On Wed, Dec 7, 2016 at 8:38 AM, Fabian Deutsch <fdeut...@redhat.com> wrote:
> On Wed, Dec 7, 2016 at 8:26 AM, Michal Privoznik <mpriv...@redhat.com> > wrote: > > On 06.12.2016 14:12, Roman Mohr wrote: > >> On Fri, Nov 25, 2016 at 4:34 PM, Michal Privoznik <mpriv...@redhat.com> > >> wrote: > >> > >>> On 25.11.2016 14:38, Roman Mohr wrote: > >>> > >>> > >> [...] > >> > >> > >>>> > >>>> 4) There libvirt domain description is not versioned > >>>> > >>>> I would expect that every time I update a domainxml (update from third > >>>> party entity), or an event is generated (update from libvirt), that > the > >>>> resource version of a Domain is increased and that I get this resource > >>>> version when I do a xmldump or when I get an event. Without this > there is > >>>> afaik no way to stay in sync with libvirt, even if you do regular > polling > >>>> of all domains. The main issue here is that I can never know if > events in > >>>> the queue arrived before my latest domain resync or after it. > >>>> > >>>> Also not that this is not about delivery guarantees of events. It is > just > >>>> about having a consistent view of a VM and the individual event. If I > >>> have > >>>> resource versions, I can decide if an event is still interesting for > me > >>> or > >>>> not, which is exactly what I need to solve the syncing problem above. > >>>> When I do a complete relisting of all domains to syn, I know which > >>> version > >>>> I got and I can then see on every event if it is newer or older. > >>>> > >>>> If along side with the event, the domain xml, the VM state, and the > >>>> resource version would be sent to a client, it would be even better. > >>> Then, > >>>> whenever there is a new event for a VM in the queue, I can be sure > that > >>>> this domainxml I see is the one which triggered the event. This xml is > >>> then > >>>> a complete representation for this revision number. > >>> > >>> I recall some people asking for this. Basically, they were worried > about > >>> somebody from outside could manipulate their XMLs without them knowing. > >>> Frankly I don't recall what was our answer to that. > >> > >> > >> > >> > >> > >>> > >>> > >> Having a version number in live XML makes sense. However, it makes less > >>> sense for config XML - there would be no way how to start with version > >>> #0 once I've edited the file. > >>> > >> > >> I think it would be very beneficial to have it on the config file too. > >> Think about the resource version as opaque data which can be used by > >> libvirt to see if the domain xml update contains the same resource > number > >> which libvirt sees. > > > > If we do this then it's just a matter of time that users start demanding > > "How do I return to revision #1337?". And we don't want to go there. > > Well - We could argue that currently it is just not possible to > connect libvirtd events and a specific dom revision. This implies that > users also could not do it themselves. > With the change however, libvirtd will not provide the full history, > but if it's needed then now users are able to add such functionality > alongside of libvirtd. It would ismpliy enable this usecase. > +1 If the dom and events are connected, creating your own history is just a matter of storing the dom in a map or a key-value store with the revision as a key. Really no need to have that in libvirt. In my eyes the benefit here really is that you get consistency which enables all the consistent caching and update usecases. > > >> So if you want to be sure that you are updating the domain xml from the > >> latest state, you pass in the resource version of your cached domain xml > >> view. If the version is still the same inside of libvirt, libvirt > updates > >> the domain xml and increases the resource version. If it has changed in > the > >> meantime, it rejects the update and the client can re-fetch the latest > >> state and try again. > > > > Makes sense. > > > >> For classic update mode, just don't pass in the > >> resource version as a client and libvirt can then just update the domain > >> xml like always. This is pretty much the same principle like described > in > >> [1]. > > > > What if users start mixing XMLs with and without revision IDs? > > Also, I'm a bit worried about revision ID wrap, but hopefully ULL is big > > enough. > > I guess that mixing with and without IDs in subsequent updates should > not be an issue. > In the case with the ID it's a sanity check to ensure that the right > state is getting updated. Without the ID this check is omitted. > > I can understand the concerns here. Maybe having a config value to enable resource versioning might make sense. Then we could enforce the presence of a resource version on updates. If versioning is turned off, everything is like always. This would problems like this completely. > - fabian > > >> > >> What is the rationale for this? > >> > >> I am mostly operating on cached views on libvirts data in combination > with > >> events. If, on listing resources and on events, I get a domain xml with > a > >> resource version and the Domain state, I have a full snapshot of the > >> Domain, which I can put into a cache or queue. Then syncing with libvirt > >> based on events and initial listing is possible. Otherwise I can never > be > >> sure if my view of libvirt is out of sync. > >> > >> When I then process an event I can process it based on the consistent > >> snapshot view of the Domain and update the domain xml. If something has > >> changed in the meantime, the update of the domain xml will fail and I > can > >> recheck and retry. Even better: In most cases the event does not need > >> retries, because a newer event is already in the queue with the new > Domain > >> view which caused the update to fail. > > > > What if on event arrival you'd only note whatever actions you need to > > perform and only after you've processed the whole queue you start > > executing them? > The problem I see here is that there can always be another event while I am executing an action, that makes it very hard to write well behaving code in combination with events. > > > > Michal > > > > -- > Fabian Deutsch <fdeut...@redhat.com> > Associate Manager, RHV Hypervisor > Red Hat >
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list