Wrapper for WaitForUpdatesEx in Vmware Vsphere SDK
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.
RetrievePropert
nova vmware driver and olso.vmware use lots of RetrievePropert
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
- Completed by
Related branches
Related bugs
Sprints
Whiteboard
https:/
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_
wait_for_update(): simple wrapper for WaitForUpdatesEx method in SDK
filtrate_
related link: http://
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=
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=
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.
#######
