Open Stack

On Fri, Sep 20, 2019 at 7:09 PM Akihiro Suda <suda.kyoto at gmail.com> wrote:
>
> > http://lists.katacontainers.io/pipermail/kata-dev/2019-September/001034.html
>
> I didn't receive this email :p
Sorry, I accidentally hit `reply-to-list` instead of `reply-to-all` :-P

>
> > Akihiro, is it possible for docker daemon to have a new configure option
> > instead? Something like:
> >   "runtimes": {
> >     "kata": {
> >       "path": "kata-runtime",
> >       "privileged_without_host_devices": true
> >     }
> >   }
> >
> > Then the behavior aligns well with [3]. And admins can just add it when
> > configuring docker to use kata-runtime. Then users don't need to change
> > their docker commandline options. Since the option is useful to all
> > docker+kata users, it makes sense to put it in the daemon config.
>
> Yes, this should be possible, and actually this is very similar to what I initially proposed (reuse runtimeArgs rather than introducing a new field): https://github.com/kata-containers/runtime/issues/1568#issuecomment-516284477
>
I was suggesting that the `privileged_without_host_devices` option
being interpreted by docker daemon instead of passing it to
kata-runtime. Is it possible? The difference is that kata-runtime
cannot tell which device is added due to `--privileged` and which is
added by users. Thus `docker run --device /dev/sda --privileged`
cannot work.

Cheers,
Tao
>
>
> 2019年9月20日(金) 19:57 Akihiro Suda <suda.kyoto at gmail.com>:
>>
>> The current gVisor seems always isolating devices even with --privileged, but I agree future version of gVisor may benefit from privileged-without-host-devices option.
>>
>> I'll keep my Moby PR open.
>>
>> 2019年9月19日(木) 1:12 Fox, Kevin M <Kevin.Fox at pnnl.gov>:
>>>
>>> Please don't take this the wrong way, as I like/use Kata. There are other isolated runtimes besides Kata though. gVisor comes to mind. I have heard of at least one other a while back not from the Kata linage. Does this dev separation work with them too? That may make it more palatable to be accepted.
>>>
>>> Thanks,
>>> Kevin
>>> ________________________________________
>>> From: Akihiro Suda [akihiro.suda.cz at hco.ntt.co.jp]
>>> Sent: Tuesday, September 17, 2019 6:35 PM
>>> To: eric.ernst at intel.com; 'Peng Tao'
>>> Cc: suda.kyoto at gmail.com; 'kata-dev'
>>> Subject: Re: [kata-dev] moby PRs for running DinD with kata
>>>
>>> Hi Tao and Eric,
>>> Cc: my gmail
>>>
>>>
>>> > I agree with the sentiment that privileged shouldn't be used unless
>>> > actually necessary, which Akihirio showed isn't the case.
>>> > FWICS, [2] doesn't work with runc, and is Kata specific?
>>>
>>> [2] doesn't work with runc and is mostly specific to Kata.
>>> Anyway [1] also seems specific to Kata, and doesn't seem to have any valid usecase with runc.
>>>
>>> Regards,
>>> Akihiro Suda
>>>
>>> -----Original Message-----
>>> From: eric.ernst at intel.com [mailto:eric.ernst at intel.com]
>>> Sent: Wednesday, September 18, 2019 1:09 AM
>>> To: Peng Tao
>>> Cc: kata-dev; Akihiro Suda; Xu Wang
>>> Subject: Re: moby PRs for running DinD with kata
>>>
>>> Hey Tao,
>>>
>>> On Tue, Sep 17, 2019 at 11:42:20PM +0800, Peng Tao wrote:
>>> > Hi Kata developers/maintainers/AC members,
>>> >
>>> > Since I cannot attend the AC meeting today, I want to bring to your
>>> > attention about two mody PRs([1] and [2]).
>>>
>>> FWIW, I like using the ML for these kinds of discussions, anyway, since
>>> it allows for more folks to chime in, and some digestion of the issue as
>>> well.  Thanks for putting this on ML!
>>>
>>> >
>>> > Akihiro Suda developed both of them as fixes for running DinD with
>>> > kata (aka, docker in kata). [1] is to provide a new docker security
>>> > option --privileged-without-host-devices, similar to the fix we had
>>> > with containerd [1]. And [2] is to simply fix the DinD entrypoint.sh
>>> > to remount sysfs in rw mode, and use a bunch of specific options to
>>> > tell docker to give proper permissions to DinD container.
>>>
>>> Thanks Akihiro.
>>>
>>> >
>>> > While [2] is good enough to fix DinD with kata, I'm afraid there might
>>> > be other container images out there that require similar tweaks to
>>> > work.
>>>
>>>
>>> I agree with the sentiment that privileged shouldn't be used unless
>>> actually necessary, which Akihirio showed isn't the case.
>>> FWICS, [2] doesn't work with runc, and is Kata specific?
>>>
>>> This is probably fine for users who "know what they are doing," and
>>> are running just in Kata? Maybe there should be a DiK or DinK image?
>>>
>>> > So I'd like to ask for your opinions on this. Do you think [2]
>>> > is good enough or is it better to persuade moby maintainers to go with
>>> > [1] instead?
>>> >
>>>
>>> I'm glad this is fixed already in containderd (and on its way for
>>> cri-o). I think adding a new flag would be helpful for us, but I
>>> understand this may not be acceptable from a moby maintainer pov.
>>> Changing the behavior of existing is too difficult for end-users, and
>>> i'm not sure an equivalent of [3] is feasilbe either.
>>>
>>> What do others think?
>>>
>>> -Eric
>>>
>>>
>>>
>>> > Cheers,
>>> > Tao
>>> >
>>> > - [1] https://protect2.fireeye.com/url?k=82cd4273-de787dca-82cd6866-0cc47adc5fce-b70c583d0228b90b&q=1&u=https%3A%2F%2Fgithub.com%2Fmoby%2Fmoby%2Fpull%2F39702
>>> > - [2] https://protect2.fireeye.com/url?k=44cf4bd5-187a746c-44cf61c0-0cc47adc5fce-d0e67658ad4ffff0&q=1&u=https%3A%2F%2Fgithub.com%2Fdocker-library%2Fdocker%2Fpull%2F191
>>> > - [3] https://protect2.fireeye.com/url?k=bda7b490-e1128b29-bda79e85-0cc47adc5fce-3601f0663a93c4fe&q=1&u=https%3A%2F%2Fgithub.com%2Fcontainerd%2Fcri%2Fpull%2F1225
>>> >
>>> > --
>>> > Into something rich and strange.
>>>
>>>
>>>
>>> _______________________________________________
>>> kata-dev mailing list
>>> kata-dev at lists.katacontainers.io
>>> https://protect2.fireeye.com/url?k=b10dcffa-edb8f043-b10de5ef-0cc47adc5fce-51d79a4c6c880768&q=1&u=http%3A%2F%2Flists.katacontainers.io%2Fcgi-bin%2Fmailman%2Flistinfo%2Fkata-dev



-- 
Into something rich and strange.