<div dir="ltr">Matt mentioned Aggregate in the scheduler meeting, that is good question and also reminder me I should explain the relationship between Aggregate and ResourceProviderTags.<div><br></div><div>The Aggregate is expected to keep as a tool for group the hosts, and just for group hosts. People used to manage Capabilities with Aggregates, they put the hosts with some kind of Capabilities into same Aggregates, and using the metadata to identify the Capabilities. But Aggregate with metadata is really not very easy to manage. </div><div><br></div><div>Thinking of the case:</div><div><br></div><div>Host1 have Capability1</div><div>Host2 have Capability1 and Capability2</div><div>Host3 have Capability2 and Capability3.</div><div><br></div><div>With this case, we needs 3 aggregates for each Capability: agg_cap1, agg_cap2, agg_cap3. Then we needs add hosts to the aggregate as below:</div><div><br></div><div>agg_cap1: host1, host2</div><div>agg_cap2: host2, host3</div><div>agg_cap3: host3</div><div><br></div><div>When there are more capabilities and more hosts which needs to manage, the mapping of hosts and aggregate will be more complicate. And there isn't a easy interface to let user to know the specific host have what kind of capabilities.</div><div><br></div><div>The ResourceProviderTags will be a substitution of Aggregate on manage capabilities. With tags, it won't generate a complex mapping. </div><div><br></div><div>For the same case, we just need to add tags on the ResourceProvider. The interface of tags is pretty easy, check out the api-wg guideline <a href="https://github.com/openstack/api-wg/blob/master/guidelines/tags.rst" target="_blank" style="font-size:14px">https://github.com/openstack/api-wg/blob/master/guidelines/tags.rst</a>. And the query parameter made the management easy.</div><div><br></div><div>There are also have some user want to write script to manage the Capabilities. Thinking the aggregate, the script will be very hard due to manage the mapping between aggregates and hosts. The script will be very easy with tags, due to tags just a set of string.</div><div><br></div></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>