ImagePropertiesFilter has no default value resulting in unpredictable scheduling

[Mohammed Naser]

When using ImagePropertiesFilter for something like hardware architecture, it can cause very unpredictable behaviour because of the lack of default value.

In our case, a public cloud user will most likely upload an image without `hw_architecture` defined anywhere (as most instruction and general OpenStack documentation refers to).

However, in a case where there are multiple architectures available, the images tagged with a specific architecture will go towards hypervisors with that specific architecture. However, those which are not tagged will go to *any* hypervisor.

Because of how popular certain architectures are, it should be possible to be able to set a 'default' value for the architecture as it is the implied one, with the ability to override it if a user wants a specific one.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/566425

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/566425
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=aa5b1326c86c408ce9cc4546e1c7a310fbce3136
Submitter: Zuul
Branch: master

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.

    Change-Id: Ib52deb095028e93619b93ef9e5f70775df2a403a
    Closes-Bug: #1769283

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/queens
Review: https://review.openstack.org/568575

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/568575
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=ad332f3c635d887b163a8abe640d2a1b0da547fc
Submitter: Zuul
Branch: stable/queens

commit ad332f3c635d887b163a8abe640d2a1b0da547fc
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.

    Change-Id: Ib52deb095028e93619b93ef9e5f70775df2a403a
    Closes-Bug: #1769283
    (cherry picked from commit aa5b1326c86c408ce9cc4546e1c7a310fbce3136)

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/nova 17.0.5 release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/nova 18.0.0.0b2 development milestone.