yahoo-eng-team team mailing list archive

[Rodolfo Alonso <1672852@xxxxxxxxxxxxxxxxxx>]

Bug closed due to lack of activity, please feel free to reopen if
needed.

** Changed in: neutron
       Status: Triaged => Won't Fix

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1672852

Title:
  [RFE] Make controllers with different list of supported API extensions
  to behave identically

Status in neutron:
  Won't Fix

Bug description:
  The idea is to make controllers behave the same on API layer
  irrespective of the fact whether they, due to their different major
  versions, or because of different configuration files, support
  different lists of API extensions.

  The primary use case here is when controllers are upgraded in rolling
  mode, when you have different major versions running and probably
  serving API requests in round-robin implemented by a frontend load
  balancer. If version N exposes extensions A,B,C,D, while N+1 exposes
  A,B,C,D,E, then during upgrade when both versions are running, API
  /extensions/ endpoint should return [A,B,C,D]. After all controllers
  get to the new major version, they can switch to [A,B,C,D,E].

  This proposal implies there is mutual awareness of controller services
  about each other and their lists of supported extensions that will be
  achieved by storing lists in a new servers table, similar to agents
  tables we have.

  On service startup, controllers will discover information about other
  controllers from the table and load only those extensions that are
  supported by all controller peers. We may also introduce a mechanism
  where a signal triggers reload of extensions based on current table
  info state, or a periodic reloading thread that will look at the table
  e.g. every 60 seconds. (An alternative could be discovering that info
  on each API request, but that would be too consuming.)

  This proposal does not handle case where we drop an extension in a
  span of a single cycle (like replacing timestamp extension with
  timestamp_core). We may need to handle those cases by some other means
  (the easiest being not allowing such drastic in-place replacement of
  attribute format).

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