| *** sameo has quit IRC | 00:12 | |
| *** mcastelino has quit IRC | 00:43 | |
| *** annabelleB has quit IRC | 01:11 | |
| *** oikiki has joined #kata-dev | 01:25 | |
| *** zerocoolback has joined #kata-dev | 01:28 | |
| *** eernst has quit IRC | 01:51 | |
| *** eernst has joined #kata-dev | 01:53 | |
| *** eernst has quit IRC | 01:58 | |
| *** zerocoolback has quit IRC | 02:56 | |
| *** liujiong has joined #kata-dev | 02:57 | |
| *** yingjun has joined #kata-dev | 03:07 | |
| *** oikiki has quit IRC | 03:12 | |
| *** yingjun has quit IRC | 03:27 | |
| *** zerocoolback has joined #kata-dev | 03:28 | |
| *** eernst has joined #kata-dev | 03:40 | |
| *** eernst has quit IRC | 03:52 | |
| *** liujiong has quit IRC | 04:22 | |
| *** liujiong has joined #kata-dev | 04:23 | |
| *** liujiong has quit IRC | 04:58 | |
| *** liujiong has joined #kata-dev | 04:59 | |
| *** oikiki has joined #kata-dev | 05:38 | |
| *** sjas_ has joined #kata-dev | 05:45 | |
| *** sjas has quit IRC | 05:48 | |
| *** zerocoolback has quit IRC | 06:14 | |
| *** oikiki has quit IRC | 06:44 | |
| *** zerocoolback has joined #kata-dev | 07:00 | |
| *** jodh has joined #kata-dev | 07:47 | |
| *** jodh has quit IRC | 07:47 | |
| *** jodh has joined #kata-dev | 07:47 | |
| *** liujiong has quit IRC | 07:57 | |
| *** cdent has joined #kata-dev | 08:50 | |
| *** sameo has joined #kata-dev | 08:52 | |
| *** gwhaley has joined #kata-dev | 08:55 | |
| *** oikiki has joined #kata-dev | 09:03 | |
| *** oikiki has quit IRC | 09:19 | |
| *** sjas_ is now known as sjas | 10:54 | |
| *** gwhaley has quit IRC | 11:58 | |
| *** gwhaley has joined #kata-dev | 12:42 | |
| *** annabelleB has joined #kata-dev | 13:46 | |
| *** rcw has joined #kata-dev | 13:55 | |
| *** sboeuf has joined #kata-dev | 14:03 | |
| *** eernst has joined #kata-dev | 14:04 | |
| *** zerocoolback has quit IRC | 14:05 | |
| kata-dev-irc-bot | <eric.ernst> hey ya'll | 14:05 |
|---|---|---|
| kata-dev-irc-bot | <sebastien.boeuf> hi @laijs @bergwolf let's start this collaborative meeting | 14:05 |
| kata-dev-irc-bot | <sebastien.boeuf> hey @eric.ernst | 14:06 |
| *** fuentess has joined #kata-dev | 14:06 | |
| *** devimc has joined #kata-dev | 14:07 | |
| kata-dev-irc-bot | <sebastien.boeuf> @bergwolf let's start with ListNetwork() | 14:07 |
| kata-dev-irc-bot | <sebastien.boeuf> you mentioned `runv network ls` | 14:08 |
| kata-dev-irc-bot | <eric.ernst> @raravena80 -- FYI from the discussion yesterday re: aws: https://github.com/kata-containers/runtime/issues/45 | 14:08 |
| kata-dev-irc-bot | <eric.ernst> @sebastien.boeuf @bergwolf - is that a command that you'd expect kata-runtime to implement? | 14:09 |
| kata-dev-irc-bot | <sebastien.boeuf> well that's exactly my question | 14:09 |
| kata-dev-irc-bot | <sebastien.boeuf> cause this seems very runv specific and I am not sure about the point having this supported by the Kata API | 14:10 |
| kata-dev-irc-bot | <sebastien.boeuf> @zhangwei555 anything you want to say about the need for `runv network ls` | 14:10 |
| kata-dev-irc-bot | <eric.ernst> I guess a naive question on my side, then would be if there is intention of having runv still after Kata makes its release (or will they just use kata-runtime, and frakti will use the kata/virtcontainers APIs). But, more importantly at this point is whether we need to support that command line option | 14:13 |
| kata-dev-irc-bot | <eric.ernst> and while i'm at it, happy equinox ya'll ;) | 14:15 |
| kata-dev-irc-bot | <zhangwei555> I think runv network ls is still necessary. Our scenario is we manage network with custom CNI plugin to add/rm/list network with runv command line. This is more direct way and we can add some customized optimization and don’t need kata runtime to do any “smart” things for us | 14:15 |
| kata-dev-irc-bot | <jonolson> @eric.ernst Maybe that's why I accidentally woke up at 5am :slightly_smiling_face: | 14:16 |
| kata-dev-irc-bot | <zhangwei555> Haha | 14:16 |
| kata-dev-irc-bot | <eric.ernst> :slightly_smiling_face: | 14:16 |
| kata-dev-irc-bot | <zhangwei555> Any network built in in cc and runv are kinds of workaround to me | 14:17 |
| kata-dev-irc-bot | <sebastien.boeuf> @zhangwei555 but the point is to push things into Kata if possible | 14:18 |
| kata-dev-irc-bot | <eric.ernst> So, your CNI plugin calls into the runtime directly. | 14:18 |
| kata-dev-irc-bot | <zhangwei555> Yes | 14:18 |
| kata-dev-irc-bot | <sebastien.boeuf> but that's not the way CNI plugins are designed initially, is it ? | 14:19 |
| kata-dev-irc-bot | <zhangwei555> For CNI network, we skip docker and use runv cmd directly | 14:19 |
| kata-dev-irc-bot | <zhangwei555> @sebastien.boeuf I don’t agree. Actually this is more CNI native way | 14:20 |
| kata-dev-irc-bot | <zhangwei555> For native container, CNI don’t care about docker, it inserts nic into container ns directly | 14:21 |
| kata-dev-irc-bot | <sebastien.boeuf> don't you already know the network namespace from runc | 14:21 |
| kata-dev-irc-bot | <sebastien.boeuf> runv | 14:21 |
| kata-dev-irc-bot | <zhangwei555> We do this too | 14:21 |
| kata-dev-irc-bot | <zhangwei555> But we can’t put nic into “kata ns” directly , unless we have kata addnetwork cmd | 14:22 |
| kata-dev-irc-bot | <sebastien.boeuf> I am trying to understand if we really need to expose `ListNetwork()` at the API level. If runv already knows about the netns, you can scan from runv (by entering this netns) | 14:22 |
| kata-dev-irc-bot | <zhangwei555> If runv copy the config from veth, you still can’t guarantee you have all nic infos correctly set | 14:23 |
| kata-dev-irc-bot | <sebastien.boeuf> Ok I understand the use case here | 14:24 |
| kata-dev-irc-bot | <sebastien.boeuf> So this needs to be well documented here: https://github.com/kata-containers/documentation/pull/27 | 14:25 |
| kata-dev-irc-bot | <zhangwei555> We do smart things for user, but you can’t do all things | 14:25 |
| kata-dev-irc-bot | Action: eric.ernst still reading it do make sure I get the nuance here. | 14:25 |
| kata-dev-irc-bot | <zhangwei555> I’ll check docs later | 14:26 |
| kata-dev-irc-bot | <eric.ernst> this is basically to avoid having to scan the containers network ns, when feasible, and just direclty add/rm/ls? | 14:27 |
| kata-dev-irc-bot | <sebastien.boeuf> thanks cause for such specific cases, we need a strong explanation why we need to expose/extend such API | 14:27 |
| kata-dev-irc-bot | <zhangwei555> I’ll add explanations in docs | 14:27 |
| kata-dev-irc-bot | <sebastien.boeuf> @eric.ernst yes, this would not be handled by virtcontainers, but externally instead | 14:28 |
| kata-dev-irc-bot | <sebastien.boeuf> @zhangwei555 another way to do that would be: | 14:29 |
| kata-dev-irc-bot | <sebastien.boeuf> - you have a watcher inside the netns scanning the network, adding any new rule or macvtap anytime it detects something new. But eventually, we need to add an `AddNetwork()` | 14:31 |
| kata-dev-irc-bot | <sebastien.boeuf> I agree with that | 14:31 |
| kata-dev-irc-bot | <sebastien.boeuf> the `ListNetwork()` is less obvious | 14:31 |
| kata-dev-irc-bot | <sebastien.boeuf> @bergwolf @laijs I'd like to talk about `sandbox.Release()` | 14:33 |
| kata-dev-irc-bot | <bergwolf> sure @sebastien.boeuf | 14:33 |
| kata-dev-irc-bot | <sebastien.boeuf> as long as we decide to destroy the pod, why can't we release what's associated to this same pod at the same time ? | 14:34 |
| kata-dev-irc-bot | <bergwolf> It is not used when destroying the pod. It is called when the CRI shim needs to quit but we want to keep the pod running, and clean up anything in-memory state (such as agent connections) and outstanding goroutines | 14:36 |
| kata-dev-irc-bot | <eric.ernst> ah. | 14:37 |
| kata-dev-irc-bot | <sebastien.boeuf> what's the use case for that ? restart ? | 14:37 |
| kata-dev-irc-bot | <bergwolf> yes, restart | 14:37 |
| kata-dev-irc-bot | <sebastien.boeuf> what is restarted ? the pod ? | 14:37 |
| kata-dev-irc-bot | <bergwolf> the CRI shim daemon | 14:37 |
| kata-dev-irc-bot | <sebastien.boeuf> why ? you want to support possible crash ? | 14:38 |
| kata-dev-irc-bot | <bergwolf> for upgrading for example | 14:38 |
| kata-dev-irc-bot | <zhangwei555> I know this. Runv is also working like this and that’s what I call it smart thing. All end to be not smart enough | 14:39 |
| kata-dev-irc-bot | <sebastien.boeuf> I get it. And the release would tell the go routines for the builtin shim to stop waiting for the process for instance ? | 14:39 |
| kata-dev-irc-bot | <bergwolf> all goroutines for the sandbox needs to be stopped | 14:39 |
| kata-dev-irc-bot | <eric.ernst> i assume there's functionality in API to attach/re-own a sandbox? | 14:40 |
| kata-dev-irc-bot | <bergwolf> e.g., the waiting process, the iostream process | 14:40 |
| kata-dev-irc-bot | <bergwolf> Yup, that's `FetchSandbox` in the api doc | 14:40 |
| kata-dev-irc-bot | <sebastien.boeuf> @eric.ernst that'd be FetchPod | 14:40 |
| kata-dev-irc-bot | <sebastien.boeuf> yeah FetchSandbox | 14:40 |
| kata-dev-irc-bot | <eric.ernst> Sorry, didn't mean to bring up the Pod v Sandbox discussion ;) | 14:40 |
| kata-dev-irc-bot | <bergwolf> ^_^ | 14:41 |
| kata-dev-irc-bot | <eric.ernst> thx for clarifying. ok. | 14:41 |
| kata-dev-irc-bot | <eric.ernst> naive question -- in the long run, is there intention to still have runv? Or is goal to move "extra" CLI options of runv into kata-runtime? | 14:41 |
| kata-dev-irc-bot | <eric.ernst> (ie, the CNI calls runv in the 'special' plugin) | 14:42 |
| *** annabelleB has quit IRC | 14:42 | |
| kata-dev-irc-bot | <sebastien.boeuf> @bergwolf yeah ok I understand the use case for `sandbox.Release()` | 14:42 |
| kata-dev-irc-bot | <bergwolf> I think kata-cli will supersede runv cli and cc-runtime in the long run, right? | 14:42 |
| kata-dev-irc-bot | <sebastien.boeuf> @bergwolf well that's our hope | 14:42 |
| kata-dev-irc-bot | <eric.ernst> ok, that's what I assumed. | 14:43 |
| kata-dev-irc-bot | <bergwolf> we don't just create yet another competitor ;) | 14:43 |
| kata-dev-irc-bot | <eric.ernst> just wanted to clarify :slightly_smiling_face: | 14:43 |
| kata-dev-irc-bot | <eric.ernst> Yep yep, makes sense. | 14:43 |
| kata-dev-irc-bot | <sebastien.boeuf> @bergwolf could you please document this release case better in the API doc | 14:43 |
| kata-dev-irc-bot | <bergwolf> sure. I'll add it | 14:43 |
| kata-dev-irc-bot | <sebastien.boeuf> cause this is not obvious | 14:43 |
| kata-dev-irc-bot | <sebastien.boeuf> thx ! | 14:43 |
| kata-dev-irc-bot | <jonolson> do either CC or runV support in-place-upgrading the hypervisor ? | 14:44 |
| kata-dev-irc-bot | <jonolson> (i'll admit to ignorance -- i don't know if qemu even supports doing that seamlessly :) | 14:45 |
| kata-dev-irc-bot | <bergwolf> @sebastien.boeuf what do you think of the metadata and vm factory plugin APIs? | 14:45 |
| kata-dev-irc-bot | <sebastien.boeuf> @bergwolf let's start with metadata | 14:45 |
| kata-dev-irc-bot | <bergwolf> @jonolson I don't think so? containers have to be restarted if hypervisor is upgrading IIUC. | 14:46 |
| kata-dev-irc-bot | <sebastien.boeuf> what is the goal exactly ? Store pod info ? | 14:46 |
| kata-dev-irc-bot | <eric.ernst> i'm not sure how the existing containers would be able to, @jonolson | 14:46 |
| kata-dev-irc-bot | <samuel.ortiz> @jonolson It does not afaik. | 14:46 |
| kata-dev-irc-bot | <samuel.ortiz> (QEMU) | 14:46 |
| kata-dev-irc-bot | <bergwolf> Yes, store/load/delete any persistent data of the pod | 14:46 |
| kata-dev-irc-bot | <bergwolf> Just as currently vc filesystem backend does. But to define the API as plugin to allow other implementations | 14:47 |
| kata-dev-irc-bot | <jonolson> this is something we do in GCE regularly -- we use a cross-version live migration to do it today, but historically we've done it with a pause/serialize/exit/fork/exit/deserialize/resume cycle -- it's not visible (well, shouldn't be) in the guest beyond a few ms of "lost time" that could just as easily be a host scheduler blip | 14:47 |
| kata-dev-irc-bot | <sebastien.boeuf> @bergwolf okay, but where is the need to expose those calls to the caller ? I would assume that virtcontainers knows what it needs to store, and this way, this should be another implementation of the storage interface, don't you think ? | 14:47 |
| kata-dev-irc-bot | <jonolson> er, exit/fork/exec, not exit/fork/exit (that wouldn't be very productive :) | 14:48 |
| kata-dev-irc-bot | <jonolson> anyway, it's not something we necessarily care about for containers where the lifecycles are often more ephemeral, but it has been useful for long-lived "instances" where there's a customer expectation of continuity | 14:48 |
| kata-dev-irc-bot | <bergwolf> @sebastien.boeuf virtcontainers is the call of this API. Internally it can be an interface for different builtin implementations. For outside implementations, it is a plugin API. | 14:49 |
| *** annabelleB has joined #kata-dev | 14:50 | |
| kata-dev-irc-bot | <bergwolf> @jonolson yes, to support that, we need to support migration in kata first. | 14:50 |
| kata-dev-irc-bot | <bergwolf> There were plans to support live migration in runv but we did not have time to implement it yet. Maybe it's a good time for kata to look at it again. | 14:51 |
| kata-dev-irc-bot | <sebastien.boeuf> @bergwolf oh okay I see what you mean now. When you're talking about metadata API, you mean the Storage interface could be exported so that we can also implement plugins for it, right ? | 14:52 |
| kata-dev-irc-bot | <bergwolf> yes, that's what I meant. | 14:52 |
| kata-dev-irc-bot | <sebastien.boeuf> @bergwolf but first step is to implement more support for the current internal `storage` interface | 14:53 |
| kata-dev-irc-bot | <zhangwei555> @bergwolf interesting point on live migration. Curious about this: how do you support live migration with 9pfs? | 14:53 |
| kata-dev-irc-bot | <bergwolf> yes, sure | 14:53 |
| kata-dev-irc-bot | <zhangwei555> Sorry for interrupt of our topic :) | 14:53 |
| kata-dev-irc-bot | <sebastien.boeuf> @bergwolf okay now this makes sense | 14:53 |
| kata-dev-irc-bot | <bergwolf> @zhangwei555 you need a shared storage if you want to migrate rootfs/volumes. | 14:54 |
| kata-dev-irc-bot | <sebastien.boeuf> @zhangwei555 no worries, this is an interesting question | 14:54 |
| kata-dev-irc-bot | <zhangwei555> Do you need hot unplug 9pfs or you have workaround? | 14:54 |
| kata-dev-irc-bot | <sebastien.boeuf> @bergwolf ok now let's talk about VM factory | 14:55 |
| kata-dev-irc-bot | <sebastien.boeuf> @zhangwei555 there is no such thing as hotunplug for 9p, is it ? | 14:55 |
| kata-dev-irc-bot | <zhangwei555> Guess so | 14:55 |
| kata-dev-irc-bot | <sebastien.boeuf> @zhangwei555 nm, there is | 14:56 |
| kata-dev-irc-bot | <sebastien.boeuf> https://lists.gnu.org/archive/html/qemu-devel/2015-10/msg02589.html | 14:56 |
| kata-dev-irc-bot | <bergwolf> @zhangwei555 you have two choices: 1. use a shared storage to support rootfs/volume and no 9pfs at all 2. use 9pfs to map host storage that is based on top of a shared storage | 14:56 |
| kata-dev-irc-bot | <bergwolf> @sebastien.boeuf yes. I think VM factory is a layer above `hypervisor`. WDYT? | 14:57 |
| kata-dev-irc-bot | <eric.ernst> had a side question on the 9p front. we've been looking at getting fixes upstream (challenging item), but came to the realization that even if we got all of this, we'd need that new kernel on host anyway. And at that point, it may make sense to just use NFS/VSOCK. Curious if folks have more insight, from a perf perspective, on this. | 14:57 |
| kata-dev-irc-bot | <eric.ernst> and posix compat. | 14:58 |
| kata-dev-irc-bot | <jonolson> you only need a new kernel if you rely on vhost, right? -- have you tried benchmarking with qemu directly servicing the 9p virtqueues ? | 14:58 |
| kata-dev-irc-bot | <sebastien.boeuf> @bergwolf that's what I was trying to figure out | 14:58 |
| kata-dev-irc-bot | <samuel.ortiz> @jonolson a host kernel, yes. | 14:58 |
| kata-dev-irc-bot | <samuel.ortiz> @jonolson you mean by doing something like fuse? | 14:59 |
| kata-dev-irc-bot | <bergwolf> @eric.ernst My understanding is that nfs over vsock is not going to be accepted by upstream in its current form. Its address design is too ugly for upstream maintainers. | 14:59 |
| gwhaley | eric.ernst: you may wish to consider eval of https://github.com/clearcontainers/vhost-9pfs as well | 14:59 |
| gwhaley | it comes with the same timeline issue as 'will not be supported on host until some time after going upstream' - unless you run it as a kernel module etc. | 15:00 |
| kata-dev-irc-bot | <jonolson> @samuel.ortiz vhost is really just virtio offload to kernel -- qemu has native support for many (all?) of the virtio devices in userland as well | 15:00 |
| kata-dev-irc-bot | <samuel.ortiz> @jonolson That's what it does by default already for 9p, yes. | 15:00 |
| kata-dev-irc-bot | <sebastien.boeuf> @bergwolf don't you think we could have an internal implementation of `hypervisor` for that ? something like `qemu_factory.go` that would implement the factory handling for qemu | 15:00 |
| kata-dev-irc-bot | <jonolson> so if you were to ship/build, say, a static qemu as part of kata you could avoid the dependency on a new host kernel | 15:01 |
| kata-dev-irc-bot | <jonolson> (if you disabled vhost) | 15:01 |
| kata-dev-irc-bot | <sebastien.boeuf> @bergwolf is the factory strongly tied to a type of hypervisor ? | 15:01 |
| kata-dev-irc-bot | <samuel.ortiz> @jonolson oh, sorry I thought you were talking about 9p... | 15:01 |
| kata-dev-irc-bot | <jonolson> @samuel.ortiz I am -- qemu can support the "host" side of 9p without host kernel support for anything other than handling VMEXITs for PIO | 15:01 |
| kata-dev-irc-bot | <sebastien.boeuf> @bergwolf or can it be decoupled from each hypervisor ? | 15:01 |
| kata-dev-irc-bot | <bergwolf> @sebastien.boeuf currently VM template is tied to qemu. But VM cache is not. | 15:02 |
| kata-dev-irc-bot | <sebastien.boeuf> @bergwolf do we need some specific API at the sandbox level, which are not part of the sandbox lifecycle ? | 15:03 |
| kata-dev-irc-bot | <bergwolf> @sebastien.boeuf what API are you suggesting? | 15:03 |
| kata-dev-irc-bot | <samuel.ortiz> @jonolson Hmm, that's basically what we do today. | 15:03 |
| kata-dev-irc-bot | <sebastien.boeuf> @bergwolf nothing, I was wondering if the VM factory process is totally handled from `CreateSandbox()` or not ? | 15:04 |
| kata-dev-irc-bot | <jonolson> @samuel.ortiz sorry -- then why is there concern about getting fixes into a new upstream host kernel? -- I think I may have missed some important context :slightly_smiling_face: | 15:04 |
| kata-dev-irc-bot | Action: samuel.ortiz reads backlog to fetch context... | 15:05 |
| kata-dev-irc-bot | <bergwolf> @sebastien.boeuf It's totally handled in `CreateSandbox()`. It just controls how a new VM is created. | 15:05 |
| kata-dev-irc-bot | <samuel.ortiz> @jonolson most likely to not maintain patches on top of our guest kernel. | 15:06 |
| kata-dev-irc-bot | <sebastien.boeuf> @bergwolf ok perfect then we can handle it from the regular `hypervisor.CreatePod()` | 15:06 |
| kata-dev-irc-bot | <jonolson> @samuel.ortiz oh -- ok, but then you just need the patches to be upstream overall -- you don't need the host where Kata is running to have picked them up | 15:07 |
| kata-dev-irc-bot | <samuel.ortiz> @jonolson Yes. The challenge with 9p is that it's basically unmaintained upstream. | 15:07 |
| kata-dev-irc-bot | <sebastien.boeuf> @bergwolf so don't you think this should be an hypervisor implementation ? | 15:07 |
| kata-dev-irc-bot | <eric.ernst> (drops back onto slack -- sorry for the confusion there) | 15:08 |
| kata-dev-irc-bot | <sebastien.boeuf> @bergwolf no need to introduce an intermediate layer for the VM factory | 15:08 |
| kata-dev-irc-bot | <bergwolf> @sebastien.boeuf I still do not think so. The functionality is above `hypervisor`. For example, if you do it in hypervisor implementation, you have to do it in every hypervisor implementation | 15:08 |
| kata-dev-irc-bot | <eric.ernst> makes sense to me, @bergwolf | 15:09 |
| kata-dev-irc-bot | <sebastien.boeuf> @bergwolf yes exactly, but I assume the implementation would be pretty different between qemu and an other hypervisor. | 15:10 |
| kata-dev-irc-bot | <bergwolf> Take cache factory for example. It requires the runtime to keep some VMs. The actual hypervisor implementation can be either qemu/libvirt/xen/kvmtools. | 15:10 |
| kata-dev-irc-bot | <jonolson> yeah :S -- internally we're (which mostly means myself and one other colleague) debating whether to better support 9p (fixups in the kernel as well as fixups in our implementation of it) or to go the block route (which I gather mirrors some of the debate here) -- virtual block devices have the distinct advantage that, especially with "virtual" nvdimm support you can make mmap() work into VMs | 15:11 |
| kata-dev-irc-bot | <bergwolf> @sebastien.boeuf Yes for VM template. No for others. We can use `hypervisor.Capabilities()` to tell if VM template is supported | 15:11 |
| kata-dev-irc-bot | <jonolson> with 9p it only works for read-only host volumes | 15:11 |
| kata-dev-irc-bot | <samuel.ortiz> @jonolson If you can control your environment to go full block, I'd avoid 9p... | 15:11 |
| kata-dev-irc-bot | <bergwolf> For cache factory, it just call standard `hypervisor` interface APIs to create new VMs. | 15:12 |
| kata-dev-irc-bot | <samuel.ortiz> just my .2 cents | 15:12 |
| kata-dev-irc-bot | <samuel.ortiz> @jonolson and 9p is not fully posix compliant, that's our major problem. | 15:12 |
| kata-dev-irc-bot | <jonolson> @samuel.ortiz we have a very fancy image caching/replication layer that speaks 9p -- but yes, generally I agree | 15:12 |
| kata-dev-irc-bot | <sebastien.boeuf> @bergwolf but when you want a new VM, you might want a new VM from scratch or a new VM from the factory. We could have a sub-interface VMFactory maybe | 15:13 |
| kata-dev-irc-bot | <samuel.ortiz> @jonolson You mean container image caching/replication ? | 15:13 |
| kata-dev-irc-bot | <sebastien.boeuf> @bergwolf I am just not clear about the factory itself | 15:13 |
| kata-dev-irc-bot | <sebastien.boeuf> @bergwolf what this means for qemu/xen/... | 15:13 |
| kata-dev-irc-bot | <jonolson> @samuel.ortiz yes -- for the read-only layers | 15:13 |
| kata-dev-irc-bot | <sebastien.boeuf> @bergwolf I would assume there is a specific part according to the type of hypervisor we're using | 15:14 |
| kata-dev-irc-bot | <samuel.ortiz> @jonolson Interesting...So you export all the ro layers into the node VM through 9p? | 15:14 |
| kata-dev-irc-bot | <bergwolf> @sebastien.boeuf the design is to include normal VM creation (aka, create one from scratch) in VM factory as well. | 15:14 |
| kata-dev-irc-bot | <sebastien.boeuf> @bergwolf yes I agree with this | 15:15 |
| kata-dev-irc-bot | <sebastien.boeuf> @bergwolf having a noop implementation for creation from scratch | 15:15 |
| kata-dev-irc-bot | <raravena80> Yeah for no downtime. | 15:15 |
| kata-dev-irc-bot | <sebastien.boeuf> @bergwolf but I'm talking implementation detail here | 15:16 |
| *** eernst has quit IRC | 15:16 | |
| kata-dev-irc-bot | <bergwolf> @sebastien.boeuf still take cache factory for example, the runtime maintains a pool of running VMs. Those VMs are created by qemu/xen etc. | 15:16 |
| kata-dev-irc-bot | <sebastien.boeuf> @bergwolf in case you have a VMFactory which actually does something | 15:16 |
| kata-dev-irc-bot | <jonolson> @samuel.ortiz right -- can leverage 9p caching since it's all read-only -- do the rw layer "some other way" (for what this is used for currently it's just tmpfs as _all_ of the containers in question are ephemeral) | 15:16 |
| kata-dev-irc-bot | <raravena80> You'd have to do vmotion/live migration first (to another machine) | 15:17 |
| kata-dev-irc-bot | <sebastien.boeuf> @bergwolf and would you need some qemu specific code from VMFactory (the case where we actually do something) ?? | 15:17 |
| kata-dev-irc-bot | <bergwolf> @sebastien.boeuf For template factory yes. For cache factory, no. | 15:18 |
| kata-dev-irc-bot | <samuel.ortiz> @jonolson may I ask: Why not using a block based graph driver on the host and go virtio-blk to export the ro layers ? | 15:18 |
| kata-dev-irc-bot | <samuel.ortiz> @jonolson Or is that what you guys are currently evaluating? | 15:18 |
| kata-dev-irc-bot | <sebastien.boeuf> @bergwolf that's my point then. For template factory, you need this to be inside the hypervisor implementation I think. Having a sub interface VMTemplate, and also relying on some reusable functions accross implementations | 15:20 |
| kata-dev-irc-bot | <bergwolf> @jonolson hyperd/runv support a rawblock graph driver that can make use of xfs/btrfs reflink feature to create shared ro layer. The rawblock file is passed to VM as block devices. You might want to take a look as well. | 15:20 |
| kata-dev-irc-bot | <samuel.ortiz> @jonolson or even better vnvdimm | 15:21 |
| kata-dev-irc-bot | <sebastien.boeuf> @bergwolf I think I got the idea, and we can move forward on this discussion | 15:21 |
| kata-dev-irc-bot | <bergwolf> @sebastien.boeuf but the functionalities is really in a different layer. If in future any other hypervisor supports vm templating, they can make use of the same code. | 15:21 |
| kata-dev-irc-bot | <sebastien.boeuf> @bergwolf we'll have more passionate discussions when the implementation time will come. | 15:21 |
| kata-dev-irc-bot | <jonolson> @samuel.ortiz 9p was a better fit for this use-case -- or at least, more expedient -- the 9p server is a true "server" so to do block we'd need to synthesize a block volume on the fly (we can't get Linux to do it for us as we don't have the right privileges in the environment where this) -- then you find out that Java makes 20k stat() calls in startup :slightly_smiling_face: | 15:21 |
| kata-dev-irc-bot | <bergwolf> @sebastien.boeuf so you are cool with vm factory on top of hypervisor? | 15:22 |
| kata-dev-irc-bot | <sebastien.boeuf> @bergwolf The only thing I want is to make sure we don't duplicate things. We'll discuss real implementation details on PR | 15:22 |
| kata-dev-irc-bot | <samuel.ortiz> @jonolson Ah, I was assuming total control of the host machine...Makes sense then. | 15:22 |
| kata-dev-irc-bot | <samuel.ortiz> 20k stat() ??? | 15:22 |
| kata-dev-irc-bot | <jonolson> @samuel.ortiz yeah, for a small-ish Spring Framework app, the Java does *stupid* things | 15:23 |
| kata-dev-irc-bot | <bergwolf> @sebastien.boeuf yes I agree. thanks! | 15:23 |
| kata-dev-irc-bot | <jonolson> er, the JRE | 15:23 |
| kata-dev-irc-bot | <sebastien.boeuf> @bergwolf I am okay with the concept of having the VMFactory and template being properly integrated into virtcontainers ;) | 15:23 |
| kata-dev-irc-bot | <samuel.ortiz> @jonolson s/for a small-ish Spring Framework app, // | 15:23 |
| kata-dev-irc-bot | <jonolson> :slightly_smiling_face: | 15:23 |
| kata-dev-irc-bot | <samuel.ortiz> cheap trolling, sorry. | 15:24 |
| kata-dev-irc-bot | <sebastien.boeuf> @bergwolf I think that's all for me | 15:24 |
| kata-dev-irc-bot | <bergwolf> @sebastien.boeuf cool. thanks! | 15:24 |
| kata-dev-irc-bot | <sebastien.boeuf> AR for @zhangwei555: Add some explicit doc to the PR about the network uses cases | 15:24 |
| kata-dev-irc-bot | <sebastien.boeuf> AR for @bergwolf: Update the diagram as asked by @james.o.hunt | 15:25 |
| kata-dev-irc-bot | <jonolson> @samuel.ortiz my day job used to be building web services in Spring -- it deserves every bit of the trolling it gets -- of course, these days I mostly write C++, so I'm not sure I've really improved my situation any :slightly_smiling_face: | 15:25 |
| kata-dev-irc-bot | <sebastien.boeuf> @bergwolf please update and comment what we've been discussing, I'll do one last review | 15:26 |
| *** gabyc_ has joined #kata-dev | 15:26 | |
| kata-dev-irc-bot | <sebastien.boeuf> @bergwolf and we'll be good to merge this doc | 15:26 |
| kata-dev-irc-bot | <bergwolf> cool. I'll update it soon | 15:26 |
| kata-dev-irc-bot | <sebastien.boeuf> @bergwolf thank you ! | 15:26 |
| kata-dev-irc-bot | <samuel.ortiz> @jonolson I've been playing with Rust for the past few days, not sure this is better ;) | 15:26 |
| kata-dev-irc-bot | <bergwolf> @sebastien.boeuf thanks for reviewing ;) | 15:26 |
| kata-dev-irc-bot | <sebastien.boeuf> np | 15:27 |
| kata-dev-irc-bot | <sebastien.boeuf> @eric.ernst that's it for me ! | 15:27 |
| kata-dev-irc-bot | <eric.ernst> Thanks y’all | 15:27 |
| kata-dev-irc-bot | <eric.ernst> I think we doubled the kata dev history this morning. | 15:28 |
| kata-dev-irc-bot | <eric.ernst> Thoughts on when to do a follow up session? | 15:28 |
| kata-dev-irc-bot | <eric.ernst> 8pm pacific, but how soon? Want another towards end of week? | 15:28 |
| kata-dev-irc-bot | <sebastien.boeuf> keep it 7AM | 15:29 |
| kata-dev-irc-bot | <anne> Does this time work for most folks? | 15:29 |
| kata-dev-irc-bot | <sebastien.boeuf> otherwise this is going to be very late for China | 15:29 |
| kata-dev-irc-bot | <anne> yeah, from our evening arch meetings, the evening pacific times are more quiet--this seemed productive | 15:29 |
| kata-dev-irc-bot | <anne> if the China folks are okay with 7am PT starts | 15:30 |
| kata-dev-irc-bot | <bergwolf> yes, 7am PT sounds good to me | 15:31 |
| kata-dev-irc-bot | <sebastien.boeuf> @eric.ernst from my perspective, I think we can wait till next week for the next one | 15:31 |
| kata-dev-irc-bot | <sebastien.boeuf> we need to have more PR to review I'd say | 15:32 |
| kata-dev-irc-bot | <sebastien.boeuf> which is going to happen after we merged this doc and that we start implementing things | 15:32 |
| kata-dev-irc-bot | <bergwolf> yup, let's keep it once a week for now and increase frequency if someone feels the need | 15:33 |
| kata-dev-irc-bot | <sebastien.boeuf> SGTM | 15:33 |
| kata-dev-irc-bot | <raravena80> a bit early for me, but I'll just scroll through the history :slightly_smiling_face: | 15:34 |
| kata-dev-irc-bot | <anne> I'll add it to the google doc, and hoping to have those ics files up on the site soon! | 15:35 |
| kata-dev-irc-bot | <sebastien.boeuf> thx @anne | 15:36 |
| *** sameo has quit IRC | 15:39 | |
| kata-dev-irc-bot | <zhangwei555> Check: 7 am PT next Monday? | 15:50 |
| kata-dev-irc-bot | <eric.ernst> Tuesday would be easier on my end | 15:50 |
| kata-dev-irc-bot | <eric.ernst> But am okay either way. My calendar will remind me :) | 15:50 |
| kata-dev-irc-bot | <bergwolf> @zhangwei555 same time as this one I think. It's Tuesday night for us in China. | 15:50 |
| kata-dev-irc-bot | <zhangwei555> Aha, I see | 15:51 |
| kata-dev-irc-bot | <zhangwei555> Thanks guys | 15:52 |
| kata-dev-irc-bot | <anne> I'd suggest tuesday US time. Monday morning 7am won't have us North American folks at our sharpest ;) | 15:53 |
| kata-dev-irc-bot | <zhangwei555> Ok for me | 15:54 |
| *** devimc has quit IRC | 15:54 | |
| *** sameo has joined #kata-dev | 15:56 | |
| *** mcastelino has joined #kata-dev | 15:56 | |
| kata-dev-irc-bot | <laijs> @sebastien.boeuf, Oh, I just missed the discussion, I can add a few comments. 1) VM factory works on top of hypervisor interface which is how runv does. But we can use the same interface for both of them (factory & hypervisor). For example the interface name can be `builder`. The function GetCacheBuilder(qemuBuilder) can return a VM cache with qemu as its underlying hypervisor for you. see | 16:04 |
| kata-dev-irc-bot | https://github.com/kata-containers/runtime/pull/32 it makes use of Adapter design patent to use single interface for two or more layers. 2) Factory can not be implemented in hypervisor. @bergwolf explained it with the cache factory. And for template factory, qemu hypervisor doesn’t support template directly, qemuhypervisor.CreateVM(congfigwithtemplate) is not going to work. Actually, a modified qemu just supports shared memory migration and | 16:04 |
| kata-dev-irc-bot | the template factory make use of this ability: creates a vm first and save it, and returns a cloned vm from the first saved one when requested. the factory owns a set of state, it is not a hypervisor. | 16:04 |
| *** eernst has joined #kata-dev | 16:55 | |
| *** gwhaley has quit IRC | 16:57 | |
| *** sameo has quit IRC | 17:03 | |
| *** devimc has joined #kata-dev | 17:16 | |
| *** annabelleB has quit IRC | 17:18 | |
| *** annabelleB has joined #kata-dev | 17:19 | |
| *** gwhaley has joined #kata-dev | 17:36 | |
| *** sameo has joined #kata-dev | 17:40 | |
| *** jodh has quit IRC | 18:05 | |
| *** sameo has quit IRC | 18:05 | |
| *** oikiki has joined #kata-dev | 18:06 | |
| *** eernst has quit IRC | 19:15 | |
| *** eernst has joined #kata-dev | 19:18 | |
| *** eernst has quit IRC | 19:23 | |
| *** eernst has joined #kata-dev | 19:28 | |
| *** eernst has quit IRC | 19:32 | |
| *** eernst has joined #kata-dev | 19:34 | |
| *** eernst has quit IRC | 19:37 | |
| *** eernst has joined #kata-dev | 19:40 | |
| *** eernst_ has joined #kata-dev | 19:42 | |
| *** eernst__ has joined #kata-dev | 19:43 | |
| *** eernst_ has quit IRC | 19:43 | |
| *** eernst has quit IRC | 19:44 | |
| *** gwhaley has quit IRC | 19:49 | |
| *** annabelleB has quit IRC | 19:58 | |
| *** eernst__ has quit IRC | 20:02 | |
| *** eernst has joined #kata-dev | 20:07 | |
| *** annabelleB has joined #kata-dev | 21:15 | |
| *** rcw has quit IRC | 21:16 | |
| *** devimc has quit IRC | 22:08 | |
| *** sameo has joined #kata-dev | 22:15 | |
| *** oikiki has quit IRC | 22:43 | |
| *** oikiki has joined #kata-dev | 22:50 | |
| *** eernst has quit IRC | 22:54 | |
| *** eernst has joined #kata-dev | 22:55 | |
| *** eernst has quit IRC | 22:56 | |
| *** eernst has joined #kata-dev | 22:56 | |
| *** eernst has quit IRC | 22:58 | |
| FL1SK | annabelleB: Hi, This is Cameron. Creating the Blog posts. Where was the Wiki I was supposed to write the drafts? | 23:01 |
| annabelleB | Hi cameron! I think jodh was thinking we’d do drafts via github (under community). | 23:02 |
| FL1SK | ah.. sounds good looking at community now | 23:03 |
| FL1SK | Starting the writing now annabelleB | 23:04 |
| FL1SK | ;-) | 23:04 |
| annabelleB | FL1SK: we haven’t put a home for them yet, but that can change! | 23:04 |
| *** gabyc_ has quit IRC | 23:04 | |
| FL1SK | No worries | 23:04 |
| *** eernst has joined #kata-dev | 23:05 | |
| *** eernst_ has joined #kata-dev | 23:06 | |
| *** oikiki has quit IRC | 23:06 | |
| *** eernst__ has joined #kata-dev | 23:07 | |
| FL1SK | annabelleB: Wiki is not open under Community, but i can issue a pull request to community to publish the draft there in MD format | 23:07 |
| annabelleB | sounds good! i’ll look for it | 23:08 |
| FL1SK | Cool | 23:08 |
| *** eernst has quit IRC | 23:09 | |
| *** eernst_ has quit IRC | 23:10 | |
| annabelleB | FL1SK: actually, could you make the draft live in a folder? Maybe a “Weekly Status Blogs” folder? | 23:11 |
| FL1SK | annabelleB: sure thing.. having trouble witih access right now.. hmm | 23:12 |
| *** eernst__ has quit IRC | 23:12 | |
| FL1SK | nevermind got it | 23:12 |
| *** sboeuf has quit IRC | 23:32 | |
| *** cdent has quit IRC | 23:50 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!