Open Stack

On Tue, Apr 6, 2021 at 1:04 AM Amnon Ilan <ailan at redhat.com> wrote:

>
>
> On Tue, Mar 30, 2021 at 2:50 AM Eric Ernst <eric.g.ernst at gmail.com> wrote:
>
>> Ya'll,
>>
>> I'd like to see if we can create a pattern in upstream Kata Containers to
>> help facilitate directly assigning volumes to the VM via virtio-blk,
>> skipping any mounts on the host, and avoiding needing to use a shared
>> file-system for the particular volume. Some of the benefits in doing this:
>>  - we can better isolate the host (no mounted filesystem),
>>  - more efficient and much faster data path that non-dax virtiofs.
>>  - avoid inode caching/memory overheads of virtiofs on the host.
>>
>> In Kubernetes today, there is not a direct communication channel between
>> CSI and the runtime. To make this work on a shorter timeline, therefore, we
>> need to come up with a less traditional way to communicate between the
>> user, CSI and the runtime. I have a proposal in place that "works" today,
>> and I'd like to get feedback on how to improve it, and see if it could be a
>> good fit for upstream. Please see: the proposal at [1], and the PR
>> associated with that proposal at [2].
>>
>
> I'm not an expert here, but why not use raw block rather than adding the
> annotation skip-hostmount
> https://kubernetes.io/blog/2019/03/07/raw-block-volume-support-to-beta/
>
> +Orit Wasserman <owasserm at redhat.com>
>

Hey Amnon,

Raw block is supported well in Kata today (it just works); the problem is
that the workload/user would then need to utilize a raw block, when in most
cases, they want a mounted filesystem to interact with.

The direct-assignment work's goal is to provide a mounted filesystem to the
container workload.

Eric


> Thanks,
> Amnon
>
>
>
>>
>> Please let me know if you:
>>   - have any suggestions on the pattern
>>   - you are a user that would find this pattern helpful for their
>> use-cases
>>
>> Thanks,
>> Eric
>>
>> [1] -
>> https://github.com/egernst/kata-containers/blob/da-proposal/docs/design/direct-assign-volume.md
>> [2] - https://github.com/kata-containers/kata-containers/pull/1568
>>
>> _______________________________________________
>> kata-dev mailing list
>> kata-dev at lists.katacontainers.io
>> http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.katacontainers.io/pipermail/kata-dev/attachments/20210406/247c4438/attachment.html>