yahoo-eng-team team mailing list archive

[Andrew Bonney <1970619@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

As far as I can tell, when Horizon interacts with an OpenStack API via
the relevant client (for example Nova client), it currently instantiates
the client with a major version integer by default (for example '2')
unless a feature requires an explicit microversion (as identified in
https://github.com/openstack/horizon/blob/fcf3ae9365ac7f8f95a29dad0c611c7542746a58/openstack_dashboard/api/microversions.py#L29).

If a feature requires a specific microversion range, then the newest
microversion from that range will always be used, but for all other
requests the oldest available microversion will be used as opposed to
the most recent (v2.1 for Nova).

This has the unfortunate side effect of causing the majority of API
requests to miss out on potential improvements in the API. For example,
as discussed in https://bugs.launchpad.net/nova/+bug/1967314/comments/3,
a live migration to a specific host will bypass the Nova scheduler
filters and may end up on a host with inappropriate capabilities.

Is the use of the oldest supported API microversions a design decision,
or would it be possible to default to the most recent version? If this
is a design decision to maintain compatibility, are there any plans to
move the minimum version forward (considering for example in Nova where
there have been ~90 versions since the default)? Alternatively, would it
be preferred for cases such as the one highlighted above to be tackled
via additions to MICROVERSION_FEATURES, even though this relates to an
improvement rather than a brand new feature?

Tested against Horizon on Xena @ d69b1d414760eba09b19e432d67f82e91620d54

Thanks

** Affects: horizon
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1970619

Title:
  API clients prefer oldest available microversions rather than newest

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  As far as I can tell, when Horizon interacts with an OpenStack API via
  the relevant client (for example Nova client), it currently
  instantiates the client with a major version integer by default (for
  example '2') unless a feature requires an explicit microversion (as
  identified in
  https://github.com/openstack/horizon/blob/fcf3ae9365ac7f8f95a29dad0c611c7542746a58/openstack_dashboard/api/microversions.py#L29).

  If a feature requires a specific microversion range, then the newest
  microversion from that range will always be used, but for all other
  requests the oldest available microversion will be used as opposed to
  the most recent (v2.1 for Nova).

  This has the unfortunate side effect of causing the majority of API
  requests to miss out on potential improvements in the API. For
  example, as discussed in
  https://bugs.launchpad.net/nova/+bug/1967314/comments/3, a live
  migration to a specific host will bypass the Nova scheduler filters
  and may end up on a host with inappropriate capabilities.

  Is the use of the oldest supported API microversions a design
  decision, or would it be possible to default to the most recent
  version? If this is a design decision to maintain compatibility, are
  there any plans to move the minimum version forward (considering for
  example in Nova where there have been ~90 versions since the default)?
  Alternatively, would it be preferred for cases such as the one
  highlighted above to be tackled via additions to
  MICROVERSION_FEATURES, even though this relates to an improvement
  rather than a brand new feature?

  Tested against Horizon on Xena @
  d69b1d414760eba09b19e432d67f82e91620d54

  Thanks

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1970619/+subscriptions