Open Stack

2016-07-20 11:43 GMT-07:00 Mooney, Sean K <sean.k.mooney at intel.com>:

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

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-
> > request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160720/d0f0caa8/attachment.html>