Re: [atomic-devel] Systemd, containers, and pid=host

[Daniel J Walsh <dwalsh redhat com>]

On 03/12/2015 02:05 PM, Clayton Coleman wrote:
> Is there a technical path to not needing the cgroup?  Are we "hacking" systemd to run in a container, vs making it truly capable of letting that control go?
This is in kernel land right now.  Systemd refuses to do away with
needing systemd within the container.  There is some effort to add a
cgroup namespace, which would allow us to have sys/fs/cgroup within the
container but only have the processes in the container listed.  This
would allow us to have containers run with this information always
available.  And potentially be able to use cgroups within the container. 

Mounting /sys/fs/cgroup into the container automatically means you are
leaking information into the container about processes outside the
container.


>> On Mar 12, 2015, at 1:21 PM, Daniel J Walsh <dwalsh redhat com> wrote:
>>
>> You could write a simple script for this now, as long as the rpm
>> containing the unit file was availabel
>>
>> FROM baseos
>> RUN yum install PATHTOUNIT; systemctl enable unit
>> CMD /usr/sbin/init
>>
>> docker build -t MYUNIT .
>>
>> docker run -d -v /sys/fs/cgroup:/sys/fs/cgroup -n MYUNIT MYUNIT
>>
>> With docker-1.5.0 in rhel this should run systemd within a container
>>
>> We are putting these patches into Fedora also.
>>
>> machinectl MYUNIT
>> and
>> journactl -m MYUNIT
>>
>> Should work, also.
>>
>> Only ugliness is the mounting of the cgroup file system.
>>
>>
>> This would end up with
>>> On 03/12/2015 09:40 AM, Clayton Coleman wrote:
>>>
>>>
>>>>> On Mar 12, 2015, at 9:30 AM, Joe Brockmeier <jzb redhat com> wrote:
>>>>>
>>>>> On 03/12/2015 07:02 AM, Clayton Coleman wrote:
>>>>> Also, we should have a tool that takes an rpm with a systemd init file
>>>>> and ends up with a docker image that works.
>>>> "should have" as in "we have that lying around somewhere" or "should
>>>> have" as in "we should put this on a board for someone to work on"?
>>> Latter - systemd unit defines the context of execution, and in both docker and rocket it should be possible to automatically "image" the package.  On the backend, we can use the process direct, insert a systemd container, or (in the long term) convert to rocket or direct systemd execution.
>>>
>>>> Might be a good thing to spec out in Matt's repo as a proposal?
>>>>
>>>> https://github.com/projectatomic/oversight
>>>>
>>>> Best,
>>>>
>>>> jzb
>>>> -- 
>>>> Joe Brockmeier | Principal Cloud & Storage Analyst
>>>> jzb redhat com | http://community.redhat.com/
>>>> Twitter: @jzb  | http://dissociatedpress.net/