<div dir="ltr">Nova-spec is submitted: <a href="https://review.openstack.org/345138">https://review.openstack.org/345138</a>, welcome review and comments!</div><div class="gmail_extra"><br><div class="gmail_quote">2016-07-11 19:08 GMT+08:00 Alex Xu <span dir="ltr"><<a href="mailto:soulxu@gmail.com" target="_blank">soulxu@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>This propose is about using ResourceProviderTags as a solution to manage Capabilities (Qualitative) in ResourceProvider.</div><div>The ResourceProviderTags is to describe the capabilities which are defined by OpenStack Service (Compute Service,</div><div>Storage Service, Network Service etc.) and by users. The ResourceProvider provide resource exposed by a single</div><div>compute node, some shared resource pool or an external resource-providing service of some sort. As such,</div><div>ResourceProviderTags is also expected to describe the capabilities of single ResourceProvider or the capabilities of</div><div>ResourcePool.</div><div><br></div><div>The ResourceProviderTags is similar with ServersTags [0] which is implemented in the Nova. The only difference is</div><div>that the tags is attached to the ResourceProvider. The API endpoint will be " /ResourceProvider/{uuid}/tags", and it</div><div>will follow the API-WG guideline about Tags [1].</div><div><br></div><div>As the Tags are just strings, the meaning of Tag isn't defined by Scheduler. The meaning of Tag is defined by</div><div>OpenStack services or Users. The ResourceProviderTags will only be used for scheduling with a ResourceProviderTags</div><div>filter.</div><div><br></div><div>The ResourceProviderTags is very easy to cover the cases of single ResourceProvider, ResourcePool and</div><div>DynamicResouces. Let see those cases one by one.</div><div><br></div><div>For single ResourceProvider case, just see how Nova report ComputeNode's Capabilities. Firstly, Nova is expected</div><div>to define a standard way to describe the Capabilities which provided by Hypervisor or Hardware. Then those description</div><div>of Capabilities can be used across the Openstack deployment. So Nova will define a set of Tags. Those Tags should</div><div>be included with prefix to indicated that this is coming from Nova. Also the naming rule of prefix can be used to catalog</div><div>the Capabilities. For example, the capabilities can be defined as:</div><div><br></div><div> COMPUTE_HW_CAP_CPU_AVX</div><div> COMPUTE_HW_CAP_CPU_SSE</div><div> ....</div><div> COMPUTE_HV_CAP_LIVE_MIGRATION</div><div> COMPUTE_HV_CAP_LIVE_SNAPSHOT</div><div> ....</div><div><br></div><div>( The COMPUTE means this is coming from Nova. HW means this is hardware related Capabilities. HV means this is</div><div> capabilities of Hypervisor. But the catalog of Capabilities can be discussed separated. This propose focus on the</div><div> ResourceTags. We also have another idea about not using 'PREFIX' to manage the Tags. We can add attributes to the</div><div> Tags. Then we have more control on the Tags. This will describe separately in the bottom. )</div><div><br></div><div>Nova will create ResourceProvider for the compute node, and report the quantitative stuff, and report capabilities</div><div>by adding those defined tags to the ResourceProvider at same time. Then those Capabilities are exposed by Nova</div><div>automatically.</div><div><br></div><div>The capabilities of ComputeNode can be queried through the API "GET /ResourceProviders/{uuid}/tags".</div><div><br></div><div>For the ResourcePool case, let us use Shared Storage Pool as example. The different Storage Pool may have</div><div>different capabilities. Maybe one of Pool are using SSD. For expose that Capability, admin user can do as below:</div><div><br></div><div>1. Define the aggregates</div><div> $AGG_UUID=`openstack aggregate create r1rck0610`</div><div><br></div><div>2. Create resource pool for shared storage</div><div> $RP_UUID=`openstack resource-provider create "/mnt/nfs/row1racks0610/" \</div><div> --aggregate-uuid=$AGG_UUID`</div><div> </div><div>3. Update the capacity of shared storage</div><div> openstack resource-provider set inventory $RP_UUID \</div><div> --resource-class=DISK_GB \</div><div> --total=100000 --reserved=1000 \</div><div> --min-unit=50 --max-unit=10000 --step-size=10 \</div><div> --allocation-ratio=1.0</div><div> </div><div>4. Add the Capabilities of shared storage</div><div> openstack resource-provider add tags $RP_UUID --tag STORAGE_WITH_SSD</div><div><br></div><div>In this case, 'STORAGE_WITH_SSD' is defined by Admin user. This is the same with Quantitative, where there</div><div>isn't agent to report the Quantitative, neither the Qualitative. </div><div><br></div><div>This is also easy to cover the DynamicResource case. Thinking of Ironic, admin will create ResourcePool for</div><div>same hardware configuration bare-metal machines. Those machines will have the same set of capabilities. So</div><div>those capabilities will be added to the ResourcePool as tags, this is pretty same with SharedStoragePool case.</div><div><br></div><div>To expose cloud capabilities to users, there is one more API endpoint 'GET /ResourceProviders/Tags'. User can</div><div>get all the tags. Then user can know what kind of Capabilities the cloud provides. The query parameter</div><div>will allow user to filter the Tags by the prefix rules.</div><div><br></div><div>This propose is intended to be a solution of managing Capabilities in the scheduler with ResourceProvider. But yes,</div><div>look at how Nova implement the manage of Capabilities, this is just part of solution. The whole solution still needs needs</div><div>other propose (like [2]) to describe how to model capabilities inside the compute node and propose (like [3]) to</div><div>describe how to request capabilities.</div><div><br></div><div>Manage Tags with attributes</div><div>=====================</div><div>As described above, we add prefix to Tags to mark which service this Tag is coming from and which catalog or</div><div>namespaces of Capabilities this Tags belongs to. An alternative idea is adding attributes to the Tags. </div><div>We can use one attribute tags to mark the origin of capabilities: Which service this capability comes from, or is it a</div><div>user-defined tag. Another idea is to add an attribute to control the tag visibility. Some of Tags may not expected to</div><div>be usable by normal users. The third possible attribute is to mark the namespace of this tag to help group tags.</div><div>For example the prefix "HV" and "HW" can be managed in this way.Then we can query/manage those tags very</div><div>easily from database by attributes.</div><div><br></div><div>Reference</div><div>========</div><div> [0] <a href="http://specs.openstack.org/openstack/nova-specs/specs/newton/approved/tag-instances.html" target="_blank">http://specs.openstack.org/openstack/nova-specs/specs/newton/approved/tag-instances.html</a></div><div> [1] <a href="https://github.com/openstack/api-wg/blob/master/guidelines/tags.rst" target="_blank">https://github.com/openstack/api-wg/blob/master/guidelines/tags.rst</a></div><div> [2] <a href="https://review.openstack.org/286520" target="_blank">https://review.openstack.org/286520</a></div><div> [3] <a href="https://review.openstack.org/313784" target="_blank">https://review.openstack.org/313784</a><br></div></div>
</blockquote></div><br></div>