Re: Merging CEP-15 to trunk

[Benedict]

Do you mean as part of a blocking review, or just in general?I don’t honestly understand the focus on ninja fixes or rebasing, in either context. Why would a project rebase its work until ready to merge? Why would you worry that a team well resourced with experienced contributors (30+yrs between them) don’t know how to work correctly with ninja fixes? These are all minor details, surely?I understand your concern around flaky tests, particularly since it seems other work has let some slip through. I don’t believe this is a blocking review concern, as it represents its own blocking requirement. I believe I have responded positively to this query already though?On 31 Jan 2023, at 01:46, Ekaterina Dimitrova  wrote:Benedict, Is it an issue to ask whether flaky tests will be addressed as per our project agreement? Or about ninja fixes and why a branch was not rebased during development? What did I miss? By the way I do not ask these questions to block anyone, even suggested to help with CI…it’s a pity this part was dismissed…  I can see that Caleb is handling the things around the merge ticket with high attention to the details as always. I can only thank him! At this point I see this thread mostly as - this is the first feature branch since quite some time, people are unsure about certain things - let’s see how we handle this for the next time to be more efficient and clear.  I think you already took some actions in your suggestion earlier today with the document around comments. On Mon, 30 Jan 2023 at 20:16, Benedict  wrote:Review should primarily ask: "is this correct?" and "could this be done differently (clearer, faster, more correct, etc)?" Blocking reviews especially, because why else would a reasonable contributor want to block progress?These questions can of course be asked of implementation details for any CEP. I have said before, a proposal to conduct a blocking review of this kind - if very late in my view - would be valid, though timeline would have to be debated.Reviewers with weaker aspirations have plenty of time available to them - two weeks have already passed, and another couple will likely yet (there isn't a rush). But it is novel to propose that such optional reviews be treated as blocking.On 30 Jan 2023, at 23:04, Henrik Ingo  wrote:Ooops, I missed copy pasting this reply into my previous email:On Fri, Jan 27, 2023 at 11:21 PM Benedict  wrote:I'm realizing in retrospect this leaves ambiguityAnother misreading at least of the intent of these clauses, is that they were to ensure that concerns about a design and approach are listened to, and addressed to the satisfaction of interested parties. It was essentially codifying the project’s long term etiquette around pieces of work with either competing proposals or fundamental concerns. It has historically helped to avoid escalation to vetoes, or reverting code after commit. It wasn’t intended that any reason might be invoked, as seems to have been inferred, and perhaps this should be clarified, though I had hoped it would be captured by the word “reasonable". Minor concerns that haven’t been caught by the initial review process can always be addressed in follow-up work, as is very common.Wouldn't you expect such concerns to at least partially now have been covered in  the CEP discussion, up front? I would expect at most at this stage someone could validate that the implementation follows the CEP. But I wouldn't expect a debate on competing approaches at this stage.henrik-- Henrik Ingoc. +358 40 569 7354 w. www.datastax.com      

Re: Merging CEP-15 to trunk

[Ekaterina Dimitrova]

Benedict, Is it an issue to ask whether flaky tests will be addressed as
per our project agreement? Or about ninja fixes and why a branch was not
rebased during development? What did I miss?

By the way I do not ask these questions to block anyone, even suggested to
help with CI…it’s a pity this part was dismissed…

 I can see that Caleb is handling the things around the merge ticket with
high attention to the details as always. I can only thank him!

At this point I see this thread mostly as - this is the first feature
branch since quite some time, people are unsure about certain things -
let’s see how we handle this for the next time to be more efficient and
clear.  I think you already took some actions in your suggestion earlier
today with the document around comments.

On Mon, 30 Jan 2023 at 20:16, Benedict  wrote:

> Review should primarily ask: "is this correct?" and "could this be done
> differently (clearer, faster, more correct, etc)?" Blocking reviews
> especially, because why else would a reasonable contributor want to block
> progress?
>
> These questions can of course be asked of implementation details for any
> CEP.
>
> I have said before, a proposal to conduct a blocking review of this kind -
> if very late in my view - would be valid, though timeline would have to be
> debated.
>
> Reviewers with weaker aspirations have plenty of time available to them -
> two weeks have already passed, and another couple will likely yet (there
> isn't a rush). But it is novel to propose that such optional reviews be
> treated as blocking.
>
> On 30 Jan 2023, at 23:04, Henrik Ingo  wrote:
>
> 
>
> Ooops, I missed copy pasting this reply into my previous email:
>
> On Fri, Jan 27, 2023 at 11:21 PM Benedict  wrote:
>
>> I'm realizing in retrospect this leaves ambiguity
>>
>>
>> Another misreading at least of the *intent* of these clauses, is that
>> they were to ensure that concerns about a *design and approach* are
>> listened to, and addressed to the satisfaction of interested parties. It
>> was essentially codifying the project’s long term etiquette around pieces
>> of work with either competing proposals or fundamental concerns. It has
>> historically helped to avoid escalation to vetoes, or reverting code after
>> commit.
>>
>> It wasn’t intended that *any* reason might be invoked, as seems to have
>> been inferred, and perhaps this should be clarified, though I had hoped it
>> would be captured by the word “reasonable". Minor concerns that haven’t
>> been caught by the initial review process can always be addressed in
>> follow-up work, as is very common.
>>
>>
> Wouldn't you expect such concerns to at least partially now have been
> covered in  the CEP discussion, up front? I would expect at most at this
> stage someone could validate that the implementation follows the CEP. But I
> wouldn't expect a debate on competing approaches at this stage.
>
> henrik
> --
>
> Henrik Ingo
>
> c. +358 40 569 7354
>
> w. www.datastax.com
>
>   
> 
> 
>
>

Re: Merging CEP-15 to trunk

[Benedict]

Review should primarily ask: "is this correct?" and "could this be done differently (clearer, faster, more correct, etc)?" Blocking reviews especially, because why else would a reasonable contributor want to block progress?These questions can of course be asked of implementation details for any CEP. I have said before, a proposal to conduct a blocking review of this kind - if very late in my view - would be valid, though timeline would have to be debated.Reviewers with weaker aspirations have plenty of time available to them - two weeks have already passed, and another couple will likely yet (there isn't a rush). But it is novel to propose that such optional reviews be treated as blocking.On 30 Jan 2023, at 23:04, Henrik Ingo  wrote:Ooops, I missed copy pasting this reply into my previous email:On Fri, Jan 27, 2023 at 11:21 PM Benedict  wrote:I'm realizing in retrospect this leaves ambiguityAnother misreading at least of the intent of these clauses, is that they were to ensure that concerns about a design and approach are listened to, and addressed to the satisfaction of interested parties. It was essentially codifying the project’s long term etiquette around pieces of work with either competing proposals or fundamental concerns. It has historically helped to avoid escalation to vetoes, or reverting code after commit. It wasn’t intended that any reason might be invoked, as seems to have been inferred, and perhaps this should be clarified, though I had hoped it would be captured by the word “reasonable". Minor concerns that haven’t been caught by the initial review process can always be addressed in follow-up work, as is very common.Wouldn't you expect such concerns to at least partially now have been covered in  the CEP discussion, up front? I would expect at most at this stage someone could validate that the implementation follows the CEP. But I wouldn't expect a debate on competing approaches at this stage.henrik-- Henrik Ingoc. +358 40 569 7354 w. www.datastax.com      

Re: Merging CEP-15 to trunk

[Ekaterina Dimitrova]

Yes, reviews can and they happen any time and anyone can do them if they
have time and interest before/after merge and anyone can raise questions or
concerns. It was happening before, it happens now, it will happen in the
future. The beauty of open source.

About this merge - I would  personally love to see everything rebased and
things rerun in CI which no one has a doubt it will happen. Benedict
already mentioned also the repeatable jobs will be used, thanks! (I know
how disappointing it can be to find a flaky test but it is way easier to
fix it while you are still on top of things, instead of, half year away for
example.)
I am not sure I understand this -
“ There exists test failures, but those are due to python-dtest not knowing
about the accord table breaking a few tests (blocker for trunk merge, it
means trunk dtest must now known about accord), or flaky tests that
committers tend to merge anyways (such as specific tests that fail often,
known issues, OS allocating of bind address, etc.)”
Do you plan to merge before fixing the tests? I am confused

I think Henrik brought an interesting point about releasable trunk. I don’t
think that we are yet there with the Jenkins issues, but we are getting
close and we strive for that, no?
My understanding at this point is:
1) we rebase and run CI, get final reviewer approval before a commit. I am
not saying it hasn’t happened with the Accord tickets,no, but I am still
not sure why the branch was not rebased to be honest. Probably there was
some reasoning I am just not familiar with it but I am definitely curious.
I find a lot of sense in agreeing in the future to keep feature branches
rebased when commits land there.
2) If we encounter new issues/flaky tests/review comments we unfortunately
get back to them and we fix them pre-commit on tickets. On the bright side,
again, it is way easier to fix them before things got in the mix and time
pass. And I believe this is the trunk agreement and the quality bar we try
to keep.
Also, knowing how you were always adhering strictly to two committers and
CI runs pre-commit to the feature branch plus Benedict’s explanation around
mainly additions of code, I don’t see any reason for anyone to be worried.
I am optimistic we will see very soon things landing in a good shape.

3) what is the story with the ninja fixes? Are they trivial ninja fixes as
Josh mentioned or additional small commits? Were they reviewed? Are they
going to be squashed? (Take these as honest questions, I just don’t know
the plan and I am trying to create my mental model). I will be happy to add
a section around ninja commits on our “how to commit page”

