Wrapper for WaitForUpdatesEx in Vmware Vsphere SDK

Registered by Xiang BZ Zhou on 2014-03-17

WaitForUpdateEx method support a polling mechanism for property collection that based on a specified wait time.
There are two ways to retrieve data in Vmware Vsphere.
RetrievePropertiesEx and ContinueRetrievePropertiesEx methods perform a single collection operation, and WaitForUpdatesEx method retrieves a baseline and update set of managed object property values.
nova vmware driver and olso.vmware use lots of RetrievePropertiesEx to collect Manged Object and do not keep a synchronized representation of server state.
But sometime we need keep pace with the server side in an increment way.
WaitForUpdatesEx returns descriptions of property changes, organized by the filter that identified the properties.
This blueprint descibe a properties retrive way like that:
1. Create PropertyFilters for PropertyCollector;
2. Wrapper WaitForUpdatesEx function for caller invoke;

Blueprint information

Status:
Started
Approver:
None
Priority:
Undefined
Drafter:
Xiang BZ Zhou
Direction:
Needs approval
Assignee:
Xiang BZ Zhou
Definition:
New
Series goal:
None
Implementation:
Started
Milestone target:
None
Started by
Xiang BZ Zhou on 2014-03-17

Related branches

Sprints

Whiteboard

https://review.openstack.org/#/c/78836/
main work still in progress, but the better than none : )

I think we really need this, especially as deployments start to get larger. However, as you know the API doesn't support multiple simultaneous calls to WaitForUpdatesEx. I would like to see example code in this blueprint of how a caller would create a filter and receive updates for it, because at the moment I don't see where you're going.

#####
As i commented in 78836, "people care about two type update sets: 1st one is all'_type' MORs updates and 2nd one is specific MOR"
I'm afraid there are two sides of works to do.

First, add some basic functions in module oslo.vmware:
_create_filter(): share part between diff type update set filter
filter_object() : Wrapper for create filter of _type MOR update set(may integrate into one filter)
filter_object_property() : Wrapper for create filter(s) specific MOR(s) ..
wait_for_update(): simple wrapper for WaitForUpdatesEx method in SDK
filtrate_update_set(): simple filtrate update_set returned by WaitForUpdatesEx(for filtrate overlap result or make the return result simple )
related link: http://pubs.vmware.com/vsphere-55/index.jsp?topic=%2Fcom.vmware.wssdk.pg.doc%2FPG_PropertyCollector.7.7.html

The second part is about the loop logic in the caller side:
I suppose to use yield expression to construct update generator, and the loop logic decided by caller.

pseudo code looks like:
While true:
    value=waitforupdatesex()
    If value:
       Yield. value
    else
      return

 About how the caller use the method with subprocess or thread or greenlet, i think It 's not the oslo.vmware side business to care.

#####
It needs to be usable. You need to consider that the caller is, in all likelihood, not only going to have to ensure only a single instance of waitforupdatesex is running for any single property collector, but also that consumers can communicate with that single instance. That's screaming for library code.

I will be very uncomfortable with this until I see a realistic proposed example of how to use it. The currently proposed API doesn't address any of the difficult problems of using WaitForUpdatesEx.

######
From above:
pseudo code looks like:
While true:
    value=waitforupdatesex()
    If value:
       Yield. value
    else
      return

This take no account of multi-threading in the caller, which is the principal problem here. For example, imagine 2 threads run the above code simultaneously. Given that the point of this code is to efficiently wait for change, this is highly likely to occur frequently. As soon as it does, you have multiple callers of WaitForUpdatesEx(), which the api specifically states has undefined behaviour.

This is what makes using this API hard. It's the *only* thing that makes using it hard. It is also equally applicable to any project which uses it, which is why it makes sense for it to be addressed in oslo. There is no point in adding window dressing around WaitForUpdatesEx if it remains fundamentally unusable.
#######

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.