Comment 16 for bug 1568191

> 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?

Historically there was nothing formal defined - things were just mentioned in docs in an adhoc manner. I don't think we're much better today.

> 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?

I don't know where the Glance metadefs catalog comes from, but from Nova's
POV it is certainly not the canonical source. Nova has a versioned object
that formally declares what is accepted by Nova, providing reasonably strong
validation on the field data formats. Any other source of information is at
best a duplicate of this object model, or at worse plain wrong.

https://github.com/openstack/nova/blob/master/nova/objects/image_meta.py

What's missing is that we ought to be auto-generating some documentation from
the ImageMeta object model for each relase, so there's clear info on what's
 supported.

> 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.

Nova already has back-compat hacks to deal with some old key names, but this is for the case where old versions of nova actually used those old key names. It sounds like here we're talking about things that we just mistakenly documented somewhere and were never actually honoured by nova. For that I don't see any compelling reason to add back compat, as they have would have never worked.