Merge "Updates to image-metadata-prefiltering spec"
This commit is contained in:
commit
7fdc4dc094
|
@ -17,7 +17,7 @@ If the operator does not configure the ImagePropertiesFilter and an instance
|
|||
is scheduled to a host that cannot support the requested device model, a late
|
||||
check in the virt driver will fail the spawn and trigger a reschedule.
|
||||
If only a subset of hosts can support the requested device model this
|
||||
frequently results in a ``No valid host`` error.
|
||||
frequently results in a ``NoValidHost`` error.
|
||||
|
||||
This proposal suggests using standardised traits and placement to address
|
||||
device model compatibility by extending existing virt drivers to declare the
|
||||
|
@ -48,7 +48,7 @@ Proposed change
|
|||
|
||||
Step 1: Standard Traits
|
||||
-----------------------
|
||||
Well-defined image metadata properties that have a finite set of values
|
||||
Well-defined `image metadata properties`_ that have a finite set of values
|
||||
which represent virtualisation capabilities will be converted to standard
|
||||
traits.
|
||||
|
||||
|
@ -108,9 +108,9 @@ The current proposed set is
|
|||
},
|
||||
}
|
||||
|
||||
Note hw_cdrom_bus supports the same values as hw_disk_bus but is not
|
||||
documented. hw_cdrom_bus will also be supported by this spec.
|
||||
Other image properties that may also be worth considering are:
|
||||
Note ``hw_cdrom_bus`` supports the same values as ``hw_disk_bus`` but is not
|
||||
documented. ``hw_cdrom_bus`` will also be supported by this spec. Other image
|
||||
properties that may also be worth considering are:
|
||||
|
||||
.. code-block:: json
|
||||
|
||||
|
@ -147,14 +147,15 @@ Other image properties that may also be worth considering are:
|
|||
}
|
||||
|
||||
While this spec primarily targets the device model specific image metadata
|
||||
properties the same pattern could be applied to hypervisor_type and vm_mode.
|
||||
properties the same pattern could be applied to ``hypervisor_type`` and
|
||||
``vm_mode``.
|
||||
|
||||
Creation of the standard traits will be tracked using placement/os-traits
|
||||
storyboard now that it is extracted from Nova so discussion of how
|
||||
these traits will be named/namespaced will happen outside this spec.
|
||||
Creation of the standard traits will be tracked in a `placement/os-traits
|
||||
StoryBoard story <os-traits story_>`_. Discussion of how these traits will be
|
||||
named/namespaced will happen there rather than in this spec.
|
||||
|
||||
Step 2: Reporting Of Capablities By Virt Drivers
|
||||
------------------------------------------------
|
||||
Step 2: Reporting Of Capabilities By Virt Drivers
|
||||
-------------------------------------------------
|
||||
|
||||
This spec primarily targets extending the libvirt driver; however as
|
||||
these properties are also used by the vmware and fake drivers they will
|
||||
|
@ -163,7 +164,7 @@ also be extended.
|
|||
To enable this feature, the virt drivers will be extended to report traits
|
||||
for each device model they are capable of emulating on the compute node
|
||||
resource provider. This will be done by introspection of the libvirt version,
|
||||
qemu version, and Nova config such as CONF.virt_type.
|
||||
qemu version, and Nova config such as ``CONF.virt_type``.
|
||||
|
||||
To support upgrades without modifying existing images or flavors, the late
|
||||
checks for device model support in the virt driver will not be removed.
|
||||
|
@ -174,43 +175,44 @@ Step 3: Requesting A Device Model And Scheduling
|
|||
A new scheduler prefilter will be added to automatically add the new traits
|
||||
to requests. As adding new options to the device models requires a change to
|
||||
Nova anyway, and these get updated infrequently, we can just have a mapping
|
||||
table in a prefilter that added additional traits to the request spec by
|
||||
table in a prefilter that adds additional traits to the request spec by
|
||||
looking up the appropriate image metadata key and appending the traits to the
|
||||
request. This will not require changes to images to use the feature.
|
||||
unnumbered request group. This will not require changes to images to use the
|
||||
feature.
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
Operators can continue to use image property filters
|
||||
Operators can continue to use image property filters.
|
||||
|
||||
If the virt drivers are modified to report traits but a prefilter
|
||||
is not added, the existing ability to specify required traits in an image
|
||||
would be sufficient to consume the new traits, however, that would require
|
||||
would be sufficient to consume the new traits. However, that would require
|
||||
the image created to first specify the device model request and then also
|
||||
the required traits.
|
||||
e.g.
|
||||
hw_vif_model=e1000 traits:compute_net_model_e1000=required
|
||||
the required traits. E.g.
|
||||
``hw_vif_model=e1000, traits:COMPUTE_NET_MODEL_E1000=required``.
|
||||
This will work but it's verbose.
|
||||
|
||||
As with other recent features, we could use the traits request as a
|
||||
replacement for an image metadata property. If we chose this option we can
|
||||
deprecate the image metadata data values in train e.g. hw_vif_model
|
||||
replacement for an image metadata property. If we chose this option we could
|
||||
deprecate the image metadata data values (e.g. ``hw_vif_model``) in train
|
||||
and remove them in a later release. To use the feature and request a device
|
||||
model going forward a trait would be used
|
||||
e.g. traits:compute_net_model_e1000=required.
|
||||
While this may seem nicer in some respects its more typing then the selected
|
||||
option and has the disadvantage of requiring all image to be updated to include
|
||||
the traits request. As such this is discarded due to the upgrade impact.
|
||||
e.g. ``traits:COMPUTE_NET_MODEL_E1000=required``.
|
||||
While this may seem nicer in some respects it is more typing than the selected
|
||||
option and has the disadvantage of requiring all images to be updated to
|
||||
include the traits request. As such this is discarded due to the upgrade
|
||||
impact.
|
||||
|
||||
Operators can also achive the goals of this spec by manually creating nova host
|
||||
aggregates or placement aggregates, then mapping the images to aggregates using
|
||||
IsolatedHostsFilter or a aggregate member_of placement request.
|
||||
Operators can also achieve the goals of this spec by manually creating nova
|
||||
host aggregates or placement aggregates, then mapping the images to aggregates
|
||||
using IsolatedHostsFilter or an aggregate ``member_of`` placement request.
|
||||
|
||||
Data model impact
|
||||
-----------------
|
||||
|
||||
A new set of standard traits will be added to os-traits.
|
||||
no other data model change should be required.
|
||||
A `new set of standard traits will be added to os-traits <os-traits story_>`_.
|
||||
No other data model change should be required.
|
||||
|
||||
REST API impact
|
||||
---------------
|
||||
|
@ -244,8 +246,8 @@ Other deployer impact
|
|||
---------------------
|
||||
|
||||
A new config option will be added to enable the image metadata prefilter.
|
||||
Initally this will default to disabled but that can be change in future
|
||||
release after feedback on the performance impact.
|
||||
Initially this will default to disabled but that can be changed in a future
|
||||
release based on feedback on the performance impact.
|
||||
|
||||
Developer impact
|
||||
----------------
|
||||
|
@ -255,7 +257,7 @@ None
|
|||
Upgrade impact
|
||||
--------------
|
||||
|
||||
No action is required on upgrade however just as with new deployments
|
||||
No action is required on upgrade. However just as with new deployments
|
||||
if the operator wishes to enable this feature they will need to
|
||||
update the nova config to enable it after upgrading.
|
||||
|
||||
|
@ -274,12 +276,13 @@ Work Items
|
|||
- Add new traits
|
||||
- Modify libvirt virt driver to report traits
|
||||
- Write prefilter
|
||||
- Add config option
|
||||
- Tests
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
None
|
||||
`Additions in os-traits <os-traits story_>`_
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
@ -288,20 +291,25 @@ This can be tested entirely in the gate.
|
|||
Functional and unit tests will be added.
|
||||
|
||||
While tempest tests could be added, since we do not have a
|
||||
multinode gate job with different hyperviors tempest will
|
||||
multinode gate job with different hypervisors tempest will
|
||||
not be extended.
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
|
||||
A release note will be added and documentation of the new config option
|
||||
for the prefilter will be provided. As there is no enduser impact
|
||||
for the prefilter will be provided. As there is no end user impact
|
||||
no user facing documentation will be required.
|
||||
|
||||
References
|
||||
==========
|
||||
* `Glance Metadata Definitions Catalog namespaces <image metadata
|
||||
properties_>`_
|
||||
* `Additions in os-traits <os-traits story_>`_
|
||||
|
||||
None
|
||||
.. _`image metadata properties`:
|
||||
https://github.com/openstack/glance/tree/master/etc/metadefs
|
||||
.. _`os-traits story`: https://storyboard.openstack.org/#!/story/2005447
|
||||
|
||||
History
|
||||
=======
|
||||
|
|
Loading…
Reference in New Issue