It sounds like the only reasonable option we are left with right now is to

Even if we enabled/removed the backport, it would take time until users can
get their hands on a new cut of the stable branch.

We would need to be more diligent in the future and limit backports to just
bug fixes to prevent situations like this from occurring, or maybe we need
to have better the latter :)

My 2c

On 22 October 2014 05:56, Maru Newby <> wrote:

> We merged caching support for the metadata agent in juno, and backported
> to icehouse.  It was enabled by default in juno, but disabled by default in
> icehouse to satisfy the stable maint requirement of not changing functional
> behavior.
> While performance of the agent was improved with caching enabled, it
> regressed a reported 8x when caching was disabled [1].  This means that by
> default, the caching backport severely impacts icehouse Neutron's
> performance.
> So, what is the way forward?  We definitely need to document the problem
> for both icehouse and juno.  Is documentation enough?  Or can we enable
> caching by default in icehouse?  Or remove the backport entirely.
> There is also a proposal to replace the metadata agent’s use of the
> neutron client in favor of rpc [2].  There were comments on an old bug
> suggesting we didn’t want to do this [3], but assuming that we want this
> change in Kilo, is backporting even a possibility given that it implies a
> behavioral change to be useful?
> Thanks,
> Maru
> 1:
> 2:
> 3:
> _______________________________________________
> OpenStack-dev mailing list
OpenStack-dev mailing list

Reply via email to