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 <ma...@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 . 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 . There were comments on an old bug > suggesting we didn’t want to do this , 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 > OpenStackfirstname.lastname@example.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev