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 (sinc
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 config
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 differ
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 than some of
the
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 than some of
the SQ
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 placement engine. :)
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 that
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
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 w
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 cl
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 c
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 c
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 o
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 default,
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 conflictin
15 matches
Mail list logo