Unfortunately, I disagree that finding a bug long after something was
committed is the same as seeing one before commit. I see people on numerous
occasions fixing things and revising. It is frustrating and I can imagine
how after that much work around Accord people just want it in. But don’t
you want to close the lose ends earlier than later? Yes, you’d say this is
long-term committed but I am afraid if you are rebasing and squashing, I
still look at the situation in a bit different way. Just my experience with
Cassandra where constantly the most unexpected things fail me :-)

Interesting points around CI, I am wondering whether we want to run the
code in both systems before commit as Jenkins also runs packaging and burn
tests. I will be happy to help to push the branch into Jenkins or CircleCI
if help is needed. I don’t have time for a review but I don’t mind to help
revise the CI results and identify what is old and (hopefully nothing) what
is new.

Also, when the time approaches, shall we agree on a particular day and ask
people not to commit anything for a day or so maybe until you test and
commit? To give you the chance to wrap up without interruptions? I think it
will be nice to schedule something.

BR,
Ekaterina

On Mon, 30 Jan 2023 at 18:54, David Capwell  wrote:

> But during development, did you ever run nightly tests / all tests?
>
>
> I strongly recommend people I work with to use my script that modifies
> circle ci, which ops us into running all tests; I tend to see people use
> this as it makes CI faster, but has this by product as well.
>
> So yes, all tests should be run before merge.  There are examples of
> Jenkins only tests that are not run, but again this is due to existing
> limitations with Jenkins.
>
>
> On Jan 30, 2023, at 3:33 PM, Henrik Ingo  wrote:
>
> On Tue, Jan 31, 2023 at 1:28 AM David Capwell  wrote:
>
>> If the CI coverage isn't 100%, then we should just identify the gaps, and
>> focus on that while preparing to merge
>>
>>
>> It has 100% coverage that is done normally for trunk merges; which is a
>> pre-commit CI run in Circle OR Jenkins.
>>
>>
> Sure. And thanks.
>
> But during development, did you ever run nightly tests / all tests? I
> wouldn't want the night after merging to trunk to be the first time those
> are run.
>
> henrik
> --
>
> Henrik Ingo
>
> c. +358 40 

Re: Merging CEP-15 to trunk

[Ekaterina Dimitrova]

Yes, reviews can and they happen any time and anyone can do them if they
have time and interest before/after merge and anyone can raise questions or
concerns. It was happening before, it happens now, it will happen in the
future. The beauty of open source.

About this merge - I would  personally love to see everything rebased and
things rerun in CI which no one has a doubt it will happen. Benedict
already mentioned also the repeatable jobs will be used, thanks! (I know
how disappointing it can be to find a flaky test but it is way easier to
fix it while you are still on top of things, instead of, half year away for
example.)
I am not sure I understand this -
“ There exists test failures, but those are due to python-dtest not knowing
about the accord table breaking a few tests (blocker for trunk merge, it
means trunk dtest must now known about accord), or flaky tests that
committers tend to merge anyways (such as specific tests that fail often,
known issues, OS allocating of bind address, etc.)”
Do you plan to merge before fixing the tests? I am confused

I think Henrik brought an interesting point about releasable trunk. I don’t
think that we are yet there with the Jenkins issues, but we are getting
close and we strive for that, no?
My understanding at this point is:
1) we rebase and run CI, get final reviewer approval before a commit. I am
not saying it hasn’t happened with the Accord tickets,no, but I am still
not sure why the branch was not rebased to be honest. Probably there was
some reasoning I am just not familiar with it but I am definitely curious.
I find a lot of sense in agreeing in the future to keep feature branches
rebased when commits land there.
2) If we encounter new issues/flaky tests/review comments we unfortunately
get back to them and we fix them pre-commit on tickets. On the bright side,
again, it is way easier to fix them before things got in the mix and time
pass. And I believe this is the trunk agreement and the quality bar we try
to keep.
Also, knowing how you were always adhering strictly to two committers and
CI runs pre-commit to the feature branch plus Benedict’s explanation around
mainly additions of code, I don’t see any reason for anyone to be worried.
I am optimistic we will see very soon things landing in a good shape.

3) what is the story with the ninja fixes? Are they trivial ninja fixes as
Josh mentioned or additional small commits? Were they reviewed? Are they
going to be squashed? (Take these as honest questions, I just don’t know
the plan and I am trying to create my mental model). I will be happy to add
a section around ninja commits on our “how to commit page”

Unfortunately, I disagree that finding a bug long after something was
committed is the same as seeing one before commit. I see people on numerous
occasions fixing things and revising. It is frustrating and I can imagine
how after that much work around Accord people just want it in. But don’t
you want to close the lose ends earlier than later? Yes, you’d say this is
long-term committed but I am afraid if you are rebasing and squashing, I
still look at the situation in a bit different way. Just my experience with
Cassandra where constantly the most unexpected things fail me :-)

Interesting points around CI, I am wondering whether we want to run the
code in both systems before commit as Jenkins also runs packaging and burn
tests. I will be happy to help to push the branch into Jenkins or CircleCI
if help is needed. I don’t have time for a review but I don’t mind to help
revise the CI results and identify what is old and (hopefully nothing) what
is new.

Also, when the time approaches, shall we agree on a particular day and ask
people not to commit anything for a day or so maybe until you test and
commit? To give you the chance to wrap up without interruptions? I think it
will be nice to schedule something.

BR,
Ekaterina


On Mon, 30 Jan 2023 at 18:33, Henrik Ingo  wrote:

> On Tue, Jan 31, 2023 at 1:28 AM David Capwell  wrote:
>
>> If the CI coverage isn't 100%, then we should just identify the gaps, and
>> focus on that while preparing to merge
>>
>>
>> It has 100% coverage that is done normally for trunk merges; which is a
>> pre-commit CI run in Circle OR Jenkins.
>>
>>
> Sure. And thanks.
>
> But during development, did you ever run nightly tests / all tests? I
> wouldn't want the night after merging to trunk to be the first time those
> are run.
>
> henrik
> --
>
> Henrik Ingo
>
> c. +358 40 569 7354
>
> w. www.datastax.com
>
>   
> 
> 
>
>

Re: Merging CEP-15 to trunk

[David Capwell]

> But during development, did you ever run nightly tests / all tests?


I strongly recommend people I work with to use my script that modifies circle 
ci, which ops us into running all tests; I tend to see people use this as it 
makes CI faster, but has this by product as well.

So yes, all tests should be run before merge.  There are examples of Jenkins 
only tests that are not run, but again this is due to existing limitations with 
Jenkins.

