f we're just LWT'ing things into
> distributed tables, doing something silly like CL_ALL, etc.
>
> +1, can we modularize/encapsulate the storage/dissemination backend needed
> for these features so they are pluggable ?
>
> I don't think either global co
rage/dissemination backend needed for these features so they are pluggable ? I don't think either global configuration or capabilities should be tied to the underlying storage/dissemination mechanism, this feels like an implementation detail.Ideally if this is well modularized, we can always pl
ething silly like CL_ALL, etc.
>
> +1, can we modularize/encapsulate the storage/dissemination backend needed
> for these features so they are pluggable ?
>
> I don't think either global configuration or capabilities should be tied
> to the underlying storage/dissemination mechani
uted tables, doing something silly like CL_ALL, etc.
>
> +1, can we modularize/encapsulate the storage/dissemination backend needed
> for these features so they are pluggable ?
>
> I don't think either global configuration or capabilities should be tied to
> the underlying st
s into
distributed tables, doing something silly like CL_ALL, etc.
+1, can we modularize/encapsulate the storage/dissemination backend needed
for these features so they are pluggable ?
I don't think either global configuration or capabilities should be tied to
the underlying storage/dissem
urpose, but we
>>>>>>> shouldn’t do what's convenient over what is right. There are several
>>>>>>> ways this often goes wrong.
>>>>>>>
>>>>>>> For example, the sybsystem gets used as is, without mo
;>>>>>>>> Jon
>>>>>>>>>
>>>>>>>>> On Mon, Jan 6, 2025 at 6:48 AM Aleksey Yeshchenko
>>>>>>>>> wrote:
>>>>>>>>>> TCM was designed with a couple of very specific cor
n, by a
>>> new feature, but in ways that invalidate the assumptions behind the design
>>> of the subsystem - designed for particular use cases.
>>>
>>> For another example, the subsystem *almost* works as is for the new
>>> feature, but doesn't *qu
; implementation. One of such changes eventually introduces a bug to the
>> shared critical subsystem, and now everyone is having a bad time.
>>
>> The risks are real, and I’d strongly prefer that we didn’t co-opt a
>> critical subsystem for a non-critical use-case for this
two paragraphs,
> in the context of guardrails and TCM, as that is what I was pushing before
> (maybe some of that is relevant to capabilities too).
>
> You are right about your YouFancyHuh example. In guardrails, that would
> translate to this:
>
> 1) 2 nodes cluster, both on ver
paragraphs,
in the context of guardrails and TCM, as that is what I was pushing before
(maybe some of that is relevant to capabilities too).
You are right about your YouFancyHuh example. In guardrails, that would
translate to this:
1) 2 nodes cluster, both on version X
2) We upgrade node 1 to version
ay that it needs to be addressed no matter where configs live.
Jon
On Mon, Jan 6, 2025 at 2:31 PM David Capwell wrote:
> 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 featur
> 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 th
e shouldn't touch the database at all otherwise,
> which isn't practical. That said, anything touching important subsystems
> needs more care, testing, and time to bake. I think we're mostly discussing
> "being careful" of which I am totally on board with. I don't think
entually introduces a bug to the
>>>>> shared critical subsystem, and now everyone is having a bad time.
>>>>>
>>>>> The risks are real, and I’d strongly prefer that we didn’t co-opt a
>>>>> critical subsystem for a non-critical use-cas
ime.
>>>>
>>>> The risks are real, and I’d strongly prefer that we didn’t co-opt a
>>>> critical subsystem for a non-critical use-case for this reason alone.
>>>>
>>>>> On 21 Dec 2024, at 23:18, Jordan West >>>>
;>>
>>>> I tend to lean towards Josh's perspective. Gossip was poorly tested and
>>>> implemented. I dont think it's a good parallel or at least I hope it's
>>>> not. Taken to the extreme we shouldn't touch the database at all
>
actical. That said, anything touching important subsystems
>>> needs more care, testing, and time to bake. I think we're mostly discussing
>>> "being careful" of which I am totally on board with. I don't think Benedict
>>> ever said "don't
shouldn't touch the database at all otherwise,
>>> which isn't practical. That said, anything touching important subsystems
>>> needs more care, testing, and time to bake. I think we're mostly discussing
>>> "being careful" of which I am totally
"being careful" of which I am totally on board with. I don't think Benedict
> ever said "don't use TCM", in fact he's said the opposite, but emphasized
> the care that is required when we do, which is totally reasonable.
>
> Back to capabilities, Riak bui
t; care, testing, and time to bake. I think we're mostly discussing "being
> careful" of which I am totally on board with. I don't think Benedict ever
> said "don't use TCM", in fact he's said the opposite, but emphasized the care
> that is require
hat is required when we do, which is totally reasonable.
Back to capabilities, Riak built them on an eventually consistent subsystem
and they worked fine. If you have a split brain you likely dont want to
communicate agreement as is (or have already learned about agreement and
its not an issue). That s
27;s point, the volume of information we're talking about here in terms of capabilities dissemination shouldn't stress TCM at all.I think a reasonable heuristic for relying on TCM for something is whether there's a big difference in UX on something being eventually consistent vs. stro
To play the devil's advocate - the more we exercise TCM the more bugs we suss
out. To Jon's point, the volume of information we're talking about here in
terms of capabilities dissemination shouldn't stress TCM at all.
I think a reasonable heuristic for relying on TCM for
ine. On Fri, Dec 20, 2024 at 7:22 PM Paulo Motta <pa...@apache.org> wrote:> It should be possible to use distributed system tables just fine for capabilities, config and guardrails.I have been thinking about this recently and I agree we should be wary about introducing new TCM states and cr
o do with what Jordan is trying to introduce. I think
>> we all agree he knows what he is doing and if he evaluates that TCM is too
>> much for his use case (or it is not a good fit) that is perfectly fine.
>>
>> On Fri, Dec 20, 2024 at 7:22 PM Paulo Motta wrote:
>>
&
his use case (or it is not a good fit) that is perfectly fine. On Fri, Dec 20, 2024 at 7:22 PM Paulo Motta <pa...@apache.org> wrote:> It should be possible to use distributed system tables just fine for capabilities, config and guardrails.I have been thinking about this recently and I ag
g and if he evaluates that TCM is too
>> much for his use case (or it is not a good fit) that is perfectly fine.
>>
>> On Fri, Dec 20, 2024 at 7:22 PM Paulo Motta wrote:
>>
>>> > It should be possible to use distributed system tables just fine for
>>>
Apologies I missed the forked thread "Re: Capabilities" before commenting
on this. I think the TCM-lite suggestion there is not incompatible with the
generic "In Maintenance" TCM state that I am proposing, since while in this
state each individual feature could also have their
...
>
> This has nothing to do with what Jordan is trying to introduce. I think we
> all agree he knows what he is doing and if he evaluates that TCM is too
> much for his use case (or it is not a good fit) that is perfectly fine.
>
> On Fri, Dec 20, 2024 at 7:22 PM Paulo Motta wrote
PM Paulo Motta wrote:
> > It should be possible to use distributed system tables just fine for
> capabilities, config and guardrails.
>
> I have been thinking about this recently and I agree we should be wary
> about introducing new TCM states and create additional comple
> It should be possible to use distributed system tables just fine for
capabilities, config and guardrails.
I have been thinking about this recently and I agree we should be wary
about introducing new TCM states and create additional complexity that can
be serviced by existing data disseminat
wrote:
> Benedict, I agree with you TCM might be overkill for capabilities. It’s
> truly something that’s fine to be eventually consistent. Riaks
> implementation used a local ETS table (ETS is built into Erlang -
> equivalent for us would a local only system table) and an efficient an
Benedict, I agree with you TCM might be overkill for capabilities. It’s
truly something that’s fine to be eventually consistent. Riaks
implementation used a local ETS table (ETS is built into Erlang -
equivalent for us would a local only system table) and an efficient and
reliable gossip protocol
ot; and _just works_.
>>
>> I think I was also investigating distributed tables but was just pulled
>> towards TCM naturally because of its goodies.
>>
>> On Fri, Dec 20, 2024 at 10:08 AM Benedict wrote:
>>
>>> TCM is a perfectly valid basis for this,
to solve meta config problems where we can’t rely on the rest of the database working. Particularly placement issues, which is why schema and membership need to live there.It should be possible to use distributed system tables just fine for capabilities, config and guardrails.That said, it’s possi
sis for this, but TCM is only really
>> *necessary* to solve meta config problems where we can’t rely on the rest
>> of the database working. Particularly placement issues, which is why schema
>> and membership need to live there.
>>
>> It should be possible to use distribu
to use distributed system tables just fine for capabilities, config and guardrails.That said, it’s possible config might be better represented as part of the schema (and we already store some relevant config there) in which case it would live in TCM automatically. Migrating existing configs to a dis
>
> It should be possible to use distributed system tables just fine for
> capabilities, config and guardrails.
>
> That said, it’s possible config might be better represented as part of the
> schema (and we already store some relevant config there) in which case it
> would live
tables just fine for capabilities, config and guardrails.That said, it’s possible config might be better represented as part of the schema (and we already store some relevant config there) in which case it would live in TCM automatically. Migrating existing configs to a distributed setup will be fun
guardrails CEP and you may
explore Capabilities CEP on TCM too, if that makes sense?
I just wanted to raise the point about the time this would be delivered. If
Capabilities are built on TCM and I wanted to do Guardrails on TCM too but
was explained it is probably too soon, I guess you would experience
Firstly, glad to see the support and enthusiasm here and in the recent
Slack discussion. I think there is enough for me to start drafting a CEP.
Stefan, global configuration and capabilities do have some overlap but not
full overlap. For example, you may want to set globally that a cluster
because we said so in TCM log so on restart / replay, a node with
"catch up" with whatever features it is asked to turn on.
Your approach seems to be that we distribute what all capabilities /
features a cluster supports and that each individual node configures itself
in some way or not to c
; > Nice stuff! I support this proposal and would be happy to help on this.
> >
> > On Wed, Dec 18, 2024 at 6:00 PM Jordan West > <mailto:jw...@apache.org>> wrote:
> >> In a recent discussion on the pains of upgrading one topic that came up is
> >> a feature
est <mailto:jw...@apache.org>> wrote:
>> In a recent discussion on the pains of upgrading one topic that came up is a
>> feature that Riak had called Capabilities [1]. A major pain with upgrades is
>> that each node independently decides when to start using new or modifie
Nice stuff! I support this proposal and would be happy to help on this.
On Wed, Dec 18, 2024 at 6:00 PM Jordan West wrote:
> In a recent discussion on the pains of upgrading one topic that came up is
> a feature that Riak had called Capabilities [1]. A major pain with upgrades
> is
ty of caveats including with streaming, schema, membership,
and sstable versions. We do have things like CASSANDRA-8110 and the storage
compatibility mode. If the capabilities concept helps us get there, that's
wonderful. It sounds like TCM will also help as a building block to make these
gt; Thanks for bringing this back, Jordan. I had completely forgotten
> > about Riak's Capabilities support. That was a fan favorite for
> > operators, along with a couple other interesting ways to control the
> > upgrade process.
> >
> > +1 on a CEP fro
+1 to the positive sentiment of such a feature. Huge benefit towards reducing
risks.
> On Dec 19, 2024, at 8:31 AM, Patrick McFadin wrote:
>
> Thanks for bringing this back, Jordan. I had completely forgotten
> about Riak's Capabilities support. That was a fan favorite for
&
Thanks for bringing this back, Jordan. I had completely forgotten
about Riak's Capabilities support. That was a fan favorite for
operators, along with a couple other interesting ways to control the
upgrade process.
+1 on a CEP from me.
On Thu, Dec 19, 2024 at 7:38 AM Josh McKenzie
Jordan West wrote:
>> In a recent discussion on the pains of upgrading one topic that came up is a
>> feature that Riak had called Capabilities [1]. A major pain with upgrades is
>> that each node independently decides when to start using new or modified
>> functio
n Wed, Dec 18, 2024 at 3:01 PM Jordan West wrote:
> In a recent discussion on the pains of upgrading one topic that came up is
> a feature that Riak had called Capabilities [1]. A major pain with upgrades
> is that each node independently decides when to start using new or modified
> fu
In a recent discussion on the pains of upgrading one topic that came up is
a feature that Riak had called Capabilities [1]. A major pain with upgrades
is that each node independently decides when to start using new or modified
functionality. Even when we put this behind a config (like storage
53 matches
Mail list logo
