openstack-volume team mailing list archive

["Thomas, Duncan" <duncan.thomas@xxxxxx>]

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:vladimir@xxxxxxxxxxxxxxxxx]
Sent: 25 October 2011 17:31
To: Thomas, Duncan; openstack-volume@xxxxxxxxxxxxxxxxxxx
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:duncan.thomas@xxxxxx<mailto:duncan.thomas@xxxxxx>]
Sent: Tuesday, October 25, 2011 9:21 AM
To: Vladimir Popovski; openstack-volume@xxxxxxxxxxxxxxxxxxx<mailto:openstack-volume@xxxxxxxxxxxxxxxxxxx>
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.com@xxxxxxxxxxxxxxxxxxx<mailto:openstack-volume-bounces+duncan.thomas=hp.com@xxxxxxxxxxxxxxxxxxx> [mailto:openstack-volume-bounces+duncan.thomas=hp.com@xxxxxxxxxxxxxxxxxxx]<mailto:[mailto:openstack-volume-bounces+duncan.thomas=hp.com@xxxxxxxxxxxxxxxxxxx]> On Behalf Of Vladimir Popovski
Sent: 24 October 2011 20:02
To: openstack-volume@xxxxxxxxxxxxxxxxxxx<mailto:openstack-volume@xxxxxxxxxxxxxxxxxxx>
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