[openstack-dev] [Nova] [RFC] ResourceProviderTags - Manage Capabilities with ResourceProvider

Mooney, Sean K sean.k.mooney at intel.com
Wed Jul 20 18:43:55 UTC 2016



> -----Original Message-----
> From: Jay Pipes [mailto:jaypipes at gmail.com]
> Sent: Wednesday, July 20, 2016 7:16 PM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [Nova] [RFC] ResourceProviderTags - Manage
> Capabilities with ResourceProvider
> 
> On 07/13/2016 01:37 PM, Ed Leafe wrote:
> > On Jul 11, 2016, at 6:08 AM, Alex Xu <soulxu at gmail.com> wrote:
> >
> >> For example, the capabilities can be defined as:
> >>
> >>     COMPUTE_HW_CAP_CPU_AVX
> >>     COMPUTE_HW_CAP_CPU_SSE
> >>     ....
> >>     COMPUTE_HV_CAP_LIVE_MIGRATION
> >>     COMPUTE_HV_CAP_LIVE_SNAPSHOT
> >>     ....
> >>
> >> ( The COMPUTE means this is coming from Nova. HW means this is
> >> hardware related Capabilities. HV means this is  capabilities of
> >> Hypervisor. But the catalog of Capabilities can be discussed
> >> separated. This propose focus on the  ResourceTags. We also have
> >> another idea about not using 'PREFIX' to manage the Tags. We can add
> >> attributes to the  Tags. Then we have more control on the Tags. This
> >> will describe separately in the bottom. )
> >
> > I was ready to start ranting about using horribly mangled names to
> represent data, and then saw your comment about attributes for tags.
> Yes, a thousand times yes to attributes! There can be several
> standards, such as ‘compute’ or ‘networking’ that we use for some basic
> cross-cloud compatibility, but making them flexible is a must for
> adoption.
> 
> I disagree :) Adoption -- at least interoperable cloud adoption -- of
> this functionality will likely be hindered by super-flexible
> description of capabilities. I think having a set of "standard"
> capabilities that can be counted on to be cross-OpenStack-cloud
> compatible and a set of "dynamic" capabilities that are custom to a
> deployment would be a good thing to do.

[Mooney, Sean K] 
I know there is a bad memories when I metion CIM (http://www.dmtf.org/standards/cim)
for many on the nova team but if we are to use standard names we should probably
actually assess are there existing standads that we could adopt instead of defining
our own standard names in nova for the resources. 
For example http://schemas.dmtf.org/wbem/cim-html/2/CIM_ProcessorAllocationSettingData.html
Define the name for different instcution set extentions for example avx is DMTF:x86:AVX.
Some work has been done in glance to allow importing cim metadata from ovf files also
https://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/cim-namespace-metadata-definitions.html

while I don’t think using the full cim information model is useful in this case using the name would be
from an inter-operability point of view as we not only would have standard names in openstack but those names
would conform to an existing standard.

We could still allow custom attribute but is see value in standardizing what can be standardized.


> 
> Best,
> -jay
> 
> > I can update the qualitative request spec to add ResourceProviderTags
> as a possible implementation.
> 
> _______________________________________________________________________
> ___
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


More information about the OpenStack-dev mailing list