| *** eernst has quit IRC | 00:02 | |
| *** eernst has joined #kata-dev | 00:16 | |
| *** eernst has quit IRC | 00:39 | |
| *** eernst has joined #kata-dev | 00:46 | |
| *** eernst has quit IRC | 00:51 | |
| *** sameo has joined #kata-dev | 01:06 | |
| *** eernst has joined #kata-dev | 01:08 | |
| *** oikiki has joined #kata-dev | 01:14 | |
| *** sameo has quit IRC | 01:22 | |
| kata-dev-irc-bot | <eric.ernst> @xu @bergwolf @laijs can you open up issues in kata-runtime to track/detail out the remaining features for release (ie: metadata / vm factory)? I'm not 100% clear if we should have seperate line items for vm factory pieces (cache, template). | 01:37 |
|---|---|---|
| kata-dev-irc-bot | <eric.ernst> I want to make sure each remaining item that we're putting in our release notes has a specific issue associated with it. | 01:37 |
| kata-dev-irc-bot | <bergwolf> @eric.ernst I'll create them | 01:43 |
| kata-dev-irc-bot | <bergwolf> We already have one for vm factory: https://github.com/kata-containers/runtime/issues/52 I added one for metadata backends: https://github.com/kata-containers/runtime/issues/233 | 01:49 |
| kata-dev-irc-bot | <bergwolf> @erig | 01:49 |
| kata-dev-irc-bot | <bergwolf> @eric.ernst ^^ | 01:49 |
| *** oikiki has quit IRC | 02:08 | |
| *** oikiki has joined #kata-dev | 02:08 | |
| *** oikiki has quit IRC | 02:08 | |
| *** oikiki has joined #kata-dev | 02:09 | |
| *** oikiki has quit IRC | 02:09 | |
| *** oikiki has joined #kata-dev | 02:10 | |
| *** oikiki has quit IRC | 02:10 | |
| *** zerocoolback has joined #kata-dev | 02:16 | |
| *** oikiki has joined #kata-dev | 02:48 | |
| *** oikiki has quit IRC | 03:21 | |
| *** oikiki has joined #kata-dev | 03:22 | |
| *** oikiki has joined #kata-dev | 03:42 | |
| *** oikiki has quit IRC | 04:20 | |
| *** sjas_ has joined #kata-dev | 04:25 | |
| *** sjas has quit IRC | 04:28 | |
| *** eernst has quit IRC | 04:50 | |
| *** eernst has joined #kata-dev | 04:51 | |
| *** sjas_ is now known as sjas | 05:33 | |
| *** oikiki has joined #kata-dev | 05:34 | |
| *** oikiki has quit IRC | 06:23 | |
| *** jodh has joined #kata-dev | 06:24 | |
| *** jodh has quit IRC | 06:24 | |
| *** jodh has joined #kata-dev | 06:24 | |
| *** dims has quit IRC | 06:54 | |
| *** oikiki has joined #kata-dev | 06:55 | |
| *** dims has joined #kata-dev | 06:56 | |
| *** dims has quit IRC | 07:01 | |
| *** dims has joined #kata-dev | 07:02 | |
| *** diga has joined #kata-dev | 07:07 | |
| *** zerocoolback has quit IRC | 07:37 | |
| *** zerocoolback has joined #kata-dev | 07:37 | |
| *** zerocoolback has quit IRC | 07:42 | |
| *** gwhaley has joined #kata-dev | 07:49 | |
| *** zerocoolback has joined #kata-dev | 08:18 | |
| *** eernst has quit IRC | 08:51 | |
| *** eernst has joined #kata-dev | 08:51 | |
| *** oikiki has quit IRC | 08:52 | |
| *** cdent has joined #kata-dev | 09:09 | |
| *** eernst has quit IRC | 09:20 | |
| *** eernst has joined #kata-dev | 09:20 | |
| *** eernst has quit IRC | 09:55 | |
| *** eernst has joined #kata-dev | 09:55 | |
| *** cdent has left #kata-dev | 10:24 | |
| *** gwhaley has quit IRC | 11:04 | |
| *** mugsie has quit IRC | 11:42 | |
| *** mugsie has joined #kata-dev | 11:42 | |
| *** mugsie has quit IRC | 11:42 | |
| *** mugsie has joined #kata-dev | 11:42 | |
| *** gwhaley has joined #kata-dev | 12:27 | |
| *** eernst has quit IRC | 12:51 | |
| *** eernst has joined #kata-dev | 12:51 | |
| *** fuentess has joined #kata-dev | 12:59 | |
| kata-dev-irc-bot | <zhangwei555> I think it’s better tagging them “release-1.0”, then we can know how far the release 1.0 is from us | 13:01 |
| kata-dev-irc-bot | <zhangwei555> I am doing the sandbox.AddStorage, I want to make sure I am doing it right. In my understanding, this is for Frakti to do hotplug storage in parallel for boosting container creating speed. So when should this function be called? To plug a storage, we need to specify a destination in container. Is this only used for hot plugging block device to qemu? Then container can mount the device to dest in Guest? @bergwolf | 13:06 |
| kata-dev-irc-bot | <zhangwei555> Or after container is created and running, we still need to add a new storage? Is there such scenario? | 13:08 |
| kata-dev-irc-bot | <zhangwei555> Can you give me the call trace of sandbox.AddStorage for illustration? I’m not very clear about the use case here | 13:09 |
| kata-dev-irc-bot | <james.o.hunt> @zhangwei555 - "release-1.0" isn't a semantic version. See https://semver.org/ and this release process PR: https://github.com/kata-containers/documentation/pull/56. | 13:11 |
| kata-dev-irc-bot | <zhangwei555> Wow, this is a very detailed doc, thanks for pointing it to me. So it should be 1.0.0 (maybe -rc1) ^^ | 13:18 |
| kata-dev-irc-bot | <bergwolf> @zhangwei555 A storage is a sandbox resource, it can be reference by a container via the rootfs or mount.Source field in the OCI spec. We do not need to determine the actual mountpoint inside the container. At the API level, I think we can just use a storageID to identify it and reference it in the OCI spec. Then within virtcontainers, we can translate the storageID to a mountpoint inside the sandbox when calling agent's | 13:38 |
| kata-dev-irc-bot | CreateContainer so that `storage.Mountpoint == OCI.Mount.Source`. The AddStorage API is invoked after `StartSandbox` and before `CreateContainer`, in parallel with `AddNetwork`. | 13:38 |
| kata-dev-irc-bot | <james.o.hunt> @zhangwei555 - yes, 1.0.0-rc1 would work I think. /cc @eric.ernst | 13:40 |
| kata-dev-irc-bot | <bergwolf> > Or after container is created and running, we still need to add a new storage? Is there such scenario? The idea is to hotplug rootfs and volumes before creating new containers. So we do not indent to hotplug a volume to a running container. But we can hotplug volumes for future containers to a running sandbox that can may already have some containers. | 13:42 |
| kata-dev-irc-bot | <zhangwei555> I get your point. But from design, I have a different idea. Block device is per sandbox, volume is per container. That means if we want to mount one block device to different mounts in different container, we only need to hotplug block to qemu once by qmp command, then mount one device (say /dev/vda) to different dest. In the scenario you provided, I have another proposal. What you need is a sandbox.AddDevice(/dev/block), then | 13:54 |
| kata-dev-irc-bot | in CreateContainer, when we try to mount a volume, and when we try to hotplug same block device, we can just skip it. I think this can fulfill your requirement, WDYT? | 13:54 |
| kata-dev-irc-bot | <bergwolf> Using a storageID also allows us to just hotplug a block device just once and the comtainer can reference it multiple times. I do not see the benifit of changing to AddDevice. | 14:05 |
| kata-dev-irc-bot | <zhangwei555> So the sandbox.AddStorage() only plug a device but don’t need to do any mount inside container/sandbox, right? | 14:08 |
| kata-dev-irc-bot | <bergwolf> And we want the addstorage API to support 9p, block device, rbd and nfs. and in virtcontainers, we only hotplug block device and rbd to guest. | 14:08 |
| kata-dev-irc-bot | <zhangwei555> Why do we need to support 9pfs? I think it won’t reduce much starting time | 14:09 |
| kata-dev-irc-bot | <bergwolf> right. it only hotplug the device to the guest vm and save the storage info in sandbox metadata. | 14:09 |
| *** gabyc_ has joined #kata-dev | 14:10 | |
| kata-dev-irc-bot | <zhangwei555> I can understand the virtio-blk scenario | 14:10 |
| kata-dev-irc-bot | <bergwolf> it's for simplicity so that we hotplug all rootfs and volumes. virtcontainers just need to record the 9pfs storage. | 14:12 |
| kata-dev-irc-bot | <zhangwei555> I think we only need to pre-plug the block device but not 9pfs die, that’s why I think it should be named AddDevice but not AddStorage | 14:13 |
| *** devimc has joined #kata-dev | 14:14 | |
| kata-dev-irc-bot | <bergwolf> it's ok if we only want to support storage types that need qmp hotplug. if you want to call it AddDevice, we need a way to differentiate it with a real device inside the comtainer. and yes, we will need AddDevice at some point | 14:16 |
| kata-dev-irc-bot | <bergwolf> as long as we can make it work and do bot interfere normal device hotplug, I do not care much about the naming:slightly_smiling_face: | 14:18 |
| kata-dev-irc-bot | <zhangwei555> So we need to first make the scenario clear, AddDevice may not be a good name. Maybe call it hotplugDev or something better | 14:19 |
| kata-dev-irc-bot | <zhangwei555> I want to make sure it can fulfill your need. And also remove unnecessary funcs inside it | 14:19 |
| kata-dev-irc-bot | <bergwolf> I think it can still fulfill the need. we need to define how to reference it in the OCI spec though. I think it can still be referenced by a deviceID, and in virtcontainers, we create addstorage grpc calls based on the reference info and change OCI spec to match storage.mountpoint to rootfs and mount.source. We still need the api to be able to pass storage type and mount options, if we call it AddDevice | 14:26 |
| kata-dev-irc-bot | <zhangwei555> I think I fully get your requirements. I’ll try to make a first implementation. The function name can be discussed later. In first implementation, I will first add virtio-blk, and I’ll leave some space for extension so in future we can support 9pfs if necessary. Is that OK? | 14:34 |
| *** zerocoolback has quit IRC | 14:41 | |
| kata-dev-irc-bot | <bergwolf> sounds good, thanks！ | 14:46 |
| *** gabyc_ has quit IRC | 14:49 | |
| *** gabyc_ has joined #kata-dev | 14:50 | |
| *** gabyc_1 has joined #kata-dev | 14:51 | |
| *** gabyc_ has quit IRC | 14:51 | |
| kata-dev-irc-bot | <julio.montes> @bergwolf ptal https://github.com/kata-containers/runtime/pull/130 | 15:15 |
| *** devimc has quit IRC | 15:50 | |
| *** eernst has quit IRC | 16:08 | |
| *** gabyc_1 has quit IRC | 16:17 | |
| *** devimc has joined #kata-dev | 16:22 | |
| *** gabyc_ has joined #kata-dev | 16:41 | |
| *** gabyc_1 has joined #kata-dev | 16:42 | |
| *** gabyc_ has quit IRC | 16:42 | |
| *** gabyc_1 has quit IRC | 16:52 | |
| *** gabyc_ has joined #kata-dev | 16:55 | |
| *** jodh has quit IRC | 17:01 | |
| *** gwhaley has quit IRC | 17:08 | |
| *** cdent has joined #kata-dev | 17:10 | |
| *** cdent has left #kata-dev | 17:11 | |
| *** pabelanger has quit IRC | 18:17 | |
| *** pabelanger has joined #kata-dev | 18:17 | |
| *** oikiki has joined #kata-dev | 18:29 | |
| *** diga has quit IRC | 18:53 | |
| *** oikiki has quit IRC | 19:11 | |
| *** eernst has joined #kata-dev | 19:23 | |
| *** eernst has quit IRC | 19:39 | |
| *** oikiki has joined #kata-dev | 19:44 | |
| *** djinni_ has quit IRC | 19:52 | |
| *** djinni has joined #kata-dev | 19:55 | |
| *** oikiki has quit IRC | 20:13 | |
| *** oikiki has joined #kata-dev | 20:16 | |
| *** oikiki has quit IRC | 20:24 | |
| *** oikiki has joined #kata-dev | 20:27 | |
| *** justJanne has quit IRC | 20:58 | |
| *** justJanne has joined #kata-dev | 20:58 | |
| *** devimc has quit IRC | 21:05 | |
| *** fuentess has quit IRC | 21:31 | |
| *** gabyc_ has left #kata-dev | 21:43 | |
| *** justJanne has quit IRC | 23:21 | |
| *** justJanne has joined #kata-dev | 23:22 | |
| *** oikiki has quit IRC | 23:53 | |
| *** oikiki has joined #kata-dev | 23:53 | |
| *** oikiki has quit IRC | 23:54 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!