Meeting notes:

Agreements by today:

1. Integrate CRFS-like function by a separate plugin of iSulad

2. One image, but not two with tags of meta/stargz as the example of crfs[1].

a) iSulad identifies the image type by MIME type or special LABEL in the distribution spec.

3. For stargz format image, do not support run as normal image (although technically, it can be).

a) Which means, we do not support “mixed deployment” with smart-loading type and normal type with the same image;

4. If there is a stargz format image in registry with name:tag, then user overrided it with normal format with the same name:tag. User should take responsibility in such scenario.

Those are left to dig more:

1. iSulad identifies the image type by MIME type or special LABEL in the distribution spec?

2. How to bypass the normal image pulling procedure by only pulling manifest in iSulad?

[1]: crfs: https://github.com/google/crfs

Best Regards,

Lu Jingxiao

发件人: lujingxiao
发送时间: 2020年6月15日 15:36
收件人: 'isulad@openeuler.org' <isulad@openeuler.org>
抄送: Weiwei (N) <wick.wei@huawei.com>
主题: Discuss on #I1JAH2: [Feature-request] Smart loading for remote images

Hi iSulad owners,

About #I1JAH2: [Feature-request] Smart loading for remote images, we’ve got some progress.

I would like to raise a topic on tomorrow’s SIG meeting, to discuss those known issues and invite you to review the design doc.

Those are left on last SIG meeting:

- integrate crfs with plugin or standalone daemon?

- how to detect the wanted image to run is normal image or stargz format? with special MIME type?

- integrate with kata: currently 9p+overlayfs should be OK, but what about virtiofs? Modify virtiofs to support crfs?

- current POC is using external rootfs to connect to crfs, can we use graphdriver but not external rootfs?

Best Regards,

Lu Jingxiao