[openstack-dev] [gnocchi] host field information flapping for instance resource-type
Hi all! We've been trying to get gnocchi working us, and have been hitting some performance bottlenecks. It seems that the 'host' field for the instance resource-type flaps between host id and host names. This makes the gnocchi dispatcher calls an update per resource which is a HTTP PATCH call. The large amount of HTTP calls causes gnocchi to be unable to keep up with ceilometer, essentially making it unworkable for us in production. I've tried removing this update code and can get ~5x the performance. So I guess the questions are, 1) why is the host information flapping? Are there difference services generating this data? 2) If gnocchi data can be viewable by the user, should we only have host id in the resource? (similar to what nova shows to user) 3) Anyone running gnocchi in prod, can you let us know how is it going? Any pointers to track down this issue will be appreciated! There is a bug[1] open for this issue but I hope this email can reach more people. FYI, we are running Mitaka ceilometer and gnocchi, but we have patched ceilometer to use the Newton gnocchi dispatcher to help with performance. [1] https://bugs.launchpad.net/ceilometer/+bug/1569037 Jake Yip, DevOps Engineer, Core Services, NeCTAR Research Cloud, The University of Melbourne __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [glance] allow a ranking mechanism for glance-api to order image locations
Thanks all for the interest. I have submitted a change at https://review.openstack.org/#/c/268865/. Please take a look and give your comments! (There are a few PEP errors that I'll be correcting...) Regards, Jake On Tue, Jan 19, 2016 at 4:41 AM, Steve Lewis wrote: > > > On Wed, Jan 13, 2016 at 4:07 PM, Jake Yip wrote: > >> >> I am wondering anyone else have solved this before? I would like to hear >> your opinions on how we can achieve this, and whether ranking it by >> metadata is the way to go. >> > > I spoke with an operator in Vancouver (Spring 2015 Summit) who wanted > similar functionality for his environment (relying on Ceph and Swift > storage with a multi-region cloud) and I believe this solution would > partially-satisfy his use case and could help close the functional gap. > > Thanks for bringing it up. I'm interested in helping see this delivered. > > -- > SteveL > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [glance] allow a ranking mechanism for glance-api to order image locations
Hi all, I've recently ran across a constraint in glance-api while working with image locations. In essence, there is no way to customize ordering of image-locations other than the default location strategies, namely location_order and store_type [0]. It seems like a more generic method of ordering image locations is needed, IMHO. Some background - We are in a multi-cell environment and each cell has it's own glance-api server. All images are stored in a global swift cluster. We would like glance to be able to fetch images from a local store, so that we can do COW for backends like RBD. Unfortunately, none of the current location strategies works for us, as we might have multiple cells sharing the same backend. I've opened a bug / wishlist describing this issue [1]. I have also implemented code that allows us to achieve that based on image location metadata. I am wondering anyone else have solved this before? I would like to hear your opinions on how we can achieve this, and whether ranking it by metadata is the way to go. The current wishlist is now tracked as a spec-lite. Is this ok? Regards, Jake [0] http://docs.openstack.org/liberty/config-reference/content/section_glance-api.conf.html [1] https://bugs.launchpad.net/glance/+bug/1528453 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
