Open Stack

>
http://lists.katacontainers.io/pipermail/kata-dev/2019-September/001034.html

I didn't receive this email :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



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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.katacontainers.io/pipermail/kata-dev/attachments/20190920/c22b4782/attachment-0001.html>