Very well written, David. Good points.
I am happy we are talking about all of this stuff and where the discussion
is going. TCM or not, I find it important we finally go through it all,
irrelevant what we eventually end up with.
I would like to add a few points, especially to your last two parag
Netflix solved the heterogeneous configuration issue really well.
Definitely the best I've seen.
With Spinnaker, you could set a config and override it at a DC, AZ or node
level. It would generate the C* yaml for you and plop it on the box, do
all the restarts etc. It was really convenient for t
> Stefan, global configuration and capabilities do have some overlap but not
> full overlap. For example, you may want to set globally that a cluster
> enables feature X or control the threshold for a guardrail but you still need
> to know if all nodes support feature X or have that guardrail, t
What about finally adding a much desired EverywhereStrategy? It wouldn't
just be useful for config - system_auth bites a lot of people today.
As much as I don't like to suggest row cache, it might be a good fit here
as well. We could remove the custom code around auth cache in the process.
Jon
The more we talk about this, the more my position crystallises against this
approach. The feature we’re discussing here should be easy to implement on top
of user facing functionality; we aren’t the only people who want functionality
like this. We should be dogfooding our own UX for this kind of
TCM was designed with a couple of very specific correctness-critical use
cases in mind, not as a generic mechanism for everyone to extend.
Its initial scope was for those use cases, but it’s potential for enabling more
sophisticated functionality was one of its selling points and is l
I think we can handle manual index selection controls independently of the
larger problem of query optimization.
Once I have time to get to know CEP-39 and the DS approach a little better,
I can open another thread here to start talking about those in the context
of the problems we need to solve.
> Would you mind elaborating on what makes it unsuitable? I don’t have a good
> mental model on its properties, so i assumed that it could be used to
> disseminate arbitrary key value pairs like config fairly easily.
It’s more than *capable* of disseminating arbitrary-ish key-value pairs - it
I agree that this would be useful, yes.
An LWT/Accord variant plus a plain writes eventually consistent variant. A
generic-by-design internal-only per-table mechanism with optional caching +
optional write notifications issued to non-replicas.
> On 6 Jan 2025, at 14:26, Josh McKenzie wrote:
>
> I think if we go down the route of pushing configs around with LWT + caching
> instead, we should have that be a generic system that is designed for
> everyone to use.
Agreed. Otherwise we end up with the same problem Aleksey's speaking about
above, where we build something for a specific pur
> I would like to remove this altogether from tests and ban it too in a week or
> two.
Don't think we had clear consensus here.
On Sun, Jan 5, 2025, at 5:42 PM, Štefan Miklošovič wrote:
> I would like to remove this altogether from tests and ban it too in a week or
> two.
>
> I see that Bereng
Would you mind elaborating on what makes it unsuitable? I don’t have a good
mental model on its properties, so i assumed that it could be used to
disseminate arbitrary key value pairs like config fairly easily.
Somewhat humorously, i think that same assumption was made when putting sai
metadata in
TCM was designed with a couple of very specific correctness-critical use cases
in mind, not as a generic mechanism for everyone to extend.
It might be *convenient* to employ TCM for some other features, which makes it
tempting to abuse TCM for an unintended purpose, but we shouldn’t do what's
c
13 matches
Mail list logo
