dcapwell commented on code in PR #3662:
URL: https://github.com/apache/cassandra/pull/3662#discussion_r1838476009
##########
src/java/org/apache/cassandra/config/AccordSpec.java:
##########
@@ -38,6 +38,20 @@ public class AccordSpec
public volatile boolean enable_journal_compaction = true;
+ /**
+ * Enables the virtual Accord debug keyspace with tables
+ * that expose internal state to aid the developers working
+ * on Accord implementation.
+ * <p/>
+ * These tables can and will change and/or go away at any point,
+ * including in a minor release, and are NOT to be relied on for anything.
+ * <p/>
+ * Only enable this keyspace if you are working on Accord and
+ * need to debug an issue with Accord implementation, or if an Accord
+ * developer asked you to.
+ */
+ public boolean enable_virtual_debug_keyspace = false;
Review Comment:
> But, it is helpful to expose these details to operators for human
interpretation of the cluster state only.
If the assumption is to expose this for operators, then operators will build
tools as manual work is a massive waste of operator time. So breaking the
table becomes a massive burden for operators, who you are saying are a target
audience.
If the audience is tests, then flagging on for tests and off for prod is
fine for me, we do this with system properties today.
> To my knowledge it is not project policy that virtual tables must be
consumable by applications,
at no point have I said "consumable by applications", I said "public api".
We have had a long stance that every table and every JMX is part of our public
API and we can not break. I have also said there is a desire and willingness
to define breakable tables, but we must do it in a way that actually documents
that tables are breakable, which is one of the main reasons the ML has focused
on how do we expose this detail to users / operators. If someone sees `debug`
do they think this can change at a moments notice, or that this is useful to
debug the issues you are facing? The focus on the ML has been the word
"experimental" as the focus was on tables not 100% ready for production, but
this patch wants a different definition, one I don't think anyone is opposed
to... my concern is articulating this to people, I want to avoid people being
blind sided by a breaking change.
Tl;DR - if this is for tests or people working on accord patches and won't
be enabled for prod, I am mostly fine, but still think a better config name
would help give this message.
If the audience is operations this then means enabled on prod, then I don't
think the config name or documentation tells operators what rules they should
expect around the API changing.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
