Re: [openstack-dev] [tc] Active or passive role with our database layer

On 05/23/2017 07:07 PM, Boris Pavlovic wrote: And how can someone, that is trying to deploy OpenStack, understand/find the right config for db? Or it's Ops tasks and community doesn't care about them? Neither. It's the ops responsibility to understand database configuration fundamentals

Re: [openstack-dev] [tc] Active or passive role with our database layer

Zane, > This is your periodic reminder that we have ~50 applications sharing the > same database and not only do none of them know how the deployer will > configure the database, most will not even have an idea which set of > assumptions the other ~49 are making about how the deployer will

Re: [openstack-dev] [tc] Active or passive role with our database layer

On 21/05/17 15:38, Monty Taylor wrote: One might argue that HA strategies are an operator concern, but in reality the set of workable HA strategies is tightly constrained by how the application works, and the pairing an application expecting one HA strategy with a deployment implementing a

Re: [openstack-dev] [tc] Active or passive role with our database layer

On 05/23/2017 03:16 PM, Edward Leafe wrote: On May 23, 2017, at 1:43 PM, Jay Pipes wrote: [1] Witness the join constructs in Golang in Kubernetes as they work around etcd not being a relational data store: Maybe it’s just me, but I found that Go code more

Re: [openstack-dev] [tc] Active or passive role with our database layer

On 05/23/2017 03:16 PM, Edward Leafe wrote: On May 23, 2017, at 1:43 PM, Jay Pipes wrote: [1] Witness the join constructs in Golang in Kubernetes as they work around etcd not being a relational data store: Maybe it’s just me, but I found that Go code more understandable

Re: [openstack-dev] [tc] Active or passive role with our database layer

On May 23, 2017, at 1:43 PM, Jay Pipes wrote: > [1] Witness the join constructs in Golang in Kubernetes as they work around > etcd not being a relational data store: Maybe it’s just me, but I found that Go code more understandable than some of the SQL we are using in the

Re: [openstack-dev] [tc] Active or passive role with our database layer

On Tue, 23 May 2017, Jay Pipes wrote: Err, in my experience, having a *completely* dumb persistence layer -- i.e. one that tries to assuage the differences between, say, relational and non-relational stores -- is a recipe for disaster. The developer just ends up writing join constructs in

Re: [openstack-dev] [tc] Active or passive role with our database layer

On 05/23/2017 07:23 AM, Chris Dent wrote: That "higher dev cost" is one of my objections to the 'active' approach but it is another implication that worries me more. If we limit deployer architecture choices at the persistence layer then it seems very likely that we will be tempted to build more

Re: [openstack-dev] [tc] Active or passive role with our database layer

On 05/23/2017 01:10 PM, Octave J. Orgeron wrote: Comments below.. On 5/21/2017 1:38 PM, Monty Taylor wrote: For example: An HA strategy using slave promotion and a VIP that points at the current write master paired with an application incorrectly configured to do such a thing can lead to

Re: [openstack-dev] [tc] Active or passive role with our database layer

Comments below.. On 5/21/2017 1:38 PM, Monty Taylor wrote: Hi all! As the discussion around PostgreSQL has progressed, it has come clear to me that there is a decently deep philosophical question on which we do not currently share either definition or agreement. I believe that the lack of

Re: [openstack-dev] [tc] Active or passive role with our database layer

On Tue, 23 May 2017, Sean Dague wrote: Do you have an example of an Open Source project that (after it was widely deployed) replaced their core storage engine for their existing users? That's not the point here. The point is that new deployments may choose to use a different one and old ones

Re: [openstack-dev] [tc] Active or passive role with our database layer

On 05/23/2017 07:23 AM, Chris Dent wrote: >> Some operations have one and only one "right" way to be done. For >> those operations if we take an 'active' approach, we can implement >> them once and not make all of our deployers and distributors each >> implement and run them. However, there is a

Re: [openstack-dev] [tc] Active or passive role with our database layer

On Sun, 21 May 2017, Monty Taylor wrote: As the discussion around PostgreSQL has progressed, it has come clear to me that there is a decently deep philosophical question on which we do not currently share either definition or agreement. I believe that the lack of clarity on this point is one

Re: [openstack-dev] [tc] Active or passive role with our database layer

On 05/21/2017 10:09 PM, Mike Bayer wrote: >> >> A similar issue lurks with the fact that MySQL unicode storage is >> 3-byte by default and 4-byte is opt-in. We could take the 'external' >> approach and document it and assume the operator has configured their >> my.cnf with the appropriate

Re: [openstack-dev] [tc] Active or passive role with our database layer

On 05/21/2017 03:38 PM, Monty Taylor wrote: documentation on the sequence of steps the operator should take. In the "active" approach, we still document expectations, but we also validate them. If they are not what we expect but can be changed at runtime, we change them overriding

[openstack-dev] [tc] Active or passive role with our database layer

Hi all! As the discussion around PostgreSQL has progressed, it has come clear to me that there is a decently deep philosophical question on which we do not currently share either definition or agreement. I believe that the lack of clarity on this point is one of the things that makes the