My understanding is same as from Ihar, and we no longer have the degradation in the latest Icehouse update. There was a degradation in 2014.1.2 [2] but the fix was backported in 2014.1.3 [1]. We don't need to take care of backporting when considering metadata RPC patch.
[1] https://review.openstack.org/#/c/120418/ [2] https://review.openstack.org/#/c/95491/ Thanks, Akihiro On Wed, Oct 22, 2014 at 7:24 PM, Ihar Hrachyshka <ihrac...@redhat.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 22/10/14 02:26, 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. > > If I correctly follow the degradation scenario, it's caused by > unneeded tokens requested from keystone each time a request hits > neutron metadata agent. This should be already fixed as [1] (included > in the latest 2014.1.3 release). > > [1]: https://review.openstack.org/#/c/118996/ > >> >> 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. > > If I'm correct, the issue is already solved in the latest Icehouse > release, so there seems to be no need to document the regression for > 2014.1.2. But yeah, sure we could put it in its release notes just in > case. > >> >> 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? > > We probably wouldn't consider backporting it to stable branches > because it touches RPC API, and we usually avoid it there. Anyway, it > shouldn't be an issue at all (as per my comment above). > >> >> 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 >> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > > iQEcBAEBCgAGBQJUR4XAAAoJEC5aWaUY1u57rYAH/jDqluduRLxwgHykP/NMIesj > 0MnesaiFwfeHdE5z3YEnteVkxEtkDRnmTRaau9TuOJpVrUfSIA7Lpa3S79Rv4cT5 > CC82FlU32fbOkCVFiXqgQvadNc3wrqHMag9FD6fpbg/MZlvV/VWHMl/z55rwhNh/ > yL+CzXd9uNgZy+ng0LI1EY+u9UcLtVwF8xhLhRIu5NMRim3HeRFlFUSN41ccemRJ > TdJUxMdtlYls/nCuIUk2QpSOZt1Hk2bysrBPh0etV501vsSHCq3cYZ3vjmt+jNX9 > thTKlsOaFpSLWnTn5+ERXk3y7pvJxo1AGOli3sLXIDYYNYPK4Y8PRYPLm43U45o= > =o7SU > -----END PGP SIGNATURE----- > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Akihiro Motoki <amot...@gmail.com> _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
