Re: [openstack-dev] [gnocchi] regional incoming storage targets
On Thu, Jun 01, 2017 at 01:46:21PM +0200, Julien Danjou wrote: On Wed, May 31 2017, gordon chung wrote: […] i'm not entirely sure this is an issue, just thought i'd raise it to discuss. It's a really interesting point you raise. I never thought we could do that but indeed, we could. Maybe we built a great architecture after all. ;-) Easy solution: disable refresh. Problem solved. I have never liked this refresh feature on API side. -- Mehdi Abaakouk mail: sil...@sileht.net irc: sileht signature.asc Description: PGP signature __ 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] [gnocchi] regional incoming storage targets
On 01/06/17 07:46 AM, Julien Danjou wrote: > Yes, write doc or log an issue at least. It's best way to keep a public > track now on ideas and what's going on since it's what people are going > to read and search into. added here: https://github.com/gnocchixyz/gnocchi/issues/60 -- gord __ 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] [gnocchi] regional incoming storage targets
On Wed, May 31 2017, gordon chung wrote: […] > i'm not entirely sure this is an issue, just thought i'd raise it to > discuss. It's a really interesting point you raise. I never thought we could do that but indeed, we could. Maybe we built a great architecture after all. ;-) Easy solution: disable refresh. Problem solved. Also that means you could not push measures to the central API endpoint, or that'd be a problem. There might be a lot of little problem like that we need to solve. > regardless, thoughts on maybe writing up deployment strategies like > this? or make everyone who reads this to erase their minds and use this > for 'consulting' fees :P Yes, write doc or log an issue at least. It's best way to keep a public track now on ideas and what's going on since it's what people are going to read and search into. -- Julien Danjou -- Free Software hacker -- https://julien.danjou.info signature.asc Description: PGP signature __ 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] [gnocchi] regional incoming storage targets
here's a scenario: i'd like aggregates stored centrally like it does currently with ceph/swift/s3 drivers but i want to collect data from many different regions spanning globe. they can all hit the same incoming storage but: - that will be a hell of a lot of load - single incoming storage locality might not be optimal for all regions causing the write performance to take longer than needed for a 'cache' storage - sending HTTP POST with JSON payload probably more bandwidth than binary serialised format gnocchi uses internally. i'm thinking it'd be good to support ability to have each region store data 'locally' to minimise latency and then have regional metricd agents aggregate into a central target. this is technically possible right now by just declaring regional (write-only?) APIs with same storage target and indexer targets but a different incoming target per region. the problem i think is how to handle coordination_url. it cannot be the same coordination_url since that would cause sack locks to overlap. if they're different, then i think there's an issue with having a centralised API (in addition to regional APIs). specifically, the centralised API cannot 'refresh'. i'm not entirely sure this is an issue, just thought i'd raise it to discuss. regardless, thoughts on maybe writing up deployment strategies like this? or make everyone who reads this to erase their minds and use this for 'consulting' fees :P cheers, -- gord __ 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