> On Jan 30, 2023, at 3:33 PM, Henrik Ingo  wrote:
> 
> On Tue, Jan 31, 2023 at 1:28 AM David Capwell  > wrote:
>> If the CI coverage isn't 100%, then we should just identify the gaps, and 
>> focus on that while preparing to merge
> 
> It has 100% coverage that is done normally for trunk merges; which is a 
> pre-commit CI run in Circle OR Jenkins.
> 
> 
> Sure. And thanks.
> 
> But during development, did you ever run nightly tests / all tests? I 
> wouldn't want the night after merging to trunk to be the first time those are 
> run.
> 
> henrik
> -- 
> 
> Henrik Ingo
> c. +358 40 569 7354 
> w. www.datastax.com 
>        
>    

Re: Merging CEP-15 to trunk

[Henrik Ingo]

On Tue, Jan 31, 2023 at 1:28 AM David Capwell  wrote:

> If the CI coverage isn't 100%, then we should just identify the gaps, and
> focus on that while preparing to merge
>
>
> It has 100% coverage that is done normally for trunk merges; which is a
> pre-commit CI run in Circle OR Jenkins.
>
>
Sure. And thanks.

But during development, did you ever run nightly tests / all tests? I
wouldn't want the night after merging to trunk to be the first time those
are run.

henrik
-- 

Henrik Ingo

c. +358 40 569 7354

w. www.datastax.com

  
  

Re: Merging CEP-15 to trunk

[David Capwell]

> Does this mean there have also been nightly jenkins builds running? Is there 
> a history of such test results visible somewhere? If yes, I think that lends 
> a lot of credibility to the claim the process was as rigorous as it is for 
> trunk, and looking at the build history for a few minutes should put our 
> minds at ease. I can't see anything Accord related in Jenkins or Butler? But 
> perhaps there's a CircleCI dashboard somewhere?

The pre-commit process has been using Circle CI, this is due to limitations 
that have been impacting Jenkins (stability, resources, etc.).  Example JIRA 
https://issues.apache.org/jira/browse/CASSANDRA-18154 
 shows the CI results 
https://app.circleci.com/pipelines/github/dcapwell/cassandra/1793/workflows/0d9ffabd-8046-41e4-a19d-aee8da98ac00
 
.

There exists test failures, but those are due to python-dtest not knowing about 
the accord table breaking a few tests (blocker for trunk merge, it means trunk 
dtest must now known about accord), or flaky tests that committers tend to 
merge anyways (such as specific tests that fail often, known issues, OS 
allocating of bind address, etc.)

> If the CI coverage isn't 100%, then we should just identify the gaps, and 
> focus on that while preparing to merge


It has 100% coverage that is done normally for trunk merges; which is a 
pre-commit CI run in Circle OR Jenkins.

> On Jan 30, 2023, at 3:03 PM, Henrik Ingo  wrote:
> 
> Ooops, I missed copy pasting this reply into my previous email:
> 
> On Fri, Jan 27, 2023 at 11:21 PM Benedict  > wrote:
>> I'm realizing in retrospect this leaves ambiguity
> 
> Another misreading at least of the intent of these clauses, is that they were 
> to ensure that concerns about a design and approach are listened to, and 
> addressed to the satisfaction of interested parties. It was essentially 
> codifying the project’s long term etiquette around pieces of work with either 
> competing proposals or fundamental concerns. It has historically helped to 
> avoid escalation to vetoes, or reverting code after commit. 
> 
> It wasn’t intended that any reason might be invoked, as seems to have been 
> inferred, and perhaps this should be clarified, though I had hoped it would 
> be captured by the word “reasonable". Minor concerns that haven’t been caught 
> by the initial review process can always be addressed in follow-up work, as 
> is very common.
> 
> 
> Wouldn't you expect such concerns to at least partially now have been covered 
> in  the CEP discussion, up front? I would expect at most at this stage 
> someone could validate that the implementation follows the CEP. But I 
> wouldn't expect a debate on competing approaches at this stage.
> 
> henrik
> -- 
> 
> Henrik Ingo
> c. +358 40 569 7354 
> w. www.datastax.com 
>        
>    

Re: Intra-project dependencies

[David Capwell]

I took a stab at creating a patch that I think addresses most of the comments I 
saw in this thread, would love feedback in 
https://issues.apache.org/jira/browse/CASSANDRA-18204 


Given that the leading solution is git submodules I went down this path and 
fleshed out the things I saw in this thread.  I don’t think this patch is 100% 
perfect (been trying to figure out release logic to confirm) so would love to 
here places that I neglected or problem areas found!

> On Jan 20, 2023, at 6:48 AM, Mick Semb Wever  wrote:
> 
>  
> Both a git post-checkout and a build fail-fast will protect us here. But the 
> post-checkout will need to fail silently if the .git subdirectory doesn't 
> exist.
> 
> Correction: the build fail-fast will need to fail silently if the .git 
> subdirectory doesn't exist.
> 
> How will this work for users downloading source distributions?
> 
> It is presumed that the source found in the submodule is on the correct SHA. 
> The integrity checks are in place when creating and when voting on the source 
> tarball release. This means that the the build of the submodule has to be 
> part of the in-tree build (which I have assumed already).

Re: Merging CEP-15 to trunk

[Henrik Ingo]

Ooops, I missed copy pasting this reply into my previous email:

On Fri, Jan 27, 2023 at 11:21 PM Benedict  wrote:

> I'm realizing in retrospect this leaves ambiguity
>
>
> Another misreading at least of the *intent* of these clauses, is that
> they were to ensure that concerns about a *design and approach* are
> listened to, and addressed to the satisfaction of interested parties. It
> was essentially codifying the project’s long term etiquette around pieces
> of work with either competing proposals or fundamental concerns. It has
> historically helped to avoid escalation to vetoes, or reverting code after
> commit.
>
> It wasn’t intended that *any* reason might be invoked, as seems to have
> been inferred, and perhaps this should be clarified, though I had hoped it
> would be captured by the word “reasonable". Minor concerns that haven’t
> been caught by the initial review process can always be addressed in
> follow-up work, as is very common.
>
>
Wouldn't you expect such concerns to at least partially now have been
covered in  the CEP discussion, up front? I would expect at most at this
stage someone could validate that the implementation follows the CEP. But I
wouldn't expect a debate on competing approaches at this stage.

henrik
-- 

Henrik Ingo

c. +358 40 569 7354

w. www.datastax.com

  
  

Re: Merging CEP-15 to trunk

[Henrik Ingo]

Hi David

On Fri, Jan 27, 2023 at 10:11 PM David Capwell  wrote:

> I've learned that when I have defended the need (or right, if appealing to
> the Governance texts...) for contributors to be able to review a feature
> branch at the time it is merged to trunk - which for Accord is now - that a
> common reaction to this is that doing a review of Accord now might take
> months and would stall the Accord project for months if that is allowed.
>
>
> The way I have been reading this thread is not that “we don’t want the
> review as it slows us down” but more “the process is X, why are you asking
> for Y?”.  I believe I can speak for everyone working on Accord, we all want
> more reviewers and contributors!
>
>
I know the Accord team has all the time been open to and even invited
participation from other contributors. I believe what happened was simply
that some of us thought "the process is Y" and then were surprised to be
rejected when trying to do Y. I think this thread has already surfaced the
different assumptions and what might be the most meaningful consensus for
future similar projects.



> I think its fair to ask the question on if feature branches “should" have
> the same process as non-feature branches, but since that has not been
> called out and voted on they are expected to follow the same process; if
> people working on feature branches have not been following the same process
> that is currently an issue that needs to be addressed (In the case of
> Accord all contributors are Committers or PMC and same process has been
> followed as trunk).  The project doesn’t have a good history (at least
> recent history) of open development of features, most features are dumps
> from private sources, so there are learning/growing pains as we try to
> develop new features in the open.
>
>
Yup.




