> I guess our architecture is pretty unique in a way but I wonder if > other people are also a little scared about the whole all DB servers > need to up to serve API requests?
When we started down this path, we acknowledged that this would create a different access pattern which would require ops to treat the cell databases differently. The input we were getting at the time was that the benefits outweighed the costs here, and that we'd work on caching to deal with performance issues if/when that became necessary. > I’ve been thinking of some hybrid cellsv1/v2 thing where we’d still > have the top level api cell DB but the API would only ever read from > it. Nova-api would only write to the compute cell DBs. > Then keep the nova-cells processes just doing instance_update_at_top to keep > the nova-cell-api db up to date. I'm definitely not in favor of doing more replication in python to address this. What was there in cellsv1 was lossy, even for the subset of things it actually supported (which didn't cover all nova features at the time and hasn't kept pace with features added since, obviously). About a year ago, I proposed that we add another "read only mirror" field to the cell mapping, which nova would use if and only if the primary cell database wasn't reachable, and only for read operations. The ops, if they wanted to use this, would configure plain old one-way mysql replication of the cell databases to a highly-available server (probably wherever the api_db is) and nova could use that as a read-only cache for things like listing instances and calculating quotas. The reaction was (very surprisingly to me) negative to this option. It seems very low-effort, high-gain, and proper re-use of existing technologies to me, without us having to replicate a replication engine (hah) in python. So, I'm curious: does that sound more palatable to you? --Dan __________________________________________________________________________ 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