Since affinity can be expressed as key-value pairs, that works fine for me too.
In our case no scheduler decision is needed, any volume diver instance will do, but I guess for non-fully-connected storage then it becomes a scheduling decision, so the interface should be something that the scheduler can make a decision on. I guess I need to go look at the scheduler code carefully and figure out how we might do the interactions. I'll have a read of your updated blueprint and comment. It seems to me that any setup where a generic scheduler cannot make sensible decisions is not a great design, but I am not that militant on the subject. Regards -- Duncan Thomas HP Cloud Services, Galway From: Vladimir Popovski [mailto:[email protected]] Sent: 25 October 2011 17:31 To: Thomas, Duncan; [email protected] Subject: RE: [Openstack-volume] adding auxiliary specs to volume create Hi Duncan, I was thinking of using it as a "requirements" field for volume scheduling. In this case it will be not a free-text, but dictionary of key/value pairs. Unlike regular volume metadata field where user/app could put anything, this one will be forwarded to scheduler and treated as a special set of requirements. However, I had a conversation with Clay yesterday and I agree that we could reuse metadata fields for that (this is pretty much what we are doing in our VSA scheduler). It means that vendor will need to create its own sub-scheduler who will know what fields it should look for in the meta-data. Regards, -Vladimir From: Thomas, Duncan [mailto:[email protected]<mailto:[email protected]>] Sent: Tuesday, October 25, 2011 9:21 AM To: Vladimir Popovski; [email protected]<mailto:[email protected]> Subject: RE: [Openstack-volume] adding auxiliary specs to volume create Hi I'm still working on the blueprint for affinity, but an optional free-text field that gets passed through to the scheduler and driver should be fine from a user api point-of-view. Regards -- Duncan Thomas HP Cloud Services, Galway From: openstack-volume-bounces+duncan.thomas=hp....@lists.launchpad.net<mailto:openstack-volume-bounces+duncan.thomas=hp....@lists.launchpad.net> [mailto:openstack-volume-bounces+duncan.thomas=hp....@lists.launchpad.net]<mailto:[mailto:openstack-volume-bounces+duncan.thomas=hp....@lists.launchpad.net]> On Behalf Of Vladimir Popovski Sent: 24 October 2011 20:02 To: [email protected]<mailto:[email protected]> Subject: [Openstack-volume] adding auxiliary specs to volume create Team, I would like to propose a change to volume-type aware scheduler we are developing. After last meeting it was unclear how we will treat volume affinity or other types of per-volume specifications. What I think we could do is to add an additional parameter (optional) to create volume API that will hold auxiliary specs for the volume. This parameter will be forwarded to scheduler as one of arguments. The generic scheduler will combine key/value pairs from extra specs together with these auxiliary specs and will perform a search based on combined list. Pls let me know what do you think about it? I've already update a BP spec with this proposal. Regards, -Vladimir
-- Mailing list: https://launchpad.net/~openstack-volume Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack-volume More help : https://help.launchpad.net/ListHelp
