[openstack-dev] [neutron][stable] metadata agent performance

Armando M. armamig at gmail.com
Wed Oct 22 03:29:33 UTC 2014


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

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 testing...um...definitely the latter :)

My 2c
Armando

On 22 October 2014 05:56, Maru Newby <marun at redhat.com> 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: https://bugs.launchpad.net/cloud-archive/+bug/1361357
> 2: https://review.openstack.org/#/c/121782
> 3: https://bugs.launchpad.net/neutron/+bug/1092043
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141022/069d2029/attachment.html>


More information about the OpenStack-dev mailing list