> On the  other hand, I can think of many things that a pair of fresh eyes
> can do at this point in reasonable time, like days or a couple weeks.
>
>
> I agree more eyes are better, but the conversation is on code that has
> already merged.  I know that many of us review code after it has been
> merged, and what we have been doing is filing follow up bugs/improvement
> requests as new work.  A simple example of this was when the trie memtables
> patch landed I reviewed code that was merged I think 2021 making memtables
> pluggable; I found a bug in it, showed the bug existed, and worked with the
> authors to get all this addressed.  Reviews after the fact are fine,
> common, and welcome in this project, but that has always sponsored new
> tickets and new work to address the feedback.
>
>
I believe Ekaterina was the first one to talk to me about the possibility
of reviewing post merge. I have to admit I have simply not taking it
seriously at the time. My background is perhaps in more corporate open
source development, and I have plenty of experience with situations where
even if an engineer, including myself sometimes, wanted to work on fixing
some technical debt, the employer's project management processes simply
wouldn't prioritize that work and it was left for years. Now that several
people have assured me that this is actually a thing in the Cassandra
project, I will try to embrace that option. It's certainly a nice tool to
not hold up the merge more than necessary.


On Fri, Jan 27, 2023 at 10:22 PM Josh McKenzie  wrote:

> I know that many of us review code after it has been merged, and what we
> have been doing is filing follow up bugs/improvement requests as new work.
>
> I think this is key. The code on the feature branch matches the same bar
> of quality / process that's on trunk, and it's trivially easy to checkout
> at the merge SHA and review the code in an IDE even after merge, raising
> questions with someone if you have concerns. If we were talking about
> merging this feature branch a week before a GA I could see why there'd be
> concern but we have a lot of calendar runway here.
>
>
Ah, this is a great perspective! I can immediately think of follow-up
thoughts...

1. Don't we follow a principle of always shippable trunk? This was actually
a reason why I sidelined the talk about post-merge review, because it
implies that the code wasn't "good enough"/perfect when it was first
merged. (But life is of course never that black and white.) Anyway... With
always shippable trunk, in theory it shouldn't make a difference whether
this is happening a week before GA or months before.

But, more importantly...

2. You and others are saying the Accord feature branch followed the same
principles as development on trunk. Does this mean there have also been
nightly jenkins builds running? Is there a history of such test results
visible somewhere? If yes, I think that lends a lot of credibility to the
claim the process was as rigorous as it is for trunk, and looking at the
build history for a few minutes should put our minds at ease. I can't see
anything Accord related in Jenkins or Butler? But perhaps there's a

Re: [ANNOUNCE] Evolving governance in the Cassandra Ecosystem

[Patrick McFadin]

This is really game-changing and an important change for the Cassandra
community. I would like to think that creating a governance structure like
this will help get more ecosystem projects under the umbrella of Apache
Cassandra.

Thank you PMC, for spending the time to create this very needed framework.

Patrick

On Mon, Jan 30, 2023 at 11:02 AM Jeff Jirsa  wrote:

