[jira] [Commented] (CASSANDRA-17544) Add EnableFlag to guardrails API

2022-05-06 Thread Jira 


[ 
https://issues.apache.org/jira/browse/CASSANDRA-17544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17533074#comment-17533074
 ] 

Andres de la Peña commented on CASSANDRA-17544:
---

Committed to {{trunk}} as 
[013acc641c5d487b07be5c082af1e85d26bd127f|https://github.com/apache/cassandra/commit/013acc641c5d487b07be5c082af1e85d26bd127f].

Thanks for the patch.

> Add EnableFlag to guardrails API
> 
>
> Key: CASSANDRA-17544
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17544
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Feature/Guardrails
>Reporter: Josh McKenzie
>Assignee: Bernardo Botella Corbi
>Priority: Low
> Fix For: 4.x
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Currently we only have a DisableFlag which, for guardrails where we're 
> enabling or disabling a feature, leads to some pretty odd ergonomics in the 
> code. For example:
>  
> {code:java}
> public static final DisableFlag compactTablesEnabled =
> new DisableFlag("compact_tables",
> state -> 
> !CONFIG_PROVIDER.getOrCreate(state).getCompactTablesEnabled(),
> "Creation of new COMPACT STORAGE tables"); {code}
> So far, the usage of these toggle flags appears to be skewed heavily towards 
> the inverse, or an EnableFlag that'd look something like this:
> {code:java}
> public static final EnableFlag featureEnabled = new 
> EnableFlag("feature_name", state -> 
> CONFIG_PROVIDER.getOrCreate(state).getCompactTablesEnabled(), "Text for 
> feature"); {code}
> While it's a relatively small change it'll help tidy up some of the 
> guardrails framework and make the logic clearer.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-17544) Add EnableFlag to guardrails API

2022-05-06 Thread Jira 


[ 
https://issues.apache.org/jira/browse/CASSANDRA-17544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17532789#comment-17532789
 ] 

Andres de la Peña commented on CASSANDRA-17544:
---

Running CI one last time before commit:
||Patch||CI||
|[trunk|https://github.com/adelapena/cassandra/commit/8cda8e6ffb8106168585cd2b6fcd7ca6cc64ec12]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1527/workflows/550363ae-af9a-46c9-a2e0-7b3f6aa79f9c]
 
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1527/workflows/78665199-6c78-45f7-9e51-6569eccbfe3c]|

I have moved the entry in {{CHANGES.txt}} to the section for 4.2, which is the 
current trunk. I've also fixed some trivial alignment issues on 
{{{}EnableFlag{}}}'s JavaDoc.

> Add EnableFlag to guardrails API
> 
>
> Key: CASSANDRA-17544
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17544
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Feature/Guardrails
>Reporter: Josh McKenzie
>Assignee: Bernardo Botella Corbi
>Priority: Low
> Fix For: 4.x
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Currently we only have a DisableFlag which, for guardrails where we're 
> enabling or disabling a feature, leads to some pretty odd ergonomics in the 
> code. For example:
>  
> {code:java}
> public static final DisableFlag compactTablesEnabled =
> new DisableFlag("compact_tables",
> state -> 
> !CONFIG_PROVIDER.getOrCreate(state).getCompactTablesEnabled(),
> "Creation of new COMPACT STORAGE tables"); {code}
> So far, the usage of these toggle flags appears to be skewed heavily towards 
> the inverse, or an EnableFlag that'd look something like this:
> {code:java}
> public static final EnableFlag featureEnabled = new 
> EnableFlag("feature_name", state -> 
> CONFIG_PROVIDER.getOrCreate(state).getCompactTablesEnabled(), "Text for 
> feature"); {code}
> While it's a relatively small change it'll help tidy up some of the 
> guardrails framework and make the logic clearer.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-17544) Add EnableFlag to guardrails API

2022-05-06 Thread Jira 


[ 
https://issues.apache.org/jira/browse/CASSANDRA-17544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17532774#comment-17532774
 ] 

Andres de la Peña commented on CASSANDRA-17544:
---

I'll commit it in a bit, only for {{trunk}}.

> Add EnableFlag to guardrails API
> 
>
> Key: CASSANDRA-17544
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17544
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Feature/Guardrails
>Reporter: Josh McKenzie
>Assignee: Bernardo Botella Corbi
>Priority: Low
> Fix For: 4.x
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Currently we only have a DisableFlag which, for guardrails where we're 
> enabling or disabling a feature, leads to some pretty odd ergonomics in the 
> code. For example:
>  
> {code:java}
> public static final DisableFlag compactTablesEnabled =
> new DisableFlag("compact_tables",
> state -> 
> !CONFIG_PROVIDER.getOrCreate(state).getCompactTablesEnabled(),
> "Creation of new COMPACT STORAGE tables"); {code}
> So far, the usage of these toggle flags appears to be skewed heavily towards 
> the inverse, or an EnableFlag that'd look something like this:
> {code:java}
> public static final EnableFlag featureEnabled = new 
> EnableFlag("feature_name", state -> 
> CONFIG_PROVIDER.getOrCreate(state).getCompactTablesEnabled(), "Text for 
> feature"); {code}
> While it's a relatively small change it'll help tidy up some of the 
> guardrails framework and make the logic clearer.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-17544) Add EnableFlag to guardrails API

2022-05-05 Thread Josh McKenzie (Jira) 


[ 
https://issues.apache.org/jira/browse/CASSANDRA-17544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17532501#comment-17532501
 ] 

Josh McKenzie commented on CASSANDRA-17544:
---

Looks good to merge (will need updated commit msg on squash of course). You 
want to handle that since you have the branch [~adelapena] or want me to?

Happy to take that on tomorrow morning if you're busy.

> Add EnableFlag to guardrails API
> 
>
> Key: CASSANDRA-17544
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17544
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Feature/Guardrails
>Reporter: Josh McKenzie
>Assignee: Bernardo Botella Corbi
>Priority: Low
> Fix For: 4.x
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Currently we only have a DisableFlag which, for guardrails where we're 
> enabling or disabling a feature, leads to some pretty odd ergonomics in the 
> code. For example:
>  
> {code:java}
> public static final DisableFlag compactTablesEnabled =
> new DisableFlag("compact_tables",
> state -> 
> !CONFIG_PROVIDER.getOrCreate(state).getCompactTablesEnabled(),
> "Creation of new COMPACT STORAGE tables"); {code}
> So far, the usage of these toggle flags appears to be skewed heavily towards 
> the inverse, or an EnableFlag that'd look something like this:
> {code:java}
> public static final EnableFlag featureEnabled = new 
> EnableFlag("feature_name", state -> 
> CONFIG_PROVIDER.getOrCreate(state).getCompactTablesEnabled(), "Text for 
> feature"); {code}
> While it's a relatively small change it'll help tidy up some of the 
> guardrails framework and make the logic clearer.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-17544) Add EnableFlag to guardrails API

2022-05-05 Thread Yifan Cai (Jira) 


[ 
https://issues.apache.org/jira/browse/CASSANDRA-17544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17532476#comment-17532476
 ] 

Yifan Cai commented on CASSANDRA-17544:
---

+1 on the patch.

> Add EnableFlag to guardrails API
> 
>
> Key: CASSANDRA-17544
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17544
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Feature/Guardrails
>Reporter: Josh McKenzie
>Assignee: Bernardo Botella Corbi
>Priority: Low
> Fix For: 4.x
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Currently we only have a DisableFlag which, for guardrails where we're 
> enabling or disabling a feature, leads to some pretty odd ergonomics in the 
> code. For example:
>  
> {code:java}
> public static final DisableFlag compactTablesEnabled =
> new DisableFlag("compact_tables",
> state -> 
> !CONFIG_PROVIDER.getOrCreate(state).getCompactTablesEnabled(),
> "Creation of new COMPACT STORAGE tables"); {code}
> So far, the usage of these toggle flags appears to be skewed heavily towards 
> the inverse, or an EnableFlag that'd look something like this:
> {code:java}
> public static final EnableFlag featureEnabled = new 
> EnableFlag("feature_name", state -> 
> CONFIG_PROVIDER.getOrCreate(state).getCompactTablesEnabled(), "Text for 
> feature"); {code}
> While it's a relatively small change it'll help tidy up some of the 
> guardrails framework and make the logic clearer.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-17544) Add EnableFlag to guardrails API

2022-05-05 Thread Jira 


[ 
https://issues.apache.org/jira/browse/CASSANDRA-17544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17532176#comment-17532176
 ] 

Andres de la Peña commented on CASSANDRA-17544:
---

CI with repeated runs after rebasing once again and adding [the missing 
{{@Test}} tag in 
{{GuardrailsTest#testEnableFlag}}|https://github.com/adelapena/cassandra/commit/24916dc27053847801ace1232106ef04f31f210c]:
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/1573]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1526/workflows/b0dd505d-8a85-4d64-8a79-e99de988615c]
 
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1526/workflows/9bff3132-61d5-4317-ace3-9d1651dc1fef]|

> Add EnableFlag to guardrails API
> 
>
> Key: CASSANDRA-17544
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17544
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Feature/Guardrails
>Reporter: Josh McKenzie
>Assignee: Bernardo Botella Corbi
>Priority: Low
> Fix For: 4.1
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Currently we only have a DisableFlag which, for guardrails where we're 
> enabling or disabling a feature, leads to some pretty odd ergonomics in the 
> code. For example:
>  
> {code:java}
> public static final DisableFlag compactTablesEnabled =
> new DisableFlag("compact_tables",
> state -> 
> !CONFIG_PROVIDER.getOrCreate(state).getCompactTablesEnabled(),
> "Creation of new COMPACT STORAGE tables"); {code}
> So far, the usage of these toggle flags appears to be skewed heavily towards 
> the inverse, or an EnableFlag that'd look something like this:
> {code:java}
> public static final EnableFlag featureEnabled = new 
> EnableFlag("feature_name", state -> 
> CONFIG_PROVIDER.getOrCreate(state).getCompactTablesEnabled(), "Text for 
> feature"); {code}
> While it's a relatively small change it'll help tidy up some of the 
> guardrails framework and make the logic clearer.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-17544) Add EnableFlag to guardrails API

2022-05-03 Thread Bernardo Botella Corbi (Jira) 


[ 
https://issues.apache.org/jira/browse/CASSANDRA-17544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17531403#comment-17531403
 ] 

Bernardo Botella Corbi commented on CASSANDRA-17544:


Posted the rebase. Please let me know if more changes are needed. Happy to help!

> Add EnableFlag to guardrails API
> 
>
> Key: CASSANDRA-17544
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17544
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Feature/Guardrails
>Reporter: Josh McKenzie
>Assignee: Bernardo Botella Corbi
>Priority: Low
> Fix For: 4.1
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Currently we only have a DisableFlag which, for guardrails where we're 
> enabling or disabling a feature, leads to some pretty odd ergonomics in the 
> code. For example:
>  
> {code:java}
> public static final DisableFlag compactTablesEnabled =
> new DisableFlag("compact_tables",
> state -> 
> !CONFIG_PROVIDER.getOrCreate(state).getCompactTablesEnabled(),
> "Creation of new COMPACT STORAGE tables"); {code}
> So far, the usage of these toggle flags appears to be skewed heavily towards 
> the inverse, or an EnableFlag that'd look something like this:
> {code:java}
> public static final EnableFlag featureEnabled = new 
> EnableFlag("feature_name", state -> 
> CONFIG_PROVIDER.getOrCreate(state).getCompactTablesEnabled(), "Text for 
> feature"); {code}
> While it's a relatively small change it'll help tidy up some of the 
> guardrails framework and make the logic clearer.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-17544) Add EnableFlag to guardrails API

2022-05-02 Thread Josh McKenzie (Jira) 


[ 
https://issues.apache.org/jira/browse/CASSANDRA-17544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17530843#comment-17530843
 ] 

Josh McKenzie commented on CASSANDRA-17544:
---

+1 here - great work [~bernardo.botella]. Definitely makes these guardrails a 
lot cleaner to reason about and use.

Could you rebase against trunk, integrate the new DisableFlag -> EnableFlag 
guardrail changes, and I'll push a copy of that branch up to my repo and 
trigger Circle on it?

[~adelapena] I think this is fine to land wherever really. trunk (i.e. 4.2+ 
now) is probably fine since it mostly cleans things up for people implementing 
new guardrails which should only happen on trunk anyway.

> Add EnableFlag to guardrails API
> 
>
> Key: CASSANDRA-17544
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17544
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Feature/Guardrails
>Reporter: Josh McKenzie
>Assignee: Bernardo Botella Corbi
>Priority: Low
> Fix For: 4.1
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Currently we only have a DisableFlag which, for guardrails where we're 
> enabling or disabling a feature, leads to some pretty odd ergonomics in the 
> code. For example:
>  
> {code:java}
> public static final DisableFlag compactTablesEnabled =
> new DisableFlag("compact_tables",
> state -> 
> !CONFIG_PROVIDER.getOrCreate(state).getCompactTablesEnabled(),
> "Creation of new COMPACT STORAGE tables"); {code}
> So far, the usage of these toggle flags appears to be skewed heavily towards 
> the inverse, or an EnableFlag that'd look something like this:
> {code:java}
> public static final EnableFlag featureEnabled = new 
> EnableFlag("feature_name", state -> 
> CONFIG_PROVIDER.getOrCreate(state).getCompactTablesEnabled(), "Text for 
> feature"); {code}
> While it's a relatively small change it'll help tidy up some of the 
> guardrails framework and make the logic clearer.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-17544) Add EnableFlag to guardrails API

2022-05-02 Thread Yifan Cai (Jira) 


[ 
https://issues.apache.org/jira/browse/CASSANDRA-17544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17530841#comment-17530841
 ] 

Yifan Cai commented on CASSANDRA-17544:
---

Agree. I think we can mark it as 4.x. It is to be merged with trunk only. 

> Add EnableFlag to guardrails API
> 
>
> Key: CASSANDRA-17544
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17544
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Feature/Guardrails
>Reporter: Josh McKenzie
>Assignee: Bernardo Botella Corbi
>Priority: Low
> Fix For: 4.1
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Currently we only have a DisableFlag which, for guardrails where we're 
> enabling or disabling a feature, leads to some pretty odd ergonomics in the 
> code. For example:
>  
> {code:java}
> public static final DisableFlag compactTablesEnabled =
> new DisableFlag("compact_tables",
> state -> 
> !CONFIG_PROVIDER.getOrCreate(state).getCompactTablesEnabled(),
> "Creation of new COMPACT STORAGE tables"); {code}
> So far, the usage of these toggle flags appears to be skewed heavily towards 
> the inverse, or an EnableFlag that'd look something like this:
> {code:java}
> public static final EnableFlag featureEnabled = new 
> EnableFlag("feature_name", state -> 
> CONFIG_PROVIDER.getOrCreate(state).getCompactTablesEnabled(), "Text for 
> feature"); {code}
> While it's a relatively small change it'll help tidy up some of the 
> guardrails framework and make the logic clearer.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-17544) Add EnableFlag to guardrails API

2022-04-29 Thread Jira 


[ 
https://issues.apache.org/jira/browse/CASSANDRA-17544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17530101#comment-17530101
 ] 

Andres de la Peña commented on CASSANDRA-17544:
---

[~jmckenzie] not sure this needs to be marked as 4.1, since it's a minor 
internal refactor and we can do it at any moment.

The proposed changes look good to me, although we need a rebase to integrate a 
couple of enable/disable flags that have been recently added, and then run CI.

> Add EnableFlag to guardrails API
> 
>
> Key: CASSANDRA-17544
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17544
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Feature/Guardrails
>Reporter: Josh McKenzie
>Assignee: Bernardo Botella Corbi
>Priority: Low
> Fix For: 4.1
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Currently we only have a DisableFlag which, for guardrails where we're 
> enabling or disabling a feature, leads to some pretty odd ergonomics in the 
> code. For example:
>  
> {code:java}
> public static final DisableFlag compactTablesEnabled =
> new DisableFlag("compact_tables",
> state -> 
> !CONFIG_PROVIDER.getOrCreate(state).getCompactTablesEnabled(),
> "Creation of new COMPACT STORAGE tables"); {code}
> So far, the usage of these toggle flags appears to be skewed heavily towards 
> the inverse, or an EnableFlag that'd look something like this:
> {code:java}
> public static final EnableFlag featureEnabled = new 
> EnableFlag("feature_name", state -> 
> CONFIG_PROVIDER.getOrCreate(state).getCompactTablesEnabled(), "Text for 
> feature"); {code}
> While it's a relatively small change it'll help tidy up some of the 
> guardrails framework and make the logic clearer.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-17544) Add EnableFlag to guardrails API

2022-04-18 Thread Bernardo Botella Corbi (Jira) 


[ 
https://issues.apache.org/jira/browse/CASSANDRA-17544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17523947#comment-17523947
 ] 

Bernardo Botella Corbi commented on CASSANDRA-17544:


Added a Pull request for the change.
||PR||
|[trunk|https://github.com/apache/cassandra/pull/1573]|

> Add EnableFlag to guardrails API
> 
>
> Key: CASSANDRA-17544
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17544
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Josh McKenzie
>Assignee: Bernardo Botella Corbi
>Priority: Normal
>
> Currently we only have a DisableFlag which, for guardrails where we're 
> enabling or disabling a feature, leads to some pretty odd ergonomics in the 
> code. For example:
>  
> {code:java}
> public static final DisableFlag compactTablesEnabled =
> new DisableFlag("compact_tables",
> state -> 
> !CONFIG_PROVIDER.getOrCreate(state).getCompactTablesEnabled(),
> "Creation of new COMPACT STORAGE tables"); {code}
> So far, the usage of these toggle flags appears to be skewed heavily towards 
> the inverse, or an EnableFlag that'd look something like this:
> {code:java}
> public static final EnableFlag featureEnabled = new 
> EnableFlag("feature_name", state -> 
> CONFIG_PROVIDER.getOrCreate(state).getCompactTablesEnabled(), "Text for 
> feature"); {code}
> While it's a relatively small change it'll help tidy up some of the 
> guardrails framework and make the logic clearer.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org