<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2016-07-20 11:43 GMT-07:00 Mooney, Sean K <span dir="ltr"><<a href="mailto:sean.k.mooney@intel.com" target="_blank">sean.k.mooney@intel.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class=""><br>
<br>
> -----Original Message-----<br>
> From: Jay Pipes [mailto:<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>]<br>
> Sent: Wednesday, July 20, 2016 7:16 PM<br>
> To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
> Subject: Re: [openstack-dev] [Nova] [RFC] ResourceProviderTags - Manage<br>
> Capabilities with ResourceProvider<br>
><br>
</span><div><div class="h5">> On 07/13/2016 01:37 PM, Ed Leafe wrote:<br>
> > On Jul 11, 2016, at 6:08 AM, Alex Xu <<a href="mailto:soulxu@gmail.com">soulxu@gmail.com</a>> wrote:<br>
> ><br>
> >> For example, the capabilities can be defined as:<br>
> >><br>
> >> COMPUTE_HW_CAP_CPU_AVX<br>
> >> COMPUTE_HW_CAP_CPU_SSE<br>
> >> ....<br>
> >> COMPUTE_HV_CAP_LIVE_MIGRATION<br>
> >> COMPUTE_HV_CAP_LIVE_SNAPSHOT<br>
> >> ....<br>
> >><br>
> >> ( The COMPUTE means this is coming from Nova. HW means this is<br>
> >> hardware related Capabilities. HV means this is capabilities of<br>
> >> Hypervisor. But the catalog of Capabilities can be discussed<br>
> >> separated. This propose focus on the ResourceTags. We also have<br>
> >> another idea about not using 'PREFIX' to manage the Tags. We can add<br>
> >> attributes to the Tags. Then we have more control on the Tags. This<br>
> >> will describe separately in the bottom. )<br>
> ><br>
> > I was ready to start ranting about using horribly mangled names to<br>
> represent data, and then saw your comment about attributes for tags.<br>
> Yes, a thousand times yes to attributes! There can be several<br>
> standards, such as ‘compute’ or ‘networking’ that we use for some basic<br>
> cross-cloud compatibility, but making them flexible is a must for<br>
> adoption.<br>
><br>
> I disagree :) Adoption -- at least interoperable cloud adoption -- of<br>
> this functionality will likely be hindered by super-flexible<br>
> description of capabilities. I think having a set of "standard"<br>
> capabilities that can be counted on to be cross-OpenStack-cloud<br>
> compatible and a set of "dynamic" capabilities that are custom to a<br>
> deployment would be a good thing to do.<br>
<br>
</div></div>[Mooney, Sean K]<br>
I know there is a bad memories when I metion CIM (<a href="http://www.dmtf.org/standards/cim" rel="noreferrer" target="_blank">http://www.dmtf.org/standards/cim</a>)<br>
for many on the nova team but if we are to use standard names we should probably<br>
actually assess are there existing standads that we could adopt instead of defining<br>
our own standard names in nova for the resources.<br>
For example <a href="http://schemas.dmtf.org/wbem/cim-html/2/CIM_ProcessorAllocationSettingData.html" rel="noreferrer" target="_blank">http://schemas.dmtf.org/wbem/cim-html/2/CIM_ProcessorAllocationSettingData.html</a><br>
Define the name for different instcution set extentions for example avx is DMTF:x86:AVX.<br>
Some work has been done in glance to allow importing cim metadata from ovf files also<br>
<a href="https://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/cim-namespace-metadata-definitions.html" rel="noreferrer" target="_blank">https://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/cim-namespace-metadata-definitions.html</a><br>
<br>
while I don’t think using the full cim information model is useful in this case using the name would be<br>
from an inter-operability point of view as we not only would have standard names in openstack but those names<br>
would conform to an existing standard.<br></blockquote><div><br></div><div>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'....</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
We could still allow custom attribute but is see value in standardizing what can be standardized.<br>
<div class=""><div class="h5"><br>
<br>
><br>
> Best,<br>
> -jay<br>
><br>
> > I can update the qualitative request spec to add ResourceProviderTags<br>
> as a possible implementation.<br>
><br>
> _______________________________________________________________________<br>
> ___<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: OpenStack-dev-<br>
> <a href="http://request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>