2016-07-20 11:43 GMT-07:00 Mooney, Sean K <sean.k.moo...@intel.com>: > > > > -----Original Message----- > > From: Jay Pipes [mailto:jaypi...@gmail.com] > > Sent: Wednesday, July 20, 2016 7:16 PM > > To: openstack-dev@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 <sou...@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. >
Thanks! This is good suggestion. For 'DMTF:x86:AVX', we probably can reference the 'x86:AVX', then we probably needs add some prefix like 'COMPUTE_HW_CPU'.... > > 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- > > requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
