commit aa5b1326c86c408ce9cc4546e1c7a310fbce3136
Author: Mohammed Naser <email address hidden>
Date: Fri May 4 21:06:46 2018 -0400
Added ability to configure default architecture for ImagePropertiesFilter
When using ImagePropertiesFilter with multiple architectures inside the
same deployment, it is possible that images can be uploaded without the
hw_architecture property defined.
This results in behaviour where the instance could be scheduled on any
type of hypervisor, resulting in an instance that will successfully
transition to ACTIVE but never properly run because of the difference
in architecture.
This makes the ImagePropertiesFilter problematic as most images are
generally uploaded without the architecture property set because
most documentation does not encourage doing that.
The addition of this flag allows to make using the filter possible
because it allows the deployer to assume a default architecture if
the user did not supply one (assuming it would be the most common
architecture in their deployment, such as x86_64) yet if the user
wants a more specific architecture, they can do it in their image
properties.
In order to avoid a circular import loop, the references to the
architecture field have been moved to a seperate module so that
they can be properly and cleaned imported inside configuration.
Reviewed: https:/ /review. openstack. org/566425 /git.openstack. org/cgit/ openstack/ nova/commit/ ?id=aa5b1326c86 c408ce9cc4546e1 c7a310fbce3136
Committed: https:/
Submitter: Zuul
Branch: master
commit aa5b1326c86c408 ce9cc4546e1c7a3 10fbce3136
Author: Mohammed Naser <email address hidden>
Date: Fri May 4 21:06:46 2018 -0400
Added ability to configure default architecture for ImageProperties Filter
When using ImageProperties Filter with multiple architectures inside the
same deployment, it is possible that images can be uploaded without the
hw_architecture property defined.
This results in behaviour where the instance could be scheduled on any
type of hypervisor, resulting in an instance that will successfully
transition to ACTIVE but never properly run because of the difference
in architecture.
This makes the ImageProperties Filter problematic as most images are
generally uploaded without the architecture property set because
most documentation does not encourage doing that.
The addition of this flag allows to make using the filter possible
because it allows the deployer to assume a default architecture if
the user did not supply one (assuming it would be the most common
architecture in their deployment, such as x86_64) yet if the user
wants a more specific architecture, they can do it in their image
properties.
In order to avoid a circular import loop, the references to the
architecture field have been moved to a seperate module so that
they can be properly and cleaned imported inside configuration.
Change-Id: Ib52deb095028e9 3619b93ef9e5f70 775df2a403a
Closes-Bug: #1769283