the only part of this separation I do not understand is the exact
behavioral relationship between VMConfig and the VM.
I see two major scenarios:
- VMConfig represents the configuration of a single VM (independently
on its current state).
This case actually does not need a separate entity, just a separate
section. I can imagine a service that takes the global VM, reads the
high level VM.Config section and generates / updates the VM.Spec
section inside the same object (no extra queries to api server are
Per-VM override is trivial as VM.Config is the object to change and
VM.Spec will be updated automatically.
Stopped VMs still look the same and keep the last VM.Spec computed for them.
Each VM is defined by its own VM object. Pools and templates are
represented outside of kubevirt (which might be necessary anyway, see
- VMConfig represents a template of sorts and is separate from VM
This case allows using single VMConfig for multiple VMs (and VM
objects). But the cost is complexity:
- Any querying will have to call apiserver multiple times to
retrieve all the information
- Per VM values like MAC address assignments or PCI passthrough
device addresses will have to be kept separately in the VM object
- Some computed values (like the memory overhead) will have to use
either two sources of information or keep high level copy in the VM
object as well.
And then there comes the update scenario.. what is supposed to
happen when VMConfig is updated? Are all information supposed to be
transferred to all VMs that were created accoding to the VMConfig
object? Or just some of them? What about per-VM overrides (temporary
change in resource allocation for example - and we will need those)?
I think we need to decide between those two usage patterns and if you
are really set on the path to the second one, then you have to
describe the mechanics of updates and local overrides properly.
> You received this message because you are subscribed to the Google Groups "kubevirt-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to kubevirt-dev...@googlegroups.com
> To post to this group, send email to kubevi...@googlegroups.com
> To view this discussion on the web visit https://groups.google.com/d/msgid/kubevirt-dev/CA%2BPVUaSEf0pLv4inNt9eivkf-7rqzTKa9Yp56jo55RmomZ85TQ%40mail.gmail.com
> For more options, visit https://groups.google.com/d/optout