Code review comment for lp:~usc-isi/nova/instance_type_extra_specs

> > 1) The concept of 'metadata' doesn't fit in very well here. The data you are
> providing is integral to the provisioning process. Our usage of metadata in
> other places represents user-defined key/value pairs that our services will
> never care about. cpu_arch would probably fit better as a core instance type
> attribute, while we could look at the others as something closer to "optional
> attributes". An instance could use one of the standard instance types with a
> don't-care attitude when provisioning towards something like xpu_arch, while
> you could provide more specific instance types with those optional attributes
> being explicitly defined.
> >
> How about the name "InstanceTypeExtraSpecs"? This would keep terminology
> consistent with the distributed zone scheduler code, which uses the term
> "specs" to refer to requested attributes that need to match the capabilities
> of a compute node.

That name definitely feels better.

> > 2) I'm not completely sold on the idea that a deployer should provide
> another method for communication of instance types. I would love to integrate
> this information into the existing flavors resource in the openstack api.
> >
> I must admit that I'm only familiar with the ec2 API. I'll take a look at the
> openstack api to try and figure out how to support querying this type of data.

Something similar to the /servers/<id>/meta resource may be something to look at.