Add arbitrary key/value scheduler hints ( was add reservation in scheduler hints) - #316

Coverage decreased (-0.03%) to 69.534% when pulling a083802 on msimonin:sched-hint-reservation-id into 9a5595b on gophercloud:master.

Coverage decreased (-0.03%) to 69.534% when pulling 23523ce on msimonin:sched-hint-reservation-id into 9a5595b on gophercloud:master.

@msimonin Thanks for this! I'm familiar with Chameleon and would love to see features added that go toward helping it.

At first glance, I don't see reservation defined in the scheduler_hints schema. Is it defined elsewhere in Nova? Or is scheduler_hints able to accept arbitrary key/value pairs?

If it's defined elsewhere in Nova, your approach might still be good. But if reservation is defined outside of the core Nova scheduler_hints extension, it would be better to create a Go package that defines the extension (even if it's for one additional field). If reservation is defined in Blazar, then creating something under openstack/blazar/v2 might make sense.

But if reservation works because scheduler_hints is able to accept any arbitrary key/value pairs, then rather than explicitly defining reservation, support for accepting any key should be added. Otherwise, what is preventing 10 other arbitrary additions to scheduler_hints? :)

This is is why the PR template asks for specific lines of code -- to help Gophercloud match what is defined in the actual API.

I hope that makes sense.

Thanks @jtopjian, absolutely, that makes sense.
I had a look on how scheduler_hints are handled.
The scheduler_hints schema sets the additionalProperties:True allowing extra key/value to be added under the scheduler_hints object. This won't be stripped from the request by the validator.

So in my understanding (I may be wrong), scheduler_hints allows extra key/value to be specified and thus is partially validated.
In the blazar case reservation are used to filter hosts and make pass only them in the reservation.

So in your opinion, what could be the best approach ?

• allowing arbitrary key/value ?
• create a dedicated go package to handle this key ?

Hope we can find a clean way to have this ! :)

Nice - that validator link is the key. This might also be relevant in terms of information, not implementation.

IMO, go for the arbitrary k/v in openstack/compute/v2/extensions/schedulerhints/requests.go. I swear this has been handled before, but it's too early in the morning for me to recall where. Might want to browse the various requests.go files and see.

In general, I think adding a field called AdditionalProperties of type map[string]string or map[string]interface{} is the best way to go. Then in ToServerSchedulerHintsCreateMap, iterate over AdditionalProperties, place each key in sh, then make sure AdditionalProperties is not placed in sh and sent as part of the request.

With regard to validating the UUID for reservation, I would just nix that. Validation will be moved to whatever piece of code declares reservation in the scheduler hint.

I think, anyway. @jrperritt ?

Coverage increased (+0.01%) to 69.578% when pulling e812e89 on msimonin:sched-hint-reservation-id into 9a5595b on gophercloud:master.

Coverage increased (+0.01%) to 69.578% when pulling 964aa3e on msimonin:sched-hint-reservation-id into 9a5595b on gophercloud:master.

@jtopjian, @jrperritt I've updated the merge request to allow arbitrary key/value to be passed in the scheduler hints under an AdditionnalProperties fields.

The topic of the PR and associated issue are less general than that, let me know what can I can do next.

Coverage increased (+0.01%) to 69.578% when pulling f6a89e4 on msimonin:sched-hint-reservation-id into 9a5595b on gophercloud:master.

@msimonin This looks good to me - nice work! Thank you for your help with digging into the core way this works, too.

@jrperritt does all of the final reviews. Hang tight until then :)

I confirm that, as far as I know, Nova can accept any string as a scheduler hint name. If the hint is not supported by any enabled filter, the launch will proceed as if the hint had not been provided.

The default list of filters can be extended by modules external to Nova, which is what Blazar is doing. Other projects can do the same and create new scheduler hints. See for example this Volume Affinity Filter from Mirantis. So I agree with the decision to allow arbitrary key/value pairs.

I renamed the PR title.
@jrperritt Is there any chance to get this merged soon ?

@jtopjian

In general, I think adding a field called AdditionalProperties of type map[string]string or map[string]interface{} is the best way to go. Then in ToServerSchedulerHintsCreateMap, iterate over AdditionalProperties, place each key in sh, then make sure AdditionalProperties is not placed in sh and sent as part of the request.

Agree

This looks good to me. Thanks, @msimonin and @priteau!