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