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
