On Wed, Dec 7, 2016 at 8:38 AM, Fabian Deutsch <fdeutsch@redhat.com> wrote:
On Wed, Dec 7, 2016 at 8:26 AM, Michal Privoznik <mprivozn@redhat.com> wrote:
> On 06.12.2016 14:12, Roman Mohr wrote:
>> On Fri, Nov 25, 2016 at 4:34 PM, Michal Privoznik <mprivozn@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 <fdeutsch@redhat.com>
Associate Manager, RHV Hypervisor
Red Hat