Comment 14 for bug 1568191

Revision history for this message
Stephen Finucane (stephenfinucane) wrote :

My 2 cents

> The Compute os-extra_specs API allows you to put arbitrary key/value
> pairs on a flavor. How do operators discover what keys actually work
> with Nova, so they know to use hw_cpu_max_sockets instead of
> hw_cpu_maxsockets?

I guess the documentation would be the best resource here. However,
unlike image metadata, there is no way to validate flavor extra keys.
The only way to max sure the things work is to use exactly what's in
the docs and perhaps validate that things work as expected.

> For interoperability, it makes sense to use the Glance metadefs
> catalog to define the VirtCPUTopology metadata keys and value
> datatypes. But operators who are doing that now are apparently
> putting non-effective metadata keys on their images. Would the
> non-effectiveness be obvious to operators, so that they'd
> correct the keys manually, or could this go unnoticed?

It depends on how important they consider the various properties.
These particular properties are upper limits on how a many
cores/cpus/sockets a user can define, and if these limits are important
then I'd hope the operator would have tested them.

> I'm asking because if you have a large number of images and server
> snapshot images around, do we expect an operator to migrate the keys
> on all these images? A better solution might be to change the nova
> code to accept either keyname.

I think we should expect them to change it, yes. At the moment, the
flavor key provided doesn't do anything: I think it better to keep
doing nothing than possibly break installs.

> On the other hand, if the ineffectiveness is so obvious that the ops
> would have corrected their systems already, then maybe we don't have
> to worry about backward compatability so much. But as Flavio and
> Erno already commented on the patch, I'm worried about the effect
> this change will have on current operators.

Yeah, if operators really care about this then it should have been
validated. If not, see above.