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