> Usually requires an offer to donate from the current owner, an acceptance
> of that offer (PMC vote), and then the work to ensure that contributions
> are acceptable from a legal standpoint (e.g. like the incubator -
> https://incubator.apache.org/guides/transitioning_asf.html - "For
> contributions composed of patches from individual contributors, it is safe
> to import the code once the major contributors (by volume) have completed
> ICLAs or SGAs.").
>
>
>
> On Mon, Jan 30, 2023 at 10:53 AM German Eichberger via dev <
> dev@cassandra.apache.org> wrote:
>
>> Great news indeed. I am wondering what it would take to include projects
>> everyone is using like medusa, reaper, cassandra-ldap, etc. as a subproject.
>>
>> Thanks,
>> German
>> --
>> *From:* Francisco Guerrero 
>> *Sent:* Friday, January 27, 2023 9:46 AM
>> *To:* dev@cassandra.apache.org 
>> *Subject:* [EXTERNAL] Re: [ANNOUNCE] Evolving governance in the
>> Cassandra Ecosystem
>>
>> Great news! I'm very happy to see these changes coming soon.
>>
>> Thanks to everyone involved in this work.
>>
>> On 2023/01/26 21:21:01 Josh McKenzie wrote:
>> > The Cassandra PMC is pleased to announce that we're evolving our
>> governance procedures to better foster subprojects under the Cassandra
>> Ecosystem's umbrella. Astute observers among you may have noticed that the
>> Cassandra Sidecar is already a subproject of Apache Cassandra as of CEP-1 (
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fpages%2Fviewpage.action%3FpageId%3D95652224=05%7C01%7CGerman.Eichberger%40microsoft.com%7Cda65de0ac4d84d94c54708db008e897d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638104384430582894%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=xUbCe%2FQGgZq3Ynr42YQucMkOw1IZ67cONiQSnkZI7bk%3D=0)
>> and Cassandra-14395 (
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FCASSANDRASC-24=05%7C01%7CGerman.Eichberger%40microsoft.com%7Cda65de0ac4d84d94c54708db008e897d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638104384430582894%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=RdItVOzwVs865Xd%2Ff8ancwkTDJWKPosHlKgbl1uysMw%3D=0),
>> however up until now we haven't had any structure to accommodate raising
>> committers on specific subprojects or clarity on the addition or governance
>> of future subprojects.
>> >
>> > Further, with the CEP for the driver donation in motion (
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1e0SsZxjeTabzrMv99pCz9zIkkgWjUd4KL5Yp0GFzNnY%2Fedit%23heading%3Dh.xhizycgqxoyo=05%7C01%7CGerman.Eichberger%40microsoft.com%7Cda65de0ac4d84d94c54708db008e897d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638104384430582894%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=pUXo983DEHRBDtjGD%2FHaZnqc1uRwpS7tBkFkNF9Qfns%3D=0),
>> the need for a structured and sustainable way to expand the Cassandra
>> Ecosystem is pressing.
>> >
>> > We'll document these changes in the confluence wiki as well as the
>> sidecar as our first formal subproject after any discussion on this email
>> thread. The new governance process is as follows:
>> > -
>> >
>> > Subproject Governance
>> > 1. The Apache Cassandra PMC is responsible for governing the broad
>> Cassandra Ecosystem.
>> > 2. The PMC will vote on inclusion of new interested subprojects using
>> the existing procedural change vote process documented in the confluence
>> wiki (Super majority voting: 66% of votes must be in favor to pass.
>> Requires 50% participation of roll call).
>> > 3. New committers for these subprojects will be nominated and raised,
>> both at inclusion as a subproject and over time. Nominations can be brought
>> to priv...@cassandra.apache.org. Typically we're looking for a mix of
>> commitment and contribution to the community and project, be it through
>> code, documentation, presentations, or other significant engagement with
>> the project.
>> > 4. While the commit-bit is ecosystem wide, code modification rights and
>> voting rights (technical contribution, binding -1, CEP's) are granted per
>> subproject
>> >  4a. Individuals are trusted to exercise prudence and only commit
>> or claim binding votes on approved subprojects. Repeated violations of this
>> social contract will result in losing committer status.
>> >  4b. Members of the PMC have 

Re: [ANNOUNCE] Evolving governance in the Cassandra Ecosystem

[Jeff Jirsa]

Usually requires an offer to donate from the current owner, an acceptance
of that offer (PMC vote), and then the work to ensure that contributions
are acceptable from a legal standpoint (e.g. like the incubator -
https://incubator.apache.org/guides/transitioning_asf.html - "For
contributions composed of patches from individual contributors, it is safe
to import the code once the major contributors (by volume) have completed
ICLAs or SGAs.").



On Mon, Jan 30, 2023 at 10:53 AM German Eichberger via dev <
dev@cassandra.apache.org> wrote:

> Great news indeed. I am wondering what it would take to include projects
> everyone is using like medusa, reaper, cassandra-ldap, etc. as a subproject.
>
> Thanks,
> German
> --
> *From:* Francisco Guerrero 
> *Sent:* Friday, January 27, 2023 9:46 AM
> *To:* dev@cassandra.apache.org 
> *Subject:* [EXTERNAL] Re: [ANNOUNCE] Evolving governance in the Cassandra
> Ecosystem
>
> Great news! I'm very happy to see these changes coming soon.
>
> Thanks to everyone involved in this work.
>
> On 2023/01/26 21:21:01 Josh McKenzie wrote:
> > The Cassandra PMC is pleased to announce that we're evolving our
> governance procedures to better foster subprojects under the Cassandra
> Ecosystem's umbrella. Astute observers among you may have noticed that the
> Cassandra Sidecar is already a subproject of Apache Cassandra as of CEP-1 (
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fpages%2Fviewpage.action%3FpageId%3D95652224=05%7C01%7CGerman.Eichberger%40microsoft.com%7Cda65de0ac4d84d94c54708db008e897d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638104384430582894%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=xUbCe%2FQGgZq3Ynr42YQucMkOw1IZ67cONiQSnkZI7bk%3D=0)
> and Cassandra-14395 (
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FCASSANDRASC-24=05%7C01%7CGerman.Eichberger%40microsoft.com%7Cda65de0ac4d84d94c54708db008e897d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638104384430582894%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=RdItVOzwVs865Xd%2Ff8ancwkTDJWKPosHlKgbl1uysMw%3D=0),
> however up until now we haven't had any structure to accommodate raising
> committers on specific subprojects or clarity on the addition or governance
> of future subprojects.
> >
> > Further, with the CEP for the driver donation in motion (
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1e0SsZxjeTabzrMv99pCz9zIkkgWjUd4KL5Yp0GFzNnY%2Fedit%23heading%3Dh.xhizycgqxoyo=05%7C01%7CGerman.Eichberger%40microsoft.com%7Cda65de0ac4d84d94c54708db008e897d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638104384430582894%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=pUXo983DEHRBDtjGD%2FHaZnqc1uRwpS7tBkFkNF9Qfns%3D=0),
> the need for a structured and sustainable way to expand the Cassandra
> Ecosystem is pressing.
> >
> > We'll document these changes in the confluence wiki as well as the
> sidecar as our first formal subproject after any discussion on this email
> thread. The new governance process is as follows:
> > -
> >
> > Subproject Governance
> > 1. The Apache Cassandra PMC is responsible for governing the broad
> Cassandra Ecosystem.
> > 2. The PMC will vote on inclusion of new interested subprojects using
> the existing procedural change vote process documented in the confluence
> wiki (Super majority voting: 66% of votes must be in favor to pass.
> Requires 50% participation of roll call).
> > 3. New committers for these subprojects will be nominated and raised,
> both at inclusion as a subproject and over time. Nominations can be brought
> to priv...@cassandra.apache.org. Typically we're looking for a mix of
> commitment and contribution to the community and project, be it through
> code, documentation, presentations, or other significant engagement with
> the project.
> > 4. While the commit-bit is ecosystem wide, code modification rights and
> voting rights (technical contribution, binding -1, CEP's) are granted per
> subproject
> >  4a. Individuals are trusted to exercise prudence and only commit or
> claim binding votes on approved subprojects. Repeated violations of this
> social contract will result in losing committer status.
> >  4b. Members of the PMC have commit and voting rights on all
> subprojects.
> > 5. For each subproject, the PMC will determine a trio of PMC members
> that will be responsible for all PMC specific functions (release votes,
> driving CVE response, marketing, branding, policing marks, etc) on the
> subproject.
> > -
> >
> > Curious to see what thoughts we have as a community!
> >
> > Thanks!
> >
> > ~Josh
> >
>

Re: [ANNOUNCE] Evolving governance in the Cassandra Ecosystem

[German Eichberger via dev]

Great news indeed. I am wondering what it would take to include projects 
everyone is using like medusa, reaper, cassandra-ldap, etc. as a subproject.

Thanks,
German

From: Francisco Guerrero 
Sent: Friday, January 27, 2023 9:46 AM
To: dev@cassandra.apache.org 
Subject: [EXTERNAL] Re: [ANNOUNCE] Evolving governance in the Cassandra 
Ecosystem

Great news! I'm very happy to see these changes coming soon.

Thanks to everyone involved in this work.

On 2023/01/26 21:21:01 Josh McKenzie wrote:
> The Cassandra PMC is pleased to announce that we're evolving our governance 
> procedures to better foster subprojects under the Cassandra Ecosystem's 
> umbrella. Astute observers among you may have noticed that the Cassandra 
> Sidecar is already a subproject of Apache Cassandra as of CEP-1 
> (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fpages%2Fviewpage.action%3FpageId%3D95652224=05%7C01%7CGerman.Eichberger%40microsoft.com%7Cda65de0ac4d84d94c54708db008e897d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638104384430582894%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=xUbCe%2FQGgZq3Ynr42YQucMkOw1IZ67cONiQSnkZI7bk%3D=0)
>  and Cassandra-14395 
> (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FCASSANDRASC-24=05%7C01%7CGerman.Eichberger%40microsoft.com%7Cda65de0ac4d84d94c54708db008e897d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638104384430582894%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=RdItVOzwVs865Xd%2Ff8ancwkTDJWKPosHlKgbl1uysMw%3D=0),
>  however up until now we haven't had any structure to accommodate raising 
> committers on specific subprojects or clarity on the addition or governance 
> of future subprojects.
>
> Further, with the CEP for the driver donation in motion 
> (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1e0SsZxjeTabzrMv99pCz9zIkkgWjUd4KL5Yp0GFzNnY%2Fedit%23heading%3Dh.xhizycgqxoyo=05%7C01%7CGerman.Eichberger%40microsoft.com%7Cda65de0ac4d84d94c54708db008e897d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638104384430582894%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=pUXo983DEHRBDtjGD%2FHaZnqc1uRwpS7tBkFkNF9Qfns%3D=0),
>  the need for a structured and sustainable way to expand the Cassandra 
> Ecosystem is pressing.
>
> We'll document these changes in the confluence wiki as well as the sidecar as 
> our first formal subproject after any discussion on this email thread. The 
> new governance process is as follows:
> -
>
> Subproject Governance
> 1. The Apache Cassandra PMC is responsible for governing the broad Cassandra 
> Ecosystem.
> 2. The PMC will vote on inclusion of new interested subprojects using the 
> existing procedural change vote process documented in the confluence wiki 
> (Super majority voting: 66% of votes must be in favor to pass. Requires 50% 
> participation of roll call).
> 3. New committers for these subprojects will be nominated and raised, both at 
> inclusion as a subproject and over time. Nominations can be brought to 
> priv...@cassandra.apache.org. Typically we're looking for a mix of commitment 
> and contribution to the community and project, be it through code, 
> documentation, presentations, or other significant engagement with the 
> project.
> 4. While the commit-bit is ecosystem wide, code modification rights and 
> voting rights (technical contribution, binding -1, CEP's) are granted per 
> subproject
>  4a. Individuals are trusted to exercise prudence and only commit or 
> claim binding votes on approved subprojects. Repeated violations of this 
> social contract will result in losing committer status.
>  4b. Members of the PMC have commit and voting rights on all subprojects.
> 5. For each subproject, the PMC will determine a trio of PMC members that 
> will be responsible for all PMC specific functions (release votes, driving 
> CVE response, marketing, branding, policing marks, etc) on the subproject.
> -
>
> Curious to see what thoughts we have as a community!
>
> Thanks!
>
> ~Josh
>

Re: [DISCUSSION] Framework for Internal Collection Exposure and Monitoring API Alignment

[David Capwell]

> I *think* this is arguably true for a vtable / CQL-based solution as well 
> from the "you don't know how people are using your API" perspective.

Very fair point and think that justifies a different thread to talk about 
backwards compatibility for our tables (virtual and not); maybe we can lump 
together the JMX backwards compatibility conversation as well in that new 
thread.

> On Jan 28, 2023, at 4:09 PM, Josh McKenzie  wrote:
> 
> First off - thanks so much for putting in this effort Maxim! This is 
> excellent work.
> 
> Some thoughts on the CEP and responses in thread:
> 
>> Considering that JMX is usually not used and disabled in production 
>> environments for various performance and security reasons, the operator may 
>> not see the same picture from various of Dropwizard's metrics exporters and 
>> integrations as Cassandra's JMX metrics provide [1][2].
> I don't think this assertion is true. Cassandra is running in a lot of places 
> in the world, and JMX has been in this ecosystem for a long time; we need 
> data that is basically impossible to get to claim "JMX is usually not used in 
> C* environments in prod".
> 
>> I also wonder about if we should care about JMX?  I know many wish to 
>> migrate (its going to be a very long time) away from JMX, so do we need a 
>> wrapper to make JMX and vtables consistent?
> If we can move away from a bespoke vtable or JMX based implementation and 
> instead have a templatized solution each of these is generated from, that to 
> me is the superior option. There's little harm in adding new JMX endpoints 
> (or hell, other metrics framework integration?) as a byproduct of adding new 
> vtable exposed metrics; we have the same maintenance obligation to them as we 
> have to the vtables and if it generates from the same base data, we shouldn't 
> have any further maintenance burden due to its presence right?
> 
>> we wish to move away from JMX
> I do, and you do, and many people do, but I don't believe all people on the 
> project do. The last time this came up in slack the conclusion was "Josh 
> should go draft a CEP to chart out a path to moving off JMX while maintaining 
> backwards-compat w/existing JMX metrics for environments that are using them" 
> (so I'm excited to see this CEP pop up before I got to it! ;)). Moving to a 
> system that gives us a 0-cost way to keep JMX and vtable in sync over time on 
> new metrics seems like a nice compromise for folks that have built out 
> JMX-based maintenance infra on top of C*. Plus removing the boilerplate toil 
> on vtables. win-win.
> 
>> If we add a column to the end of the JMX row did we just break users?  
> I *think* this is arguably true for a vtable / CQL-based solution as well 
> from the "you don't know how people are using your API" perspective. Unless 
> we have clear guidelines about discretely selecting the columns you want from 
> a vtable and trust users to follow them, if people have brittle greedy 
> parsers pulling in all data from vtables we could very well break them as 
> well by adding a new column right? Could be wrong here; I haven't written 
> anything that consumes vtable metric data and maybe the obvious idiom in the 
> face of that is robust in the presence of column addition. /shrug
> 
> It's certainly more flexible and simpler to write to w/out detonating 
> compared to JMX, but it's still an API we'd be revving.
> 
> On Sat, Jan 28, 2023, at 4:24 PM, Ekaterina Dimitrova wrote:
>> Overall I have similar thoughts and questions as David.
>> 
>> I just wanted to add a reminder about this thread from last summer[1]. We 
>> already have issues with the alignment of JMX and Settings Virtual Table. I 
>> guess this is how Maxim got inspired to suggest this framework proposal 
>> which I want to thank him for! (I noticed he assigned CASSANDRA-15254)
>> 
>> Not to open the Pandora box, but to me the most important thing here is to 
>> come into agreement about the future of JMX and what we will do or not as a 
>> community. Also, how much time people are able to invest. I guess this will 
>> influence any directions to be taken here.
>> 
>> [1] 
>> https://lists.apache.org/thread/8mjcwdyqoobpvw2262bqmskkhs76pp69 
>> 
>> 
>> 
>> On Thu, 26 Jan 2023 at 12:41, David Capwell > > wrote:
>> I took a look and I see the result is an interface that looks like the 
>> vtable interface, that is then used by vtables and JMX?  My first thought is 
>> why not just use the vtable logic?
>> 
>> I also wonder about if we should care about JMX?  I know many wish to 
>> migrate (its going to be a very long time) away from JMX, so do we need a 
>> wrapper to make JMX and vtables consistent?  I am cool with something like 
>> the following
>> 
>> registerWithJMX(jmxName, query(“SELECT * FROM system_views.streaming”));
>> 
>> So if we want to have a JMX view that matches the table then that’s cool by 
>> me, but 

Re: [DISCUSSION] Framework for Internal Collection Exposure and Monitoring API Alignment

[Maxim Muzafarov]

First of all, I'd like to thank you all for the comments. It's crucial
for me to get the feedback considering the fact I'm limited in
discussing such details with anyone else :-)

We should start a new thread about the JMX deprecation for sure, but
let me make a few comments here as well.


In my past experience, we had some concerns using JMX on production
environments: there were some difficulties integrating JMX with the
internal role management security plugins, enabling JMX for exporting
metrics most of the time means exposing management commands we'd like
to avoid and maintaining an SSL-enabled JMX configuration requires
additional attention outside the accepted security system as a whole.
None of the above makes JMX a bad tool, but the valuable question here
is - if there was an alternative tool that offered the same level of
functionality, would the JMX tool still be used for production
environments? Of course, let's not forget Dropwizard's metrics and the
collection of reporters it offers (they do not recommend gathering
metrics through production environments [1]).

At the same time, as long as JMX maintenance remains simple, is
limited in the number of classes it implements, and offers the same
functionality as the other tools, it brings much more value to
deployments, especially in development and/or test environments. This
is one of the goals that I am trying to offer you in this enhancement
proposal.

This templatized solution over internal data collections is not
limited only to Virtual Table (vtable), or JMX interfaces,  I can
imagine plugins providing any other access points (REST API, etc.)
based on it.


Responding to design comments:


> why not just use the vtable logic?

Actually, I have some concerns here as well. I even found the example
in the source code [2], but in my opinion, this approach has some
drawbacks:

- It may have additional overhead parsing query statements;
- Such queries may flood the user's query history, so we have to
handle it somehow;
- JMX (or other interfaces) becomes tightly coupled to the vtable
implementation, making it difficult to change the latter;
- vtable has its own drawbacks, like building table metadata and
building the result set with the same column types requires some level
of abstraction to not repeat this for every table;

Considering everything above I came to a conclusion to create a
SystemView and ViewRow abstraction (probably the naming is not my best
talent).


> If we add a column to the end of the JMX row did we just break users?

To be honest, I didn't pay much attention to it, thinking it would be
safe to add a new regular column. As far as the current state of
virtual tables is concerned, there's nothing new here, but I'll invest
my time in it once we agree (and if) on the high-level details.


[1] https://metrics.dropwizard.io/4.2.0/manual/core.html#jmx
[2] 
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/SystemKeyspace.java#L614

On Mon, 30 Jan 2023 at 14:12, Claude Warren, Jr via dev
 wrote:
>
> Actually, Maxim's proposal does not depend on JMX being present or not.  What 
> the proposal does is make it easier to create/sync multiple presentations of 
> the same internal data:  Virtual Tables, JMX, Metrics, next year's  greatest 
> data presentation strategy.  Removing JMX from the mix just reduces the 
> number of implementations, it does not in any way invalidate or change the 
> proposal.
>
> On Mon, Jan 30, 2023 at 11:27 AM Ekaterina Dimitrova  
> wrote:
>>
>> +1 on starting that discussion, thank you for volunteering Benjamin!
>>
>> On Mon, 30 Jan 2023 at 4:59, Benjamin Lerer  wrote:
>>>
>>> It seems to me that the question that we need to answer, before Maxim puts 
>>> more effort into this work, is: what is the future of JMX?
>>> I agree that we have never been clear about that decision up to now. At 
>>> least now we have a reason to clarify that point.
>>>
>>> I can start a discussion about that if people agree?
>>>
>>> Le dim. 29 janv. 2023 à 10:14, Dinesh Joshi  a écrit :

 I’m also very interested in this area. I quickly skimmed the proposal and 
 IIUC it doesn’t call for moving away from JMX. Instead I think it’s making 
 it easier to expose metrics over various interfaces. Maxim please correct 
 me if I’m wrong in my understanding.

 I also second Josh’s point on JMX usage. I know it’s disabled in some 
 deployments but it is not common practice in most places.

 Dinesh

 On Jan 28, 2023, at 4:10 PM, Josh McKenzie  wrote:

 
 First off - thanks so much for putting in this effort Maxim! This is 
 excellent work.

 Some thoughts on the CEP and responses in thread:

 Considering that JMX is usually not used and disabled in production 
 environments for various performance and security reasons, the operator 
 may not see the same picture from various of Dropwizard's metrics 
 exporters and 

Re: [DISCUSSION] Framework for Internal Collection Exposure and Monitoring API Alignment

[Claude Warren, Jr via dev]

Actually, Maxim's proposal does not depend on JMX being present or not.
What the proposal does is make it easier to create/sync multiple
presentations of the same internal data:  Virtual Tables, JMX, Metrics,
next year's  greatest data presentation strategy.  Removing JMX from the
mix just reduces the number of implementations, it does not in any way
invalidate or change the proposal.

On Mon, Jan 30, 2023 at 11:27 AM Ekaterina Dimitrova 
wrote:

> +1 on starting that discussion, thank you for volunteering Benjamin!
>
> On Mon, 30 Jan 2023 at 4:59, Benjamin Lerer  wrote:
>
>> It seems to me that the question that we need to answer, before Maxim
>> puts more effort into this work, is: what is the future of JMX?
>> I agree that we have never been clear about that decision up to now. At
>> least now we have a reason to clarify that point.
>>
>> I can start a discussion about that if people agree?
>>
>> Le dim. 29 janv. 2023 à 10:14, Dinesh Joshi  a écrit :
>>
>>> I’m also very interested in this area. I quickly skimmed the proposal
>>> and IIUC it doesn’t call for moving away from JMX. Instead I think it’s
>>> making it easier to expose metrics over various interfaces. Maxim please
>>> correct me if I’m wrong in my understanding.
>>>
>>> I also second Josh’s point on JMX usage. I know it’s disabled in some
>>> deployments but it is not common practice in most places.
>>>
>>> Dinesh
>>>
>>> On Jan 28, 2023, at 4:10 PM, Josh McKenzie  wrote:
>>>
>>> 
>>> First off - thanks so much for putting in this effort Maxim! This is
>>> excellent work.
>>>
>>> Some thoughts on the CEP and responses in thread:
>>>
>>> *Considering that JMX is usually not used and disabled in production
>>> environments for various performance and security reasons, the operator may
>>> not see the same picture from various of Dropwizard's metrics exporters and
>>> integrations as Cassandra's JMX metrics provide [1][2].*
>>>
>>> I don't think this assertion is true. Cassandra is running in a *lot*
>>> of places in the world, and JMX has been in this ecosystem for a long time;
>>> we need data that is basically impossible to get to claim "JMX is usually
>>> not used in C* environments in prod".
>>>
>>> I also wonder about if we should care about JMX?  I know many wish to
>>> migrate (its going to be a very long time) away from JMX, so do we need a
>>> wrapper to make JMX and vtables consistent?
>>>
>>> If we can move away from a bespoke vtable or JMX based implementation
>>> and instead have a templatized solution each of these is generated from,
>>> that to me is the superior option. There's little harm in adding new JMX
>>> endpoints (or hell, other metrics framework integration?) as a byproduct of
>>> adding new vtable exposed metrics; we have the same maintenance obligation
>>> to them as we have to the vtables and if it generates from the same base
>>> data, we shouldn't have any further maintenance burden due to its presence
>>> right?
>>>
>>> we wish to move away from JMX
>>>
>>> I do, and you do, and many people do, but I don't believe *all* people
>>> on the project do. The last time this came up in slack the conclusion was
>>> "Josh should go draft a CEP to chart out a path to moving off JMX while
>>> maintaining backwards-compat w/existing JMX metrics for environments that
>>> are using them" (so I'm excited to see this CEP pop up before I got to it!
>>> ;)). Moving to a system that gives us a 0-cost way to keep JMX and vtable
>>> in sync over time on new metrics seems like a nice compromise for folks
>>> that have built out JMX-based maintenance infra on top of C*. Plus removing
>>> the boilerplate toil on vtables. win-win.
>>>
>>> If we add a column to the end of the JMX row did we just break users?
>>>
>>> I *think* this is arguably true for a vtable / CQL-based solution as
>>> well from the "you don't know how people are using your API" perspective.
>>> Unless we have clear guidelines about discretely selecting the columns you
>>> want from a vtable and trust users to follow them, if people have brittle
>>> greedy parsers pulling in all data from vtables we could very well break
>>> them as well by adding a new column right? Could be wrong here; I haven't
>>> written anything that consumes vtable metric data and maybe the obvious
>>> idiom in the face of that is robust in the presence of column addition.
>>> /shrug
>>>
>>> It's certainly more flexible and simpler to write to w/out detonating
>>> compared to JMX, but it's still an API we'd be revving.
>>>
>>> On Sat, Jan 28, 2023, at 4:24 PM, Ekaterina Dimitrova wrote:
>>>
>>> Overall I have similar thoughts and questions as David.
>>>
>>> I just wanted to add a reminder about this thread from last summer[1].
>>> We already have issues with the alignment of JMX and Settings Virtual
>>> Table. I guess this is how Maxim got inspired to suggest this framework
>>> proposal which I want to thank him for! (I noticed he assigned
>>> CASSANDRA-15254)
>>>
>>> Not to open the Pandora 

Re: Internal Documentation Contribution Guidance

[Benedict]

Apologies, I think it should be opened up for comments now.On 30 Jan 2023, at 11:29, Ekaterina Dimitrova  wrote:Thank you Benedict! Can you, please, give us comment access to the doc?On Mon, 30 Jan 2023 at 6:14, Benedict  wrote:During public and private discussions around CEP-15, it became apparent that we lack any guidance on internal documentation and commenting in the “style guide” - which I also propose we rename to “Contribution Guide” or “Contribution and Style Guide" to better describe the broader role it has taken on.I have put together a starting proposal to kick us off here: https://docs.google.com/document/d/1qt7xmvEAXm_w9ARb2lVutapB_3il2WWEWuq_zYlu_9sThere might also be some value in working on some more general guidance on processes like commit, review etc. that also came up. I haven’t tried to address these here, but if anyone wants to work on that I’d be happy to participate.

Re: Internal Documentation Contribution Guidance

[Ekaterina Dimitrova]

Thank you Benedict! Can you, please, give us comment access to the doc?

On Mon, 30 Jan 2023 at 6:14, Benedict  wrote:

> During public and private discussions around CEP-15, it became apparent
> that we lack any guidance on internal documentation and commenting in the
> “style guide” - which I also propose we rename to “Contribution Guide” or
> “Contribution and Style Guide" to better describe the broader role it has
> taken on.
>
> I have put together a starting proposal to kick us off here:
> https://docs.google.com/document/d/1qt7xmvEAXm_w9ARb2lVutapB_3il2WWEWuq_zYlu_9s
>
> There might also be some value in working on some more general guidance on
> processes like commit, review etc. that also came up. I haven’t tried to
> address these here, but if anyone wants to work on that I’d be happy to
> participate.
>
>

Re: [DISCUSSION] Framework for Internal Collection Exposure and Monitoring API Alignment

[Ekaterina Dimitrova]

+1 on starting that discussion, thank you for volunteering Benjamin!

On Mon, 30 Jan 2023 at 4:59, Benjamin Lerer  wrote:

> It seems to me that the question that we need to answer, before Maxim puts
> more effort into this work, is: what is the future of JMX?
> I agree that we have never been clear about that decision up to now. At
> least now we have a reason to clarify that point.
>
> I can start a discussion about that if people agree?
>
> Le dim. 29 janv. 2023 à 10:14, Dinesh Joshi  a écrit :
>
>> I’m also very interested in this area. I quickly skimmed the proposal and
>> IIUC it doesn’t call for moving away from JMX. Instead I think it’s making
>> it easier to expose metrics over various interfaces. Maxim please correct
>> me if I’m wrong in my understanding.
>>
>> I also second Josh’s point on JMX usage. I know it’s disabled in some
>> deployments but it is not common practice in most places.
>>
>> Dinesh
>>
>> On Jan 28, 2023, at 4:10 PM, Josh McKenzie  wrote:
>>
>> 
>> First off - thanks so much for putting in this effort Maxim! This is
>> excellent work.
>>
>> Some thoughts on the CEP and responses in thread:
>>
>> *Considering that JMX is usually not used and disabled in production
>> environments for various performance and security reasons, the operator may
>> not see the same picture from various of Dropwizard's metrics exporters and
>> integrations as Cassandra's JMX metrics provide [1][2].*
>>
>> I don't think this assertion is true. Cassandra is running in a *lot* of
>> places in the world, and JMX has been in this ecosystem for a long time; we
>> need data that is basically impossible to get to claim "JMX is usually not
>> used in C* environments in prod".
>>
>> I also wonder about if we should care about JMX?  I know many wish to
>> migrate (its going to be a very long time) away from JMX, so do we need a
>> wrapper to make JMX and vtables consistent?
>>
>> If we can move away from a bespoke vtable or JMX based implementation and
>> instead have a templatized solution each of these is generated from, that
>> to me is the superior option. There's little harm in adding new JMX
>> endpoints (or hell, other metrics framework integration?) as a byproduct of
>> adding new vtable exposed metrics; we have the same maintenance obligation
>> to them as we have to the vtables and if it generates from the same base
>> data, we shouldn't have any further maintenance burden due to its presence
>> right?
>>
>> we wish to move away from JMX
>>
>> I do, and you do, and many people do, but I don't believe *all* people
>> on the project do. The last time this came up in slack the conclusion was
>> "Josh should go draft a CEP to chart out a path to moving off JMX while
>> maintaining backwards-compat w/existing JMX metrics for environments that
>> are using them" (so I'm excited to see this CEP pop up before I got to it!
>> ;)). Moving to a system that gives us a 0-cost way to keep JMX and vtable
>> in sync over time on new metrics seems like a nice compromise for folks
>> that have built out JMX-based maintenance infra on top of C*. Plus removing
>> the boilerplate toil on vtables. win-win.
>>
>> If we add a column to the end of the JMX row did we just break users?
>>
>> I *think* this is arguably true for a vtable / CQL-based solution as well
>> from the "you don't know how people are using your API" perspective. Unless
>> we have clear guidelines about discretely selecting the columns you want
>> from a vtable and trust users to follow them, if people have brittle greedy
>> parsers pulling in all data from vtables we could very well break them as
>> well by adding a new column right? Could be wrong here; I haven't written
>> anything that consumes vtable metric data and maybe the obvious idiom in
>> the face of that is robust in the presence of column addition. /shrug
>>
>> It's certainly more flexible and simpler to write to w/out detonating
>> compared to JMX, but it's still an API we'd be revving.
>>
>> On Sat, Jan 28, 2023, at 4:24 PM, Ekaterina Dimitrova wrote:
>>
>> Overall I have similar thoughts and questions as David.
>>
>> I just wanted to add a reminder about this thread from last summer[1]. We
>> already have issues with the alignment of JMX and Settings Virtual Table. I
>> guess this is how Maxim got inspired to suggest this framework proposal
>> which I want to thank him for! (I noticed he assigned CASSANDRA-15254)
>>
>> Not to open the Pandora box, but to me the most important thing here is
>> to come into agreement about the future of JMX and what we will do or not
>> as a community. Also, how much time people are able to invest. I guess this
>> will influence any directions to be taken here.
>>
>> [1]
>> https://lists.apache.org/thread/8mjcwdyqoobpvw2262bqmskkhs76pp69
>>
>>
>> On Thu, 26 Jan 2023 at 12:41, David Capwell  wrote:
>>
>> I took a look and I see the result is an interface that looks like the
>> vtable interface, that is then used by vtables and JMX?  My first thought
>> is 

Internal Documentation Contribution Guidance

[Benedict]

During public and private discussions around CEP-15, it became apparent that we 
lack any guidance on internal documentation and commenting in the “style guide” 
- which I also propose we rename to “Contribution Guide” or “Contribution and 
Style Guide" to better describe the broader role it has taken on.

I have put together a starting proposal to kick us off here: 
https://docs.google.com/document/d/1qt7xmvEAXm_w9ARb2lVutapB_3il2WWEWuq_zYlu_9s

There might also be some value in working on some more general guidance on 
processes like commit, review etc. that also came up. I haven’t tried to 
address these here, but if anyone wants to work on that I’d be happy to 
participate.

Re: [DISCUSSION] Framework for Internal Collection Exposure and Monitoring API Alignment

[Benjamin Lerer]

It seems to me that the question that we need to answer, before Maxim puts
more effort into this work, is: what is the future of JMX?
I agree that we have never been clear about that decision up to now. At
least now we have a reason to clarify that point.

I can start a discussion about that if people agree?

Le dim. 29 janv. 2023 à 10:14, Dinesh Joshi  a écrit :

> I’m also very interested in this area. I quickly skimmed the proposal and
> IIUC it doesn’t call for moving away from JMX. Instead I think it’s making
> it easier to expose metrics over various interfaces. Maxim please correct
> me if I’m wrong in my understanding.
>
> I also second Josh’s point on JMX usage. I know it’s disabled in some
> deployments but it is not common practice in most places.
>
> Dinesh
>
> On Jan 28, 2023, at 4:10 PM, Josh McKenzie  wrote:
>
> 
> First off - thanks so much for putting in this effort Maxim! This is
> excellent work.
>
> Some thoughts on the CEP and responses in thread:
>
> *Considering that JMX is usually not used and disabled in production
> environments for various performance and security reasons, the operator may
> not see the same picture from various of Dropwizard's metrics exporters and
> integrations as Cassandra's JMX metrics provide [1][2].*
>
> I don't think this assertion is true. Cassandra is running in a *lot* of
> places in the world, and JMX has been in this ecosystem for a long time; we
> need data that is basically impossible to get to claim "JMX is usually not
> used in C* environments in prod".
>
> I also wonder about if we should care about JMX?  I know many wish to
> migrate (its going to be a very long time) away from JMX, so do we need a
> wrapper to make JMX and vtables consistent?
>
> If we can move away from a bespoke vtable or JMX based implementation and
> instead have a templatized solution each of these is generated from, that
> to me is the superior option. There's little harm in adding new JMX
> endpoints (or hell, other metrics framework integration?) as a byproduct of
> adding new vtable exposed metrics; we have the same maintenance obligation
> to them as we have to the vtables and if it generates from the same base
> data, we shouldn't have any further maintenance burden due to its presence
> right?
>
> we wish to move away from JMX
>
> I do, and you do, and many people do, but I don't believe *all* people on
> the project do. The last time this came up in slack the conclusion was
> "Josh should go draft a CEP to chart out a path to moving off JMX while
> maintaining backwards-compat w/existing JMX metrics for environments that
> are using them" (so I'm excited to see this CEP pop up before I got to it!
> ;)). Moving to a system that gives us a 0-cost way to keep JMX and vtable
> in sync over time on new metrics seems like a nice compromise for folks
> that have built out JMX-based maintenance infra on top of C*. Plus removing
> the boilerplate toil on vtables. win-win.
>
> If we add a column to the end of the JMX row did we just break users?
>
> I *think* this is arguably true for a vtable / CQL-based solution as well
> from the "you don't know how people are using your API" perspective. Unless
> we have clear guidelines about discretely selecting the columns you want
> from a vtable and trust users to follow them, if people have brittle greedy
> parsers pulling in all data from vtables we could very well break them as
> well by adding a new column right? Could be wrong here; I haven't written
> anything that consumes vtable metric data and maybe the obvious idiom in
> the face of that is robust in the presence of column addition. /shrug
>
> It's certainly more flexible and simpler to write to w/out detonating
> compared to JMX, but it's still an API we'd be revving.
>
> On Sat, Jan 28, 2023, at 4:24 PM, Ekaterina Dimitrova wrote:
>
> Overall I have similar thoughts and questions as David.
>
> I just wanted to add a reminder about this thread from last summer[1]. We
> already have issues with the alignment of JMX and Settings Virtual Table. I
> guess this is how Maxim got inspired to suggest this framework proposal
> which I want to thank him for! (I noticed he assigned CASSANDRA-15254)
>
> Not to open the Pandora box, but to me the most important thing here is to
> come into agreement about the future of JMX and what we will do or not as a
> community. Also, how much time people are able to invest. I guess this will
> influence any directions to be taken here.
>
> [1]
> https://lists.apache.org/thread/8mjcwdyqoobpvw2262bqmskkhs76pp69
>
>
> On Thu, 26 Jan 2023 at 12:41, David Capwell  wrote:
>
> I took a look and I see the result is an interface that looks like the
> vtable interface, that is then used by vtables and JMX?  My first thought
> is why not just use the vtable logic?
>
> I also wonder about if we should care about JMX?  I know many wish to
> migrate (its going to be a very long time) away from JMX, so do we need a
> wrapper to make JMX and vtables