On 10/22/2014 02:26 AM, 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: 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@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
I thought the performance regression was caused by wrong keystone token
caching leading to authentication per neutron client instance. Fix was
backported to Icehouse [1].

Does it mean this patch hasn't solved the problem and regression is
somewhere else?

Kuba

[1] https://review.openstack.org/#/c/120418/

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to