subject:"\[jira\] \[Comment Edited\] \(CASSANDRA\-15234\) Standardise config and JVM parameters"



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 1/13/22, 3:26 AM:
---

While rebasing and adding more parameters I hit a corner case, three duration 
parameters without unit suffixes which I personally don't think they need name 
change. That's fine. A converter was easy to add for them, BUT... what about 
Virtual tables? In order to support backward compatibility we currently list 
old parameters, those with new names are available in the old and the new form. 
For example:
{code:java}
memtable_heap_space   2018MiB
memtable_heap_space_in_mb    2018
{code}
The parameters that I personally didn't find a reason to change names but only 
the value formatting (adding the units to the value) are:

_key_cache_save_period, row_cache_save_period and counter_cache_save_period._ I 
can easily say we introduce a breaking change and leave those alone in the new 
format but I am open to hear also others' opinion. I feel I am getting too used 
to this work and I might be missing something. Also, IMHO it's worth it not to 
introduce breaking changes when/if possible.

In other news during the latest rebase and addition of parameters I found we 
need to improve the precision for the _DataRateSpec._ I will publish this in a 
separate patch soon, already handled.

I am doing last cleaning of tests and I will publish the final version with all 
latest changes from November until now for the reviewers' consideration. 

 


was (Author: e.dimitrova):
While rebasing and adding more parameters I hit a corner case, three duration 
parameters without unit suffixes which I personally don't think they need name 
change. That's fine. A converter was easy to add for them, BUT... what about 
Virtual tables? In order to support backward compatibility we currently list 
old parameters, those with new names are available in the old and the new form. 
For example:

 
{code:java}
memtable_heap_space   2018MiB
memtable_heap_space_in_mb    2018
{code}
The parameters that I personally didn't find a reason to change names but only 
the value formatting (adding the units to the value) are:

_key_cache_save_period, row_cache_save_period and counter_cache_save_period._ I 
can easily say we introduce a breaking change and leave those alone in the new 
format but I am open to hear also others' opinion. I feel I am getting too used 
to this work and I might be missing something. Also, IMHO it's worth it not to 
introduce breaking changes when/if possible.

In other news during the latest rebase and addition of parameters I found we 
need to improve the precision for the _DataRateSpec._ I will publish this in a 
separate patch soon, already handled.

I am doing last cleaning of tests and I will publish the final version with all 
latest changes from November until now for the reviewers' consideration. 

 

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for either 
> their old or new definition e.g. {{KiB/s}}, or we could support them and 
> simply log the value in bytes/s.



--
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

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 1/13/22, 3:25 AM:
---

While rebasing and adding more parameters I hit a corner case, three duration 
parameters without unit suffixes which I personally don't think they need name 
change. That's fine. A converter was easy to add for them, BUT... what about 
Virtual tables? In order to support backward compatibility we currently list 
old parameters, those with new names are available in the old and the new form. 
For example:

 
{code:java}
memtable_heap_space   2018MiB
memtable_heap_space_in_mb    2018
{code}
The parameters that I personally didn't find a reason to change names but only 
the value formatting (adding the units to the value) are:

_key_cache_save_period, row_cache_save_period and counter_cache_save_period._ I 
can easily say we introduce a breaking change and leave those alone in the new 
format but I am open to hear also others' opinion. I feel I am getting too used 
to this work and I might be missing something. Also, IMHO it's worth it not to 
introduce breaking changes when/if possible.

In other news during the latest rebase and addition of parameters I found we 
need to improve the precision for the _DataRateSpec._ I will publish this in a 
separate patch soon, already handled.

I am doing last cleaning of tests and I will publish the final version with all 
latest changes from November until now for the reviewers' consideration. 

 


was (Author: e.dimitrova):
While rebasing and adding more parameters I hit a corner case, three duration 
parameters without unit suffixes which I personally don't think they need name 
change. That's fine. A converter was easy to add for them, BUT... what about 
Virtual tables? In order to support backward compatibility we currently list 
old parameters, those with new names are available in the old and the new form. 
For example:

 
{code:java}
memtable_heap_space   2018MiB
meltable_heap_space_in_mb    2018
{code}
The parameters that I personally didn't find a reason to change names but only 
the value formatting (adding the units to the value) are:

_key_cache_save_period, row_cache_save_period and counter_cache_save_period._ I 
can easily say we introduce a breaking change and leave those alone in the new 
format but I am open to hear also others' opinion. I feel I am getting too used 
to this work and I might be missing something. Also, IMHO it's worth it not to 
introduce breaking changes when/if possible.

In other news during the latest rebase and addition of parameters I found we 
need to improve the precision for the _DataRateSpec._ I will publish this in a 
separate patch soon, already handled.

I am doing last cleaning of tests and I will publish the final version with all 
latest changes from November until now for the reviewers' consideration. 

 

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for either 
> their old or new definition e.g. {{KiB/s}}, or we could support them and 
> simply log the value in bytes/s.



--
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

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 1/13/22, 3:24 AM:
---

While rebasing and adding more parameters I hit a corner case, three duration 
parameters without unit suffixes which I personally don't think they need name 
change. That's fine. A converter was easy to add for them, BUT... what about 
Virtual tables? In order to support backward compatibility we currently list 
old parameters, those with new names are available in the old and the new form. 
For example:

 
{code:java}
memtable_heap_space   2018MiB
meltable_heap_space_in_mb    2018
{code}
The parameters that I personally didn't find a reason to change names but only 
the value formatting (adding the units to the value) are:

_key_cache_save_period, row_cache_save_period and counter_cache_save_period._ I 
can easily say we introduce a breaking change and leave those alone in the new 
format but I am open to hear also others' opinion. I feel I am getting too used 
to this work and I might be missing something. Also, IMHO it's worth it not to 
introduce breaking changes when/if possible.

In other news during the latest rebase and addition of parameters I found we 
need to improve the precision for the _DataRateSpec._ I will publish this in a 
separate patch soon, already handled.

I am doing last cleaning of tests and I will publish the final version with all 
latest changes from November until now for the reviewers' consideration. 

 


was (Author: e.dimitrova):
While rebasing and adding more parameters I hit a corner case, three duration 
parameters without unit suffixes which I personally don't think they need name 
change. That's fine. A converter was easy to add for them, BUT... what about 
Virtual tables? In order to support backward compatibility we currently list 
old parameters, those with new names are available in the old and the new form. 
For example:

 
{code:java}
memtable_heap_space   2018MiB
meltable_heap_space_in_mb    2018
{code}
The parameters that I personally didn't find a reason to change names but only 
the value formatting (adding the units to the value) are:

_key_cache_save_period, row_cache_save_period and counter_cache_save_period._ I 
can easily say we introduce a breaking change and leave those alone in the new 
format but I am open to hear also others' opinion. I feel I am getting too used 
to this work and I might be missing something. Also, IMHO it's worth it not to 
introduce breaking changes when/if possible.

In other news during the latest rebase and addition of parameters I found we 
need to improve the precision for the _DataRateSpec._ I will publish this in a 
separate patch soon.

I am doing last cleaning of tests and I will publish the final version with all 
latest changes from November until now for the reviewers' consideration. 

 

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for either 
> their old or new definition e.g. {{KiB/s}}, or we could support them and 
> simply log the value in bytes/s.



--
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

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 1/13/22, 3:24 AM:
---

While rebasing and adding more parameters I hit a corner case, three duration 
parameters without unit suffixes which I personally don't think they need name 
change. That's fine. A converter was easy to add for them, BUT... what about 
Virtual tables? In order to support backward compatibility we currently list 
old parameters, those with new names are available in the old and the new form. 
For example:

 
{code:java}
memtable_heap_space   2018MiB
meltable_heap_space_in_mb    2018
{code}
The parameters that I personally didn't find a reason to change names but only 
the value formatting (adding the units to the value) are:

_key_cache_save_period, row_cache_save_period and counter_cache_save_period._ I 
can easily say we introduce a breaking change and leave those alone in the new 
format but I am open to hear also others' opinion. I feel I am getting too used 
to this work and I might be missing something. Also, IMHO it's worth it not to 
introduce breaking changes when/if possible.

In other news during the latest rebase and addition of parameters I found we 
need to improve the precision for the _DataRateSpec._ I will publish this in a 
separate patch soon.

I am doing last cleaning of tests and I will publish the final version with all 
latest changes from November until now for the reviewers' consideration. 

 


was (Author: e.dimitrova):
While rebasing and adding more parameters I hit a corner case, three duration 
parameters without unit suffixes which I personally don't think they need name 
change. That's fine. A converter was easy to add for them, BUT... what about 
Virtual tables? In order to support backward compatibility we currently list 
old parameters, those with new names are available in the old and the new form. 
For example:

 
{code:java}
memtable_heap_space   2018MiB
meltable_heap_space_in_mb    2018
{code}
The parameters that I personally didn't find a reason to change names but only 
the value formatting (adding the units to the value) are:

_key_cache_save_period, row_cache_save_period and counter_cache_save_period._ I 
can easily say we introduce a breaking change and leave those alone in the new 
format but I am open to hear also others' opinion. I feel I am getting too used 
to this work and I might be missing something. Also, IMHO it's worth it not to 
introduce breaking changes when possible.

In other news during the latest rebase and addition of parameters I found we 
need to improve the precision for the _DataRateSpec._ I will publish this in a 
separate patch soon.

I am doing last cleaning of tests and I will publish the final version with all 
latest changes from November until now for the reviewers' consideration. 

 

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for either 
> their old or new definition e.g. {{KiB/s}}, or we could support them and 
> simply log the value in bytes/s.



--
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

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 1/6/22, 5:44 PM:
--

Moved back to 4.x as the patch has backward compatibility, introducing no 
breaking changes which aligns with our release discussions. 
{quote}we would probably save ourselves some UX trouble later on if we allow a 
single space between values and units. (ex. Allow both 10MiB and 10 MiB.)
{quote}
This is very easy to introduce but I think it is confusing to have both, 
similar to what we decided about the letter case. I would prefer to keep the 
current version only. Let me know what you think.
{quote}The second is trying, where possible, to leave the cases where we throw 
{{ConfigurationException}} intact. (This mostly applies to the cases where we 
might throw it via JMX, i.e. we have something of a contract at the moment.)
{quote}
Good point, I will handle it, thanks. 


was (Author: e.dimitrova):
Moved back to 4.x as the patch has backward compatibility, introducing no 
breaking changes which aligns with our release discussions. 
{quote}r on if we allow a single space between values and units. (ex. Allow 
both 10MiB and 10 MiB
{quote}
This is very easy to introduce but I think it is confusing to have both, 
similar to what we decided about the letter case. I would prefer to keep the 
current version only. Let me know what you think.
{quote}The second is trying, where possible, to leave the cases where we throw 
{{ConfigurationException}} intact. (This mostly applies to the cases where we 
might throw it via JMX, i.e. we have something of a contract at the moment.)
{quote}
Good point, I will handle it, thanks. 

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for either 
> their old or new definition e.g. {{KiB/s}}, or we could support them and 
> simply log the value in bytes/s.



--
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

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 1/6/22, 5:43 PM:
--

Moved back to 4.x as the patch has backward compatibility, introducing no 
breaking changes which aligns with our release discussions. 
{quote}r on if we allow a single space between values and units. (ex. Allow 
both 10MiB and 10 MiB
{quote}
This is very easy to introduce but I think it is confusing to have both, 
similar to what we decided about the letter case. I would prefer to keep the 
current version only. Let me know what you think.
{quote}The second is trying, where possible, to leave the cases where we throw 
{{ConfigurationException}} intact. (This mostly applies to the cases where we 
might throw it via JMX, i.e. we have something of a contract at the moment.)
{quote}
Good point, I will handle it, thanks. 


was (Author: e.dimitrova):
Moved back to 4.x as the patch has backward compatibility, introducing no 
breaking changes which aligns with our release discussions. 
{quote}r on if we allow a single space between values and units. (ex. Allow 
both {{10MiB }}and {{10 MiB}}
{quote}
This is very easy to introduce but I think it is confusing to have both, 
similar to what we decided about the letter case. I would prefer to keep the 
current version only. Let me know what you think.
{quote}bq. The second is trying, where possible, to leave the cases where we 
throw {{ConfigurationException}} intact. (This mostly applies to the cases 
where we might throw it via JMX, i.e. we have something of a contract at the 
moment.)
{quote}
Good point, I will handle it, thanks. 

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for either 
> their old or new definition e.g. {{KiB/s}}, or we could support them and 
> simply log the value in bytes/s.



--
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

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 1/6/22, 4:16 PM:
--

Thank you [~maedhroz] . I already addressed the first two commits review 
comments, I will address the third commit comments now. Then I will rebase on 
the latest changes from December and take care of the newest added config in a 
new commit. I will ping you when I am done. 
{quote}It's ok that the patch bumps build.xml to 5.0, if warranted (on the 
presumption we are honouring capability or providing a deprecation cycle where 
appropriate).
{quote}
In theory we have backward compatibility with the old yaml&config, no breaking 
changes which someone might say it qualifies for 4.1. Should I hit the mailing 
list about that?

Also, for general visibility - I opted out of adding new JMX methods as there 
are already tickets for updating config through Virtual tables people work on 
and also there is no plan to change nodetool. 


was (Author: e.dimitrova):
Thank you [~maedhroz] . I already addressed the first two commits review 
comments, I will address the third commit comments now. Then I will rebase on 
the latest changes from December and take care of the newest added config in a 
new commit. I will ping you when I am done. 
{quote}{quote} It's ok that the patch bumps build.xml to 5.0, if warranted (on 
the presumption we are honouring capability or providing a deprecation cycle 
where appropriate).
{quote}{quote}
In theory we have backward compatibility with the old yaml&config, no breaking 
changes which someone might say it qualifies for 4.1. Should I hit the mailing 
list about that?

Also, for general visibility - I opted out of adding new JMX methods as there 
are already tickets for updating config through Virtual tables people work on 
and also there is no plan to change nodetool. 

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for either 
> their old or new definition e.g. {{KiB/s}}, or we could support them and 
> simply log the value in bytes/s.



--
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

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 1/6/22, 4:16 PM:
--

Thank you [~maedhroz] . I already addressed the first two commits review 
comments, I will address the third commit comments now. Then I will rebase on 
the latest changes from December and take care of the newest added config in a 
new commit. I will ping you when I am done. 
{quote}{quote} It's ok that the patch bumps build.xml to 5.0, if warranted (on 
the presumption we are honouring capability or providing a deprecation cycle 
where appropriate).
{quote}{quote}
In theory we have backward compatibility with the old yaml&config, no breaking 
changes which someone might say it qualifies for 4.1. Should I hit the mailing 
list about that?

Also, for general visibility - I opted out of adding new JMX methods as there 
are already tickets for updating config through Virtual tables people work on 
and also there is no plan to change nodetool. 


was (Author: e.dimitrova):
Thank you [~maedhroz] . I already addressed those on the first two commits, I 
will address the third commit comments now. Then I will rebase on the latest 
changes from December and take care of the newest added config in a new commit. 
I will ping you when I am done. 
{quote}bq. It's ok that the patch bumps build.xml to 5.0, if warranted (on the 
presumption we are honouring capability or providing a deprecation cycle where 
appropriate).
{quote}
In theory we have backward compatibility with the old yaml&config, no breaking 
changes which someone might say it qualifies for 4.1. Should I hit the mailing 
list about that?

Also, for general visibility - I opted out of adding new JMX methods as there 
are already tickets for updating config through Virtual tables people work on 
and also there is no plan to change nodetool. 

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for either 
> their old or new definition e.g. {{KiB/s}}, or we could support them and 
> simply log the value in bytes/s.



--
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

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

2022-01-06 Thread Michael Semb Wever (Jira)



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

Michael Semb Wever edited comment on CASSANDRA-15234 at 1/6/22, 10:16 AM:
--

bq. Ah, and of course, we'll have to make a decision in terms of whether this 
hits 4.1 or not. If it doesn't, it seems like we wouldn't be able to merge to 
trunk.

It's ok that the patch bumps build.xml to 5.0, if warranted (on the presumption 
we are honouring capability or providing a deprecation cycle where appropriate).


was (Author: michaelsembwever):
> Ah, and of course, we'll have to make a decision in terms of whether this 
> hits 4.1 or not. If it doesn't, it seems like we wouldn't be able to merge to 
> trunk.

It's ok that the patch bumps build.xml to 5.0, if warranted (on the presumption 
we are honouring capability or providing a deprecation cycle where appropriate).

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for either 
> their old or new definition e.g. {{KiB/s}}, or we could support them and 
> simply log the value in bytes/s.



--
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

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

2021-12-15 Thread Ekaterina Dimitrova (Jira)



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 12/15/21, 8:38 PM:


Thank you [~maedhroz] 

I made all changes as per the review comments and our discussions. I also left 
responses on the PR. I have three commits on 
[this|https://github.com/ekaterinadimitrova2/cassandra/pull/191/files] new PR, 
as we talked (The old PR stays there, nothing added, nothing squashed; kept for 
reference) Next round of review on the [new 
|https://github.com/ekaterinadimitrova2/cassandra/pull/191/files] PR, the 
following commits:
 * [the custom types and the related 
tests|https://github.com/ekaterinadimitrova2/cassandra/pull/191/commits/c5b19d441949a4bbf0a4395517f8f637b9ee1ddf].
 All tests pass
 * [The annotations and 
converters|https://github.com/ekaterinadimitrova2/cassandra/pull/191/commits/4fda1efee2cb9e01982f79d1aa99ad8fbf8b]
  for backward compatibility. I [ran 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1253/workflows/864beb33-9051-4ef7-a96d-4e235fa96e4e]
 the test suite to ensure any changes in the YAML loader didn't break anything. 
From what I see the only failures are known ones which after rebase of the 
patch should go away, most of them.
 * [The big change 
|https://github.com/ekaterinadimitrova2/cassandra/pull/191/commits/6a4cf1d5925da154fd39c35e367fb1aa0f447ca3]-
 all the parameters plus adding backward compatibility for virtual tables. [CI 
run|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1255/workflows/89b0d74c-f745-436a-b2bb-bc7b5ea721e6]
 Java 8 (I will run again also Java 11 later but there was no reason to waste 
resources now). The only related to this patch failure is the one of 
_test_sstablelevelreset ._ I have to adjust the warning pattern in the dtest 
repo.

Side Note: There are two circle ci related commits for testing purposes. Please 
ignore them. I will remove them at the end.

I haven't touched the docs as they will have to be reworked after the migration 
to adoc.

JMX methods conversion to the old units is in there but I will add new JMX 
methods in a separate commit. (There is another ticket linked to this one for 
that but there was a discussion better to add them here) This doesn't stop the 
rest of the work from being revised in the meantime.

I have to add also that warning we discussed in case some parameters are set 
more than once in cassandra.yaml. I will do it in a separate commit.

After we confirm the current work, I will do new rebase and change any new 
parameters in trunk to the new format (we still don't have alpha version so it 
is safe to just change the names and types and no backward compatibility is 
needed).

Order of commits for now should be:

1) Cassandra repo [(the custom types and related 
tests)|https://github.com/ekaterinadimitrova2/cassandra/pull/191/commits/c5b19d441949a4bbf0a4395517f8f637b9ee1ddf]

2) Cassandra repo ([The backward compatibility framework 
|https://github.com/ekaterinadimitrova2/cassandra/pull/191/commits/4fda1efee2cb9e01982f79d1aa99ad8fbf8b])

3) CCM patch

4) dtest patch

5) The [big change of 
parameters|https://github.com/ekaterinadimitrova2/cassandra/pull/191/commits/6a4cf1d5925da154fd39c35e367fb1aa0f447ca3]

 


was (Author: e.dimitrova):
Thank you [~maedhroz] 

I made all changes as per the review comments and our discussions. I also left 
responses on the PR. I have three commits on 
[this|https://github.com/ekaterinadimitrova2/cassandra/pull/191/files] new PR, 
as we talked (The old PR stays there, nothing added, nothing squashed; kept for 
reference) Next round of review on the [new 
|https://github.com/ekaterinadimitrova2/cassandra/pull/191/files] PR, the 
following commits:
 * [the custom types and the related 
tests|https://github.com/ekaterinadimitrova2/cassandra/pull/191/commits/c5b19d441949a4bbf0a4395517f8f637b9ee1ddf].
 All tests pass
 * [The annotations and 
converters|https://github.com/ekaterinadimitrova2/cassandra/pull/191/commits/4fda1efee2cb9e01982f79d1aa99ad8fbf8b]
  for backward compatibility. I [ran 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1253/workflows/864beb33-9051-4ef7-a96d-4e235fa96e4e]
 the test suite to ensure any changes in the YAML loader didn't break anything. 
From what I see the only failures are known ones which after rebase of the 
patch should go away, most of them.
 * [The big change 
|https://github.com/ekaterinadimitrova2/cassandra/pull/191/commits/6a4cf1d5925da154fd39c35e367fb1aa0f447ca3]-
 all the parameters plus adding backward compatibility for virtual tables. [CI 
run|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1255/workflows/89b0d74c-f745-436a-b2bb-bc7b5ea721e6]
 Java 8 (I will run again also Java 11

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

2021-12-09 Thread Caleb Rackliffe (Jira)



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

Caleb Rackliffe edited comment on CASSANDRA-15234 at 12/9/21, 11:17 PM:


Finished my first pass of review and left comments inline in the PR. (Can take 
a look at CCM next...)


was (Author: maedhroz):
Finished my first pass of review and left comments inline in the PR.

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for either 
> their old or new definition e.g. {{KiB/s}}, or we could support them and 
> simply log the value in bytes/s.



--
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

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

2021-12-06 Thread Caleb Rackliffe (Jira)



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

Caleb Rackliffe edited comment on CASSANDRA-15234 at 12/6/21, 11:35 PM:


Note: I think the {{TestClientRequestMetrics}} 
[failure|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1239/workflows/d0f8f584-ede1-42f1-96ad-9fbc2d981a56/jobs/7427]
 is related to CASSANDRA-17155. With everything rebased, it should wash out. CC 
[~yifanc]


was (Author: maedhroz):
Note: I think the {{TestClientRequestMetrics}} 
[failure|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1239/workflows/d0f8f584-ede1-42f1-96ad-9fbc2d981a56/jobs/7427]
 is related to CASSANDRA-17155. With everything rebased, it should wash out.

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for either 
> their old or new definition e.g. {{KiB/s}}, or we could support them and 
> simply log the value in bytes/s.



--
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

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

2021-12-02 Thread Ekaterina Dimitrova (Jira)



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 12/2/21, 11:47 PM:


Short update:
 - I figured out what needs to be done in order to be able to test with our own 
CCM branch - ticket to update our docs opened CASSANDRA-17182.
 - I was also thinking of adding a test to the ccm tests but it seems they are 
not run in CI, not sure what is the story there. ([~mck], any ideas?)
 - Almost all tests pass now, it seems I have an issue with the assert warnings 
only(a few Python DTests failed), I have to correct the string pattern used. I 
did it 
[here|https://github.com/apache/cassandra-dtest/pull/169/commits/7c417847092524d46de9e03d11d6acc63159e2dd]
 but I haven't run whole CI for this now. [Java8 
CI|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1239/workflows/345d82ca-1e2a-4db9-b660-a88324793a40]
 | [Java11 CI 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1239/workflows/d0f8f584-ede1-42f1-96ad-9fbc2d981a56].
 This branch was not rebased in the past two weeks so some of the test fixes 
are not applied.
 - I will do the JMX change next week in a new commit, it also shouldn't bother 
any reviews to happen in the meantime if/when people are available. I know 
[~dcapwell] and [~blerer] are busy and also holidays are approaching.


was (Author: e.dimitrova):
Short update:
- I figured out what needs to be done in order to be able to test with our own 
CCM branch - ticket to update our docs opened CASSANDRA-17182.
- I was also thinking of adding a test to the ccm tests but it seems they are 
not run in CI, not sure what is the story there. ([~mck], any ideas?)
- Almost all tests pass now, it seems I have an issue with the assert warnings 
only, I have to correct the pattern. I did it 
[here|https://github.com/apache/cassandra-dtest/pull/169/commits/7c417847092524d46de9e03d11d6acc63159e2dd]
 but I don't think I haven't run whole CI for this. [Java8 
CI|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1239/workflows/345d82ca-1e2a-4db9-b660-a88324793a40]
 | [Java11 
CIhttps://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1239/workflows/d0f8f584-ede1-42f1-96ad-9fbc2d981a56].
 This branch was not rebased in the past two weeks so some of the test fixes 
are no applied. 
- I will do the JMX change next week in a new commit, it also shouldn't bother 
any reviews to happen in the meantime if/when people are available. I know 
[~dcapwell] and [~blerer] are busy and also holidays are approaching. 

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for either 
> their old or new definition e.g. {{KiB/s}}, or we could support them and 
> simply log the value in bytes/s.



--
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

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 12/2/21, 2:54 AM:
---

Quick update - I figured it is purely pip3 issue how we install ccm. The time 
things worked was when I had a bug in my code, but in general CCM is not 
changing to my new version when I change it in requirements.txt

 

What I found in CircleCI logs:
{code:java}
Collecting ccm
  Cloning https://github.com/ekaterinadimitrova2/ccm.git (to revision 
CASSANDRA-15234) to 
/tmp/pip-install-dvfww32x/ccm_727b34808faa4db6904e104a715a22d2
  Running command git clone -q https://github.com/ekaterinadimitrova2/ccm.git 
/tmp/pip-install-dvfww32x/ccm_727b34808faa4db6904e104a715a22d2
  Running command git checkout -b CASSANDRA-15234 --track origin/CASSANDRA-15234
  Switched to a new branch 'CASSANDRA-15234'
  Branch 'CASSANDRA-15234' set up to track remote branch 'CASSANDRA-15234' from 
'origin'.
  Resolved https://github.com/ekaterinadimitrova2/ccm.git to commit 
ee52d120ea34d44500c64bfb3b9d3f517b0865f1
{code}
 But then
{code:java}
 pip3 freeze
{code}
output shows:
{code:java}
ccm @ 
git+https://github.com/riptano/ccm.git@ce612ea71587bf263ed513cb8f8d5dfcf7c8dadb
{code}

I will debug this tomorrow but it is the way we update ccm not CircleCI


was (Author: e.dimitrova):
Quick update - I figured it is purely pip3 issue how we install ccm. The time 
things worked was when I had a bug in my code, but in general CCM is not 
changing to my new version when I change it in requirements.txt

 

What I found in CircleCI logs:

{code:java}
Collecting ccm
  Cloning https://github.com/ekaterinadimitrova2/ccm.git (to revision 
CASSANDRA-15234) to 
/tmp/pip-install-dvfww32x/ccm_727b34808faa4db6904e104a715a22d2
  Running command git clone -q https://github.com/ekaterinadimitrova2/ccm.git 
/tmp/pip-install-dvfww32x/ccm_727b34808faa4db6904e104a715a22d2
  Running command git checkout -b CASSANDRA-15234 --track origin/CASSANDRA-15234
  Switched to a new branch 'CASSANDRA-15234'
  Branch 'CASSANDRA-15234' set up to track remote branch 'CASSANDRA-15234' from 
'origin'.
  Resolved https://github.com/ekaterinadimitrova2/ccm.git to commit 
ee52d120ea34d44500c64bfb3b9d3f517b0865f1
{code}

 But then
{code:java}
 pip3 freeze
{code}
 output shows:

{code:java}
ccm @ 
git+https://github.com/riptano/ccm.git@ce612ea71587bf263ed513cb8f8d5dfcf7c8dadb
{code}


> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for either 
> their old or new definition e.g. {{KiB/s}}, or we could support them and 
> simply log the value in bytes/s.



--
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

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 12/2/21, 2:54 AM:
---

Quick update - I figured it is purely pip3 issue how we install ccm. The time 
things worked was when I had a bug in my code, but in general CCM is not 
changing to my new version when I change it in requirements.txt

 

What I found in CircleCI logs:
{code:java}
Collecting ccm
  Cloning https://github.com/ekaterinadimitrova2/ccm.git (to revision 
CASSANDRA-15234) to 
/tmp/pip-install-dvfww32x/ccm_727b34808faa4db6904e104a715a22d2
  Running command git clone -q https://github.com/ekaterinadimitrova2/ccm.git 
/tmp/pip-install-dvfww32x/ccm_727b34808faa4db6904e104a715a22d2
  Running command git checkout -b CASSANDRA-15234 --track origin/CASSANDRA-15234
  Switched to a new branch 'CASSANDRA-15234'
  Branch 'CASSANDRA-15234' set up to track remote branch 'CASSANDRA-15234' from 
'origin'.
  Resolved https://github.com/ekaterinadimitrova2/ccm.git to commit 
ee52d120ea34d44500c64bfb3b9d3f517b0865f1
{code}
 But then
{code:java}
 pip3 freeze
{code}
output shows:
{code:java}
ccm @ 
git+https://github.com/riptano/ccm.git@ce612ea71587bf263ed513cb8f8d5dfcf7c8dadb
{code}

I will debug this tomorrow but it is the way we update ccm not CircleCI caching 
or so


was (Author: e.dimitrova):
Quick update - I figured it is purely pip3 issue how we install ccm. The time 
things worked was when I had a bug in my code, but in general CCM is not 
changing to my new version when I change it in requirements.txt

 

What I found in CircleCI logs:
{code:java}
Collecting ccm
  Cloning https://github.com/ekaterinadimitrova2/ccm.git (to revision 
CASSANDRA-15234) to 
/tmp/pip-install-dvfww32x/ccm_727b34808faa4db6904e104a715a22d2
  Running command git clone -q https://github.com/ekaterinadimitrova2/ccm.git 
/tmp/pip-install-dvfww32x/ccm_727b34808faa4db6904e104a715a22d2
  Running command git checkout -b CASSANDRA-15234 --track origin/CASSANDRA-15234
  Switched to a new branch 'CASSANDRA-15234'
  Branch 'CASSANDRA-15234' set up to track remote branch 'CASSANDRA-15234' from 
'origin'.
  Resolved https://github.com/ekaterinadimitrova2/ccm.git to commit 
ee52d120ea34d44500c64bfb3b9d3f517b0865f1
{code}
 But then
{code:java}
 pip3 freeze
{code}
output shows:
{code:java}
ccm @ 
git+https://github.com/riptano/ccm.git@ce612ea71587bf263ed513cb8f8d5dfcf7c8dadb
{code}

I will debug this tomorrow but it is the way we update ccm not CircleCI

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for either 
> their old or new definition e.g. {{KiB/s}}, or we could support them and 
> simply log the value in bytes/s.



--
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

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 12/1/21, 9:07 PM:
---

Moving the ticket to "In Review" as [~dcapwell]  is already looking into it.

Also, for visibility and context as it seems I missed in my summary - there is 
a separate ticket linked to this one(CASSANDRA-9691) which was mentioning 
liberating metrics and JMX from units or just moving to lowest unit at least. I 
left this part to be handled there but I forgot to mention it in my summary. 
Apologize for that

My thought was currently to leave the  JMX and metrics for now and assume the 
old units are in place but [~dcapwell] is right we need at least to verify (and 
convert if needed) that in Config the old unit was used with the new custom 
types and we didn't use something different as this can be a mess if we leave 
it to people and reading docs. Something similar will also be needed for VTs 
where we will have to check the Converter in the new @Replaces annotation. 
There was idea for getting the VT backward compatibility out until we figure 
out how we are going to handle the VT as there is ongoing discussion around 
that, I will leave this now aside for a moment until we clear a bit the 
discussion. CC [~blerer] as I know he is working on a patch for CASSANDRA-15254

Also, I will be looking again into the ccm issue in the afternoon. 

 


was (Author: e.dimitrova):
Moving the ticket to "In Review" as [~dcapwell]  is already looking into it.

Also, for visibility and context as it seems I missed in my summary - there is 
a separate ticket linked to this one(CASSANDRA-9691) which was mentioning 
liberating metrics and JMX from units or just moving to lowest unit at least. I 
left this part to be handled there but I forgot to mention it in my summary. 
Apologize for that

My thought was currently to leave the  JMX and metrics for now and assume the 
old units are in place but [~dcapwell] is right we need at least to verify and 
convert if needed that in Config the old unit was used with the new custom 
types and we didn't use something different as this can be a mess if we leave 
it to people and reading docs. Something similar will also be needed for VTs 
where we will have to check the Converter in the new @Replaces annotation. 
There was idea for getting the VT backward compatibility out until we figure 
out how we are going to handle the VT as there is ongoing discussion around 
that, I will leave this now aside for a moment until we clear a bit the 
discussion. CC [~blerer] as I know he is working on a patch for CASSANDRA-15254

Also, I will be looking again into the ccm issue in the afternoon. 

 

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for either 
> their old or new definition e.g. {{KiB/s}}, or we could support them and 
> simply log the value in bytes/s.



--
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

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 12/1/21, 5:43 PM:
---

Moving the ticket to "In Review" as [~dcapwell]  is already looking into it.

Also, for visibility and context as it seems I missed in my summary - there is 
a separate ticket linked to this one(CASSANDRA-9691) which was mentioning 
liberating metrics and JMX from units or just moving to lowest unit at least. I 
left this part to be handled there but I forgot to mention it in my summary. 
Apologize for that

My thought was currently to leave the  JMX and metrics for now and assume the 
old units are in place but [~dcapwell] is right we need at least to verify and 
convert if needed that in Config the old unit was used with the new custom 
types and we didn't use something different as this can be a mess if we leave 
it to people and reading docs. Something similar will also be needed for VTs 
where we will have to check the Converter in the new @Replaces annotation. 
There was idea for getting the VT backward compatibility out until we figure 
out how we are going to handle the VT as there is ongoing discussion around 
that, I will leave this now aside for a moment until we clear a bit the 
discussion. CC [~blerer] as I know he is working on a patch for CASSANDRA-15254

Also, I will be looking again into the ccm issue in the afternoon. 

 


was (Author: e.dimitrova):
Moving the ticket to "In Review" as [~dcapwell]  is already looking into it.

Also, for visibility and context as it seems I missed in my summary - there is 
a separate ticket linked to this one(CASSANDRA-9691) which was mentioning 
liberating metrics and JMX from units or just moving to lowest unit at least. I 
left this part to be handled there but I forgot to mention it in my summary. 
Apologize for that

My thought was currently to leave the  JMX and metrics for now and assume the 
old units are in place but [~dcapwell] is right we need at least to verify and 
convert if needed that in Config the old unit was used with the new custom 
types and we didn't use something different as this can be a mess if we live it 
to people and reading docs. Something similar will also be needed for VTs where 
we will have to check the Converter in the new @Replaces annotation. There was 
idea for getting the VT backward compatibility out until we figure out how we 
are going to handle the VT as there is ongoing discussion around that, I will 
leave this now aside for a moment until we clear a bit the discussion. CC 
[~blerer] as I know he is working on a patch for CASSANDRA-15254

Also, I will be looking again into the ccm issue in the afternoon. 

 

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for either 
> their old or new definition e.g. {{KiB/s}}, or we could support them and 
> simply log the value in bytes/s.



--
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

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 12/1/21, 5:42 PM:
---

Moving the ticket to "In Review" as [~dcapwell]  is already looking into it.

Also, for visibility and context as it seems I missed in my summary - there is 
a separate ticket linked to this one(CASSANDRA-9691) which was mentioning 
liberating metrics and JMX from units or just moving to lowest unit at least. I 
left this part to be handled there but I forgot to mention it in my summary. 
Apologize for that

My thought was currently to leave the  JMX and metrics for now and assume the 
old units are in place but [~dcapwell] is right we need at least to verify and 
convert if needed that in Config the old unit was used with the new custom 
types and we didn't use something different as this can be a mess if we live it 
to people and reading docs. Something similar will also be needed for VTs where 
we will have to check the Converter in the new @Replaces annotation. There was 
idea for getting the VT backward compatibility out until we figure out how we 
are going to handle the VT as there is ongoing discussion around that, I will 
leave this now aside for a moment until we clear a bit the discussion. CC 
[~blerer] as I know he is working on a patch for CASSANDRA-15254

Also, I will be looking again into the ccm issue in the afternoon. 

 


was (Author: e.dimitrova):
Moving the ticket to "In Review" as [~dcapwell]  is already looking into it.

Also, for visibility and context as it seems I missed in my summary - there is 
a separate ticket linked to this one(CASSANDRA-9691) which was mentioning 
liberating metrics and JMX from units or just moving to lowest unit at least. I 
left this part to be handled there but I forgot to mention it in my summary. 
Apologize for that

My thought was currently to leave the  JMX for now and assume the old units are 
in place but [~dcapwell] is right we need at least to verify and convert if 
needed that in Config the old unit was used with the new custom types and we 
didn't use something different as this can be a mess if we live it to people 
and reading docs. Something similar will also be needed for VTs where we will 
have to check the Converter in the new @Replaces annotation. There was idea for 
getting the VT backward compatibility out until we figure out how we are going 
to handle the VT as there is ongoing discussion around that, I will leave this 
now aside for a moment until we clear a bit the discussion. CC [~blerer] as I 
know he is working on a patch for CASSANDRA-15254

Also, I will be looking again into the ccm issue in the afternoon. 

 

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for either 
> their old or new definition e.g. {{KiB/s}}, or we could support them and 
> simply log the value in bytes/s.



--
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

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

2021-11-30 Thread Ekaterina Dimitrova (Jira)



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 11/30/21, 11:52 PM:
-

Sure, [PR|https://github.com/apache/cassandra/pull/1350] created
{quote}patch is massive; no way I can finish before I go on break Friday =(
{quote}
This waited whole year, it can wait while you take well deserved break. I will 
be off on Friday and then in two weeks again. Hopefully the next rebase won't 
be too painful :) Hopefully the community won't work too much around the 
holidays :D  


was (Author: e.dimitrova):
Sure, [PR|https://github.com/apache/cassandra/pull/1350] created

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for either 
> their old or new definition e.g. {{KiB/s}}, or we could support them and 
> simply log the value in bytes/s.



--
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

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

2021-11-22 Thread Ekaterina Dimitrova (Jira)

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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 11/22/21, 2:41 PM:

[~dcapwell],[~blerer], submitting for new round of review.
I have some issue that I can't always trigger in CI the newest version I push
to ccm. Still it seems Jenkins has more success than CircleCI.

Until I figure it out, these are the patches for initial round of review.

[trunk|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:CASSANDRA-15234-take2?expand=1]
|
[dtest|https://github.com/ekaterinadimitrova2/cassandra-dtest/pull/new/CASSANDRA-15234-take2]
| [ccm|https://github.com/ekaterinadimitrova2/ccm/pull/new/CASSANDRA-15234]

I cleaned all tests without full Jenkins confirmation of the Python DTests yet
due to the ccm issue mentioned.

Also, this patch latest rebase was also a week ago and I will rebase again when
I have to do next round of review changes and I fix ccm as otherwise on every
rebase something new appears as trunk is quite alive and the config is all over
the place. Let me first stabilize CI and we can agree on the patch, then I will
clean this.

Now a few important comments:
* ASCII doc migration is still not done but I will open a ticket to add docs
for us for adding new config and docs for our users around the new and old
types and names.
* DTests were not updated to the new names and format as this will take
forever. Suggestion - leave the old ones and add new tests with new ones. We
can also open a follow up ticket but now this exercises the backward
compatibility which is good as this is also how I figured out one more change
needed for CCM.
* CCM was updated to be able to handle the backward compatibility and mimic
the Cassandra behavior.
* I suggest not to overwhelm the patch with the reorganization of
cassandra.yaml I suggested earlier on this ticket. I will pull it in a separate
one and I can trigger a new discuss thread on the mailing list to confirm that.
* Converter was not changed to an enum because we need generics support for
that and [JEP301|http://openjdk.java.net/jeps/301] was withdrawn.
* Intentionally left the commits after the old patch not squashed to provide
some input and hopefully make the review a bit more easy. [~blerer] and
[~dcapwell] , please, let me know if you want them in a different way for the
review.
* Now when 4.0 was released I had to add also Virtual Table backward
compatibility and the easiest way was just to have the old names and types and
the new ones both listed in the Settings table, available for our users.
* _commitlog_sync_batch_in_ms_ was left for another ticket as the in-jvm
upgrade tests will need work to make it possible to support it due to their
nature as it seems we have the lower branch _DatabaseDescriptor_ class loaded
and it makes checks on trunk and complains if we change to the custom type.
(CASSANDRA-17161)
* Any new parameters added post 4.0 in trunk were/will be directly changed to
support the new format as they are still not in any release.
* CCM_41_YAML_OPTIONS in ccm should be well documented and people warned that
they need to keep it up to date on changes in config. I hope we won't need this
to happen a lot after this update but we need to ensure people are aware of it.
It seems a bit clumsy but I didn't find a better way to handle ccm at this
point. I am open for ideas.
* I can think of adding some additional test for the virtual table.
* I also suggest we add a warning to the users when they start Cassandra that
if they add more than once a property (even if it is the old name), the latest
occurrence from the yaml file will be the one assigned to the parameter. I
would say we add also info to the docs and we don't complicate to add checks
whether we have or not more occurrences during startup and emitting warnings on
occurrence as it seems a bit too much overhead on startup. WDYT?
* There were deprecation warnings emitted more than once. I fixed this. This
fix should be also ported to 4.0 where we had to make small port of the name
change because of two parameters issues. (FTR - CASSANDRA-17141) In 4.0 they
are not only two properties with the warnings twice so it was harder to spot
it.

was (Author: e.dimitrova):
[~dcapwell],[~blerer], submitting for new round of review.
I have some issue that I can't always trigger to get the newest version I push
to ccm. Still it seems Jenkins has more success than CircleCI.

Until I figure it out, these are the patches for initial round of review.

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

2021-11-21 Thread Ekaterina Dimitrova (Jira)

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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 11/22/21, 3:58 AM:

[~dcapwell],[~blerer], submitting for new round of review.
I have some issue that I can't always trigger to get the newest version I push
to ccm. Still it seems Jenkins has more success than CircleCI.

Until I figure it out, these are the patches for initial round of review.

I cleaned all tests without full Jenkins confirmation of the dtests yet due to
the ccm issue mentioned.

Now a few important comments:
* ASCII doc migration is still not done but I will open a ticket to add docs
for us for adding new config and docs for our users around the new and old
types and names.
* DTests were not updated to the new names and format as this will take
forever. Suggestion - leave the old ones and add new tests with new ones. We
can also open a follow up ticket but now this exercises the backward
compatibility which is good as this is also how I figured out one more change
needed for CCM.
* CCM was updated to be able to handle the backward compatibility and
Cassandra behavior.
* I suggest not to overwhelm the patch with the reorganization of
cassandra.yaml I suggested earlier on this ticket. I will pull it in a separate
one and I can trigger a new discuss thread on the mailing list to confirm that.
* Converter was not changed to an enum because we need generics support for
that and [JEP301|http://openjdk.java.net/jeps/301] was withdrawn.
* Intentionally left the commits after the old patch not squashed to provide
some input and hopefully make the review a bit more easy. [~blerer] and
[~dcapwell] , please, let me know if you want them in a different way for the
review.
* Now when 4.0 was released I had to add also Virtual Table backward
compatibility and the easiest way was just to have the old names and types and
the new ones both listed in the Settings table.
* commitlog_sync_batch_in_ms was left for another ticket as the in-jvm upgrade
tests will need work to make it possible to support it due to their nature as
it seems we have the lower branch DatabaseDescriptor class loaded and it makes
checks on trunk and complains if we change to the custom type.
* Any new parameters added post 4.0 in trunk were/will be directly changed to
support the new format as they are still not in any release.
* CCM_41_YAML_OPTIONS in ccm should be well documented and people warned that
they need to keep it up to date on changes in config. I hope we won't need this
to happen a lot after this update but we need to ensure people are aware of it.
It seems a bit clumsy but I didn't find a better way to handle ccm at this
point. Open for ideas.
* I can think of adding some additional test for the virtual table.
* I also suggest we add a warning to the users when they start Cassandra that
if they add more than once a property (even if it is the old name), the latest
occurrence from the yaml file will appear. I would say we add also to the docs
and we don't complicate to add checks whether we have or not more occurrences
and on occurrences adding it as it seems a bit too much overhead on startup.
WDYT?
* There were deprecation warnings emitted more than once. I fixed this. This
fix should be also ported to 4.0 where we had to make small port of the name
change because of two parameters issues. (FTR - CASSANDRA-17141)

was (Author: e.dimitrova):
I have some issue that I can't always trigger to get the newest version I push
to ccm. Still it seems Jenkins has more success than CircleCI.

Until I figure it out, these are the patches for initial round of review.

I cleaned all tests without full Jenkins confirmation of the dtests yet due to
the ccm issue mentioned.

Also, this patch latest rebase was also a week ago and I will rebase again when
I have to do next roun

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

2021-07-19 Thread Ekaterina Dimitrova (Jira)



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 7/19/21, 5:08 PM:
---

Thank you [~benedict] and apologize for the late response. There was a lot of 
multitasking lately.
{quote}it would be good to get some initial feedback on this approach to 
grouping of config options, as optimising the groups is a laborious job that 
there's no point pursuing if it's otherwise unwelcome.
{quote}
Absolutely agree with you. I personally have only that question for feedback, 
whether they would prefer the sections or the nested version you suggested. 

[~maedhroz], [~mck], [~paulo], [~blerer], [~dcapwell], [~lor...@datastax.com]   
(maybe [~stefan.miklosovic] as I know he was also interested into this work at 
some point) - do you have anything to add here as concerns/comment before we 
bring it to the user list? Any other proposals?

Also, should it come from a PMC? Survey or just a discussion mail thread? I am 
not familiar of any similar discussions before so I am not sure what would be 
the right approach, I am open for suggestions/advice anyone might have. Thank 
you.

 

 


was (Author: e.dimitrova):
Thank you [~benedict] and apologize for the late response. There was a lot of 
multitasking lately.
{quote}it would be good to get some initial feedback on this approach to 
grouping of config options, as optimising the groups is a laborious job that 
there's no point pursuing if it's otherwise unwelcome.
{quote}
Absolutely agree with you. I personally have only that question for feedback, 
whether they would prefer the sections or the nested version you suggested. 

[~maedhroz], [~mck], [~paulo], [~blerer], [~dcapwell], [~lor...@datastax.com]   
(maybe [~stefan.miklosovic] as I know he was also interested into this work at 
some point) - do you have anything to add here as concerns/comment before we 
bring it to the user list?

Also, should it come from a PMC? Survey or just a discussion mail thread? I am 
not familiar of any similar discussions before so I am not sure what would be 
the right approach, I am open for suggestions/advice anyone might have. Thank 
you.

 

 

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for either 
> their old or new definition e.g. {{KiB/s}}, or we could support them and 
> simply log the value in bytes/s.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

2021-07-07 Thread Ekaterina Dimitrova (Jira)



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 7/7/21, 3:41 PM:
--

Reading back the thread here and reminding myself of what we discussed I guess 
the next step is to hash out a proposal for the user list and get some feedback?
{quote}{quote} I'd personally prefer to hash out here for a week or so, to get 
a good proposal to take to the user list, or a couple of competing proposals. I 
find public engagements works best when there's a good case to 
challenge/consider.
{quote}{quote}


was (Author: e.dimitrova):
Reading back the thread here and reminding myself of what we discussed I guess 
the next step is to hash a proposal for the user list and get some feedback?
{quote}bq. I'd personally prefer to hash out here for a week or so, to get a 
good proposal to take to the user list, or a couple of competing proposals. I 
find public engagements works best when there's a good case to 
challenge/consider.
{quote}

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for either 
> their old or new definition e.g. {{KiB/s}}, or we could support them and 
> simply log the value in bytes/s.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

2021-07-07 Thread Ekaterina Dimitrova (Jira)



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 7/7/21, 3:41 PM:
--

Reading back the thread here and reminding myself of what we discussed I guess 
the next step is to hash out a proposal for the user list and get some feedback?
{quote}bq. I'd personally prefer to hash out here for a week or so, to get a 
good proposal to take to the user list, or a couple of competing proposals. I 
find public engagements works best when there's a good case to 
challenge/consider.
{quote}
 


was (Author: e.dimitrova):
Reading back the thread here and reminding myself of what we discussed I guess 
the next step is to hash out a proposal for the user list and get some feedback?
{quote}{quote} I'd personally prefer to hash out here for a week or so, to get 
a good proposal to take to the user list, or a couple of competing proposals. I 
find public engagements works best when there's a good case to 
challenge/consider.
{quote}{quote}

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for either 
> their old or new definition e.g. {{KiB/s}}, or we could support them and 
> simply log the value in bytes/s.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

2020-10-07 Thread Benedict Elliott Smith (Jira)



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

Benedict Elliott Smith edited comment on CASSANDRA-15234 at 10/7/20, 1:24 PM:
--

Not sure if you need special permissions, but you can just create a new version.

Sorry for my having not had time to finish my proposal - but I agree having a 
bit more time to decide and consult on the best layout is probably a good thing.


was (Author: benedict):
Not sure if you need special permissions, but you can just create a new version.

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.0
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for either 
> their old or new definition e.g. {{KiB/s}}, or we could support them and 
> simply log the value in bytes/s.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

2020-10-07 Thread Caleb Rackliffe (Jira)



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

Caleb Rackliffe edited comment on CASSANDRA-15234 at 10/7/20, 1:11 PM:
---

bq. In the spirit of expediting 4.0RC release I propose we postpone this to 
4.X, and resume this with high priority earlier in the next release cycle.

I'm more or less in agreement that we push this to the next major along with 
CASSANDRA-16038, unless some unrelated need for the latter arises.


was (Author: maedhroz):
bq. In the spirit of expediting 4.0RC release I propose we postpone this to 
4.X, and resume this with high priority earlier in the next release cycle.

I'm more or less in agreement that we push this to 4.x along with 
CASSANDRA-16038, unless some unrelated need for the latter arises.

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha, 4.0-triage
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for either 
> their old or new definition e.g. {{KiB/s}}, or we could support them and 
> simply log the value in bytes/s.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

2020-07-24 Thread Ekaterina Dimitrova (Jira)

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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 7/24/20, 8:55 PM:
---

[~benedict] I am sorry for my delayed responses but I am multi-tasking a lot
these days.
{quote}I'm fairly certain the main body of this work should be utilised to
support whatever our new config file layout is; whether we commit it first or
all together is fine by me, and I'm happy to defer to others' preferences (most
importantly yours, as the author)
{quote}
I think the backward compatibility is the primary part that will be most
probably reworked to accommodate the new approach. I think the moment we moved
the ticket to beta and the discussion continued here, that was the time we kind
of agreed through our actions that this work will be
continued/completed/committed later. I might have gotten it wrong. As it looks
like this is already happening, I suggest to shape it and then move on with the
actual changes. Maybe we can only create now a separate new ticket on the
in-jvm api change so a snapshot release could be voted, etc. But also, we need
to see what yaml nodes will have to be created according to what we need, so
that work could also wait a bit until the api part is agreed, I think.

About the dual approach, I am not sure I understand you correct what you mean
in this citation:
{quote}providing us a simple route to permitting common options being given at
the start of the file, without confusing the overall approach.
{quote}
I understand having third version will help any simplistic tools in case they
can't deal with the nested approach but to me personally it would be confusing.
I am pretty sure [~lor...@datastax.com] will update perfectly the documentation
(as usual, thanks a lot [~lor...@datastax.com]!) but at the same time if
someone is in a hurry during a production issue, they will just jump on random
link from google probably and maybe be get confused about what/how. Here, for
this part, probably the survey will show the best.
Otherwise, the grouping sounds reasonable to me.

The reason why I suggested Quick Start, Advanced options etc is new users. I
kind of feel that for someone brand new to C* this might help. But also if we
make groups into nested parameters, sure this becomes irrelevant and those
sections will not really make sense anymore, not in their current version.

Excited to see the end result/user reactions.

Last but not least, I also agree with you on the below:
{quote}I'd personally prefer to hash out here for a week or so, to get a good
proposal to take to the user list, or a couple of competing proposals. I find
public engagements works best when there's a good case to challenge/consider.
{quote}

was (Author: e.dimitrova):
[~benedict] I am sorry for my delayed responses but I am multi-tasking a lot
these days.
{quote}I'm fairly certain the main body of this work should be utilised to
support whatever our new config file layout is; whether we commit it first or
all together is fine by me, and I'm happy to defer to others' preferences (most
importantly yours, as the author)
{quote}
I think the backward compatibility is the primary part that will be most
probably reworked to accommodate the new approach. I think the moment we moved
the ticket to beta and the discussion continued here, that was the time we kind
of agreed through our actions that this work will be
continued/completed/committed later. I might have gotten it wrong. As it looks
like this is already happening, I suggest to shape it and then move on with the
actual changes. Maybe we can only create now a separate new ticket on the
in-jvm api change so a snapshot release could be voted, etc. But also, we need
to see what yaml nodes will have to be created according to what we need, so
that work could also wait a bit until the api part is agreed, I think.

The reason why I suggested Quick Start, Advanced options etc is new users. I
kind of

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

2020-07-24 Thread Ekaterina Dimitrova (Jira)

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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 7/24/20, 8:54 PM:
---

Excited to see the end result/user reactions.

About the dual approach, I am not sure I understand you correct what you mean
in this citation:
{quote}providing us a simple route to permitting common options being given at
the start of the file, without confusing the overall approach.
{quote}
I understand having third version will help any simplistic tools in case they
can't deal with the nested approach but to me personally it would be confusing.
I am pretty sure [~lor...@datastax.com] will update perfectly the documentation
(as usual, thanks a lot [~lor...@datastax.com]!) but at the same time if
someone is in a hurry during a production issue, they will just jump on random
link probably and maybe be get confused about what/how. Here, for this part,
probably the survey will show the best.
Otherwise, the grouping sounds reasonable to me.

The reason why I suggested Quick Start, Advanced options etc is new users. I
kind of feel that for someone brand new to C* t

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

2020-07-21 Thread Benedict Elliott Smith (Jira)



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

Benedict Elliott Smith edited comment on CASSANDRA-15234 at 7/21/20, 9:39 PM:
--

bq.  it would be great to start this dialog on user@

I'd personally prefer to hash out here for a week or so, to get a good proposal 
to take to the user list, or a couple of competing proposals.  I find public 
engagements works best when there's a good case to challenge/consider.

It's a difficult balancing act getting any given approach right, and there are 
multiple approaches.  I would love to see another approach taken more to its 
conclusion for comparison.

I've made some further changes, and to make it clearer created a 
[yaml|https://github.com/belliottsmith/cassandra/blob/5f80d1c0d38873b7a27dc137656d8b81f8e6bbd7/conf/cassandra_nocomment.yaml]
 with comments mostly stripped.

In this version, there are basic settings for network, disk etc all grouped 
together, followed by operator tuneables mostly under {{limits}} within which 
we now have {{throughput}}, {{concurrency}}, {{capacity}}.  This leads to 
settings for some features being kept separate (most notably for caching), but 
helps the operator understand what they have to play with for controlling 
resource consumption.

It's still incomplete, but 90%+ done, and thoughts would be most welcome.

bq. My main concern is if this makes it more confusing for users; they may find 
some docs which say the old name, some using the nested name, and others using 
the flat name.

This is a possibility, and I'm not wed to the idea - but I think the balance of 
benefit to risk is probably pretty good, particularly since the names are 
fairly consistent (and we can have a blurb at the start to explain the dual 
system), so I doubt it should lead to too much confusion if we opt for it.



was (Author: benedict):
bq.  it would be great to start this dialog on user@

I'd personally prefer to hash out here for a week or so, to get a good proposal 
to take to the user list, or a couple of competing proposals.  I find public 
engagements works best when there's a good case to challenge/consider.

It's a difficult balancing act getting any given approach right, and there are 
multiple approaches.  I would love to see another approach taken more to its 
conclusion for comparison.

I've made some further changes, and to make it clearer created a 
[yaml|https://github.com/belliottsmith/cassandra/blob/acac38be9f528e380974423b86fad5e895e3/conf/cassandra_nocomment.yaml]
 with comments mostly stripped.

In this version, there are basic settings for network, disk etc all grouped 
together, followed by operator tuneables mostly under {{limits}} within which 
we now have {{throughput}}, {{concurrency}}, {{capacity}}.  This leads to 
settings for some features being kept separate (most notably for caching), but 
helps the operator understand what they have to play with for controlling 
resource consumption.

It's still incomplete, but 90%+ done, and thoughts would be most welcome.

bq. My main concern is if this makes it more confusing for users; they may find 
some docs which say the old name, some using the nested name, and others using 
the flat name.

This is a possibility, and I'm not wed to the idea - but I think the balance of 
benefit to risk is probably pretty good, particularly since the names are 
fairly consistent (and we can have a blurb at the start to explain the dual 
system), so I doubt it should lead to too much confusion if we opt for it.


> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-beta
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for e

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

2020-07-21 Thread Benedict Elliott Smith (Jira)



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

Benedict Elliott Smith edited comment on CASSANDRA-15234 at 7/21/20, 9:08 PM:
--

bq.  it would be great to start this dialog on user@

I'd personally prefer to hash out here for a week or so, to get a good proposal 
to take to the user list, or a couple of competing proposals.  I find public 
engagements works best when there's a good case to challenge/consider.

It's a difficult balancing act getting any given approach right, and there are 
multiple approaches.  I would love to see another approach taken more to its 
conclusion for comparison.

I've made some further changes, and to make it clearer created a 
[yaml|https://github.com/belliottsmith/cassandra/blob/acac38be9f528e380974423b86fad5e895e3/conf/cassandra_nocomment.yaml]
 with comments mostly stripped.

In this version, there are basic settings for network, disk etc all grouped 
together, followed by operator tuneables mostly under {{limits}} within which 
we now have {{throughput}}, {{concurrency}}, {{capacity}}.  This leads to 
settings for some features being kept separate (most notably for caching), but 
helps the operator understand what they have to play with for controlling 
resource consumption.

It's still incomplete, but 90%+ done, and thoughts would be most welcome.

bq. My main concern is if this makes it more confusing for users; they may find 
some docs which say the old name, some using the nested name, and others using 
the flat name.

This is a possibility, and I'm not wed to the idea - but I think the balance of 
benefit to risk is probably pretty good, particularly since the names are 
fairly consistent (and we can have a blurb at the start to explain the dual 
system), so I doubt it should lead to too much confusion if we opt for it.



was (Author: benedict):
bq.  it would be great to start this dialog on user@

I'd personally prefer to hash out here for a week or so, to get a good proposal 
to take to the user list, or a couple of competing proposals.  I find public 
engagements works best when there's a good case to challenge/consider.

It's a difficult balancing act getting any given approach right, and there are 
multiple approaches.  I would love to see another approach taken more to its 
conclusion for comparison.

I've made some further changes, and to make it clearer created a 
[yaml|https://github.com/belliottsmith/cassandra/blob/acac38be9f528e380974423b86fad5e895e3/conf/cassandra_nocomment.yaml]
 with comments mostly stripped.

In this version, there are basic settings for network, disk etc all grouped 
together, followed by operator tuneables mostly under {{limits}} within which 
we now have {{throughput}}, {{concurrency}}, {{capacity}}.  This leads to 
settings for some features being kept separate (most notably for caching), but 
helps the operator understand what they have to play with for controlling 
resource consumption.

It's still incomplete, but 90%+ done, and thoughts would be most welcome.



> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-beta
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for either 
> their old or new definition e.g. {{KiB/s}}, or we could support them and 
> simply log the value in bytes/s.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

2020-07-21 Thread Ekaterina Dimitrova (Jira)



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 7/21/20, 5:53 PM:
---

Good catch [~benedict] . Thank you. My bad, just pushed a fast commit 
[here|https://github.com/ekaterinadimitrova2/cassandra/commit/b4eebe080835da79d032f9314262c268b71172a8]
 for the three rate parameters we have. 

For the record, I stopped working on this patch until it is clear whether the 
code will be used at all. As far as I understand, you took the lead on a POC 
development for the newly suggested approach. Unfortunately, I don't have time 
to support this now but I would be happy to give feedback when it is shaped 
already. 

If you decide at some point this work or part of it to be committed, let me 
know, I will complete whatever is outstanding. The main framework is in place.

A couple of things to keep in mind:
 * As suggested by Benjamin, the patch can be simplified by making 
{{Converter}} an {{enum}}. It will allow to use the enum value directly into 
the {{Replaces}} annotation. Doing so will remove the need to use reflection to 
instantiate the converters and the use of a cache to avoid multiple 
instantiation.
 * In-jvm tests - loading config parameters should be reworked as currently 
they don't work with custom types (like the newly introduced Duration, etc). 
The suggested approach by [~dcapwell] would work but it requires also api 
changes. I suggest a separate ticket for this part to be opened. Instead of 
using reflection, the suggestion is to use SnakeYAML. In order not to slow down 
the tests, no yaml files will be introduced but there will be a function to 
build the yaml nodes for us. This was a quick POC by [~dcapwell] but there are 
parameters which will need additional work and attention:

 
{code:java}
public class MapToConfigTest
 {
     @Test
     public void test()
     {
          Map map = ImmutableMap.builder()
                                                          
.put("auto_bootstrap", false)
                                                          
.put("permissions_validity_in_ms", 10)
                                                          .put("role_manager", 
"some value")
                                                          .build(); Constructor 
constructor = new YamlConfigurationLoader.CustomConstructor(Config.class);
         PropertiesChecker propertiesChecker = new PropertiesChecker();
         constructor.setPropertyUtils(propertiesChecker);
         constructor.setComposer(new Composer(null, null)
         {
              public Node getSingleNode()
             {
                return toNode(map);
             }
          });
            Config config = (Config) constructor.getSingleData(Config.class);
           System.out.println("trap");
     }
     public static Node toNode(Object object)
     {
          if (object instanceof Map)
          {
               List values = new ArrayList<>();
               for (Map.Entry e : ((Map) 
object).entrySet())
               {
                    values.add(new NodeTuple(toNode(e.getKey()), 
toNode(e.getValue(;
               }
               return new MappingNode(FAKE_TAG, values, null);
           }
           else if (object instanceof Number || object instanceof String || 
object instanceof Boolean)
           {
               return new ScalarNode(FAKE_TAG, object.toString(), FAKE_MARK, 
FAKE_MARK, '\''); 
   }
          else
          {
                throw new UnsupportedOperationException("unexpected type found: 
given " + object.getClass());
          }
      }
      private static final Tag FAKE_TAG = new Tag("ignore");
      private static final Mark FAKE_MARK = new Mark("ignore", 0, 0, 0, "", 0);
 }
{code}
 

The rest are small things which I also partially already handled. 

[~maedhroz], [~benedict], please, let me know if you have any other questions 
around this patch.


was (Author: e.dimitrova):
Good catch [~benedict] . Thank you. My bad, just pushed a fast commit 
[here|https://github.com/ekaterinadimitrova2/cassandra/commit/b4eebe080835da79d032f9314262c268b71172a8]
 for the three rate parameters we have. 

For the record, I stopped working on this patch until it is clear whether the 
code will be used at all. As far as I understand, you took the lead on a POC 
development for the newly suggested approach. Unfortunately, I don't have time 
to support this now but I would be happy to give feedback when it is shaped 
already. 

If you decide at some point this work or part of it to be committed, let me 
know, I will complete whatever is outstanding. The main framework is in place.

A couple of things to keep in mind:
 * As suggested by Benjamin, the patch can be simplified by making 
{{Converter}} an {{enum}}. It will allow to use the en

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

2020-07-21 Thread Ekaterina Dimitrova (Jira)



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 7/21/20, 5:53 PM:
---

Good catch [~benedict] . Thank you. My bad, just pushed a fast commit 
[here|https://github.com/ekaterinadimitrova2/cassandra/commit/b4eebe080835da79d032f9314262c268b71172a8]
 for the three rate parameters we have. 

For the record, I stopped working on this patch until it is clear whether the 
code will be used at all. As far as I understand, you took the lead on a POC 
development for the newly suggested approach. Unfortunately, I don't have time 
to support this now but I would be happy to give feedback when it is shaped 
already. 

If you decide at some point this work or part of it to be committed, let me 
know, I will complete whatever is outstanding. The main framework is in place.

A couple of things to keep in mind:
 * As suggested by Benjamin, the patch can be simplified by making 
{{Converter}} an {{enum}}. It will allow to use the enum value directly into 
the {{Replaces}} annotation. Doing so will remove the need to use reflection to 
instantiate the converters and the use of a cache to avoid multiple 
instantiation.
 * In-jvm tests - loading config parameters should be reworked as currently 
they don't work with custom types (like the newly introduced Duration, etc). 
The suggested approach by [~dcapwell] would work but it requires also api 
changes. I suggest a separate ticket for this part to be opened. Instead of 
using reflection, the suggestion is to use SnakeYAML. In order not to slow down 
the tests, no yaml files will be introduced but there will be a function to 
build the yaml nodes for us. This was a quick POC by [~dcapwell] but there are 
parameters which will need additional work and attention:

 
{code:java}
public class MapToConfigTest
 {
     @Test
     public void test()
     {
          Map map = ImmutableMap.builder()
                                                          
.put("auto_bootstrap", false)
                                                          
.put("permissions_validity_in_ms", 10)
                                                          .put("role_manager", 
"some value")
                                                          .build(); Constructor 
constructor = new YamlConfigurationLoader.CustomConstructor(Config.class);
         PropertiesChecker propertiesChecker = new PropertiesChecker();
         constructor.setPropertyUtils(propertiesChecker);
         constructor.setComposer(new Composer(null, null)
         {
              public Node getSingleNode()
             {
                return toNode(map);
             }
          });
            Config config = (Config) constructor.getSingleData(Config.class);
           System.out.println("trap");
     }

     public static Node toNode(Object object)
     {
          if (object instanceof Map)
          {
               List values = new ArrayList<>();
               for (Map.Entry e : ((Map) 
object).entrySet())
               {
                    values.add(new NodeTuple(toNode(e.getKey()), 
toNode(e.getValue(;
               }
               return new MappingNode(FAKE_TAG, values, null);
           }
           else if (object instanceof Number || object instanceof String || 
object instanceof Boolean)
           {
               return new ScalarNode(FAKE_TAG, object.toString(), FAKE_MARK, 
FAKE_MARK, '\''); 
   }
          else
          {
                throw new UnsupportedOperationException("unexpected type found: 
given " + object.getClass());
          }
      }
      private static final Tag FAKE_TAG = new Tag("ignore");
      private static final Mark FAKE_MARK = new Mark("ignore", 0, 0, 0, "", 0);
 }
{code}
 

The rest are small things which I also partially already handled. 

[~maedhroz], [~benedict], please, let me know if you have any other questions 
around this patch.


was (Author: e.dimitrova):
Good catch [~benedict] . Thank you. My bad, just pushed a fast commit 
[here|https://github.com/ekaterinadimitrova2/cassandra/commit/b4eebe080835da79d032f9314262c268b71172a8]
 for the three rate parameters we have. 

For the record, I stopped working on this patch until it is clear whether the 
code will be used at all. As far as I understand, you took the lead on a POC 
development for the newly suggested approach. Unfortunately, I don't have time 
to support this now but I would be happy to give feedback when it is shaped 
already. 

If you decide at some point this work or part of it to be committed, let me 
know, I will complete whatever is outstanding. The main framework is in place.

A couple of things to keep in mind:
 * As suggested by Benjamin, the patch can be simplified by making 
{{Converter}} an {{enum}}. It will allow to use the e

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

2020-07-21 Thread Ekaterina Dimitrova (Jira)



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 7/21/20, 5:42 PM:
---

Good catch [~benedict] . Thank you. My bad, just pushed a fast commit 
[here|https://github.com/ekaterinadimitrova2/cassandra/commit/b4eebe080835da79d032f9314262c268b71172a8]
 for the three rate parameters we have. 

For the record, I stopped working on this patch until it is clear whether the 
code will be used at all. As far as I understand, you took the lead on a POC 
development for the newly suggested approach. Unfortunately, I don't have time 
to support this now but I would be happy to give feedback when it is shaped 
already. 

If you decide at some point this work or part of it to be committed, let me 
know, I will complete whatever is outstanding. The main framework is in place.

A couple of things to keep in mind:
 * As suggested by Benjamin, the patch can be simplified by making 
{{Converter}} an {{enum}}. It will allow to use the enum value directly into 
the {{Replaces}} annotation. Doing so will remove the need to use reflection to 
instantiate the converters and the use of a cache to avoid multiple 
instantiation.
 * In-jvm tests - loading config parameters should be reworked as currently 
they don't work with custom types (like the newly introduced Duration, etc). 
The suggested approach by [~dcapwell] would work but it requires also api 
changes. I suggest a separate ticket for this part to be opened. Instead of 
using reflection, the suggestion is to use SnakeYAML. In order not to slow down 
the tests, no yaml files will be introduced but there will be a function to 
build the yaml nodes for us. This was a quick POC by [~dcapwell] but there are 
parameters which will need additional work and attention:

 
public class MapToConfigTest
{
@Test
public void test()
{
Map map = ImmutableMap.builder()
  .put("auto_bootstrap", false)
  .put("permissions_validity_in_ms", 10)
  .put("role_manager", "some value")
  .build();Constructor constructor = 
new YamlConfigurationLoader.CustomConstructor(Config.class);
PropertiesChecker propertiesChecker = new PropertiesChecker();
constructor.setPropertyUtils(propertiesChecker);
constructor.setComposer(new Composer(null, null) {
public Node getSingleNode()
{
return toNode(map);
}
});Config config = (Config) 
constructor.getSingleData(Config.class);
System.out.println("trap");
}public static Node toNode(Object object)
{
if (object instanceof Map)
{
List values = new ArrayList<>();
for (Map.Entry e : ((Map) 
object).entrySet())
{
values.add(new NodeTuple(toNode(e.getKey()), 
toNode(e.getValue(;
}
return new MappingNode(FAKE_TAG, values, null);
}
else if (object instanceof Number || object instanceof String || object 
instanceof Boolean)
{
return new ScalarNode(FAKE_TAG, object.toString(), FAKE_MARK, 
FAKE_MARK, '\'');
}
else
{
throw new UnsupportedOperationException("unexpected type found: 
given " + object.getClass());
}
}private static final Tag FAKE_TAG = new Tag("ignore");
private static final Mark FAKE_MARK = new Mark("ignore", 0, 0, 0, "", 0);
}

 The rest are small things which I also partially already handled. 

[~maedhroz], [~benedict], please, let me know if you have any other questions 
around this patch.


was (Author: e.dimitrova):
Good catch [~benedict] . Thank you. My bad, just pushed a fast commit 
[here|https://github.com/ekaterinadimitrova2/cassandra/commit/b4eebe080835da79d032f9314262c268b71172a8]
 for the three rate parameters we have. 

For the record, I stopped working on this patch until it is clear whether the 
code will be used at all. As far as I understand, you took the lead on a POC 
development for the newly suggested approach. Unfortunately, I don't have time 
to support this now but I would be happy to give feedback when it is shaped 
already. 

If you decide at some point this work or part of it to be committed, let me 
know, I will complete whatever is outstanding. The main framework is in place.

A couple of things to keep in mind:
 * As suggested by Benjamin, the patch can be simplified by making 
{{Converter}} an {{enum}}. It will allow to use the enum value directly into 
the {{Replaces}} annotation. Doing so will remove the need to use reflection to 
instantiate the converters and the use of a cache to avoid multiple 
instantiation.
 * In-jvm tests

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

2020-07-17 Thread Benedict Elliott Smith (Jira)



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

Benedict Elliott Smith edited comment on CASSANDRA-15234 at 7/17/20, 10:19 AM:
---

Thanks Caleb for the reminder.  I've [pushed another 
approach|https://github.com/belliottsmith/cassandra/tree/CASSANDRA-15234-grouping-ideas],
 that groups options by the reason the operator cares about them, namely: 
* {{cluster}}-wide settings (partitioner, token etc)
* {{disk}} options that specify strategy, throttle throughput etc
* {{memory}} options that allocate heap or direct memory resources
* {{concurrency}} that constrain the number of operations or threads committed 
to tasks
* {{internode}} and {{client}} networking options 
* {{feature}} options; and
* {{log}} options for our warning thresholds etc

It was taking a while, and it might not be well received, so I only went about 
90% of the way so that the approach can receive some feedback.  Obviously, this 
would necessitate a different approach to the headline comments, wherein we 
might want to list the parameters users might care about in prose alongside 
explanations for why they might care.

I personally would like to propose we also introduce a dual system for updating 
properties, wherein we can accept the nested namespace versions, as well as 
e.g. dot-delimited versions.  e.g. {{disk.throttle.compaction: 10MiB/s}}. This 
should mitigate any risk to simplistic tools, as well as maybe providing us a 
simple route to permitting common options being given at the start of the file, 
without confusing the overall approach.

[~e.dimitrova]: in going through the yaml, I noticed that you have used mbps in 
many places, but I thought we had previously agreed that any {{bps}} was 
ambiguous, since it can mean bits or bytes?  I thought we had settled on MiB/s 
so that there could be no ambiguity?  (Since MB/s is also ambiguous - 
technically meaning 1000s, but often meaning powers of 2)?


was (Author: benedict):
Thanks Caleb for the reminder.  I've pushed another approach, that groups 
options by the reason the operator cares about them, namely: 
* {{cluster}}-wide settings (partitioner, token etc)
* {{disk}} options that specify strategy, throttle throughput etc
* {{memory}} options that allocate heap or direct memory resources
* {{concurrency}} that constrain the number of operations or threads committed 
to tasks
* {{internode}} and {{client}} networking options 
* {{feature}} options; and
* {{log}} options for our warning thresholds etc

It was taking a while, and it might not be well received, so I only went about 
90% of the way so that the approach can receive some feedback.  Obviously, this 
would necessitate a different approach to the headline comments, wherein we 
might want to list the parameters users might care about in prose alongside 
explanations for why they might care.

I personally would like to propose we also introduce a dual system for updating 
properties, wherein we can accept the nested namespace versions, as well as 
e.g. dot-delimited versions.  e.g. {{disk.throttle.compaction: 10MiB/s}}. This 
should mitigate any risk to simplistic tools, as well as maybe providing us a 
simple route to permitting common options being given at the start of the file, 
without confusing the overall approach.

[~e.dimitrova]: in going through the yaml, I noticed that you have used mbps in 
many places, but I thought we had previously agreed that any {{bps}} was 
ambiguous, since it can mean bits or bytes?  I thought we had settled on MiB/s 
so that there could be no ambiguity?  (Since MB/s is also ambiguous - 
technically meaning 1000s, but often meaning powers of 2)?

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-beta
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

2020-07-17 Thread Benedict Elliott Smith (Jira)



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

Benedict Elliott Smith edited comment on CASSANDRA-15234 at 7/17/20, 10:17 AM:
---

Thanks Caleb for the reminder.  I've pushed another approach, that groups 
options by the reason the operator cares about them, namely: 
* {{cluster}}-wide settings (partitioner, token etc)
* {{disk}} options that specify strategy, throttle throughput etc
* {{memory}} options that allocate heap or direct memory resources
* {{concurrency}} that constrain the number of operations or threads committed 
to tasks
* {{internode}} and {{client}} networking options 
* {{feature}} options; and
* {{log}} options for our warning thresholds etc

It was taking a while, and it might not be well received, so I only went about 
90% of the way so that the approach can receive some feedback.  Obviously, this 
would necessitate a different approach to the headline comments, wherein we 
might want to list the parameters users might care about in prose alongside 
explanations for why they might care.

I personally would like to propose we also introduce a dual system for updating 
properties, wherein we can accept the nested namespace versions, as well as 
e.g. dot-delimited versions.  e.g. {{disk.throttle.compaction: 10MiB/s}}. This 
should mitigate any risk to simplistic tools, as well as maybe providing us a 
simple route to permitting common options being given at the start of the file, 
without confusing the overall approach.

[~e.dimitrova]: in going through the yaml, I noticed that you have used mbps in 
many places, but I thought we had previously agreed that any {{bps}} was 
ambiguous, since it can mean bits or bytes?  I thought we had settled on MiB/s 
so that there could be no ambiguity?  (Since MB/s is also ambiguous - 
technically meaning 1000s, but often meaning powers of 2)?


was (Author: benedict):
Thanks Caleb for the reminder.  I've pushed another approach, that groups 
options by the reason the operator cares about them, namely: {{cluster}}-wide 
settings (partitioner, token etc), {{disk}} options that specify strategy, 
throttle throughput etc, {{memory}} options that allocate heap or direct memory 
resources, {{concurrency}} that constrain the number of operations or threads 
committed to tasks, {{internode}} and {{client}} networking options, 
{{feature}} options and {{log}} options for our warning thresholds etc.  It was 
taking a while, and it might not be well received, so I only went about 90% of 
the way so that the approach can receive some feedback.  Obviously, this would 
necessitate a different approach to the headline comments, wherein we might 
want to list the parameters users might care about in prose alongside 
explanations for why they might care.

I personally would like to propose we also introduce a dual system for updating 
properties, wherein we can accept the nested namespace versions, as well as 
e.g. dot-delimited versions.  e.g. {{disk.throttle.compaction: 10MiB/s}}

[~e.dimitrova]: in going through the yaml, I noticed that you have used mbps in 
many places, but I thought we had previously agreed that any {{bps}} was 
ambiguous, since it can mean bits or bytes?  I thought we had settled on MiB/s 
so that there could be no ambiguity?  (Since MB/s is also ambiguous - 
technically meaning 1000s, but often meaning powers of 2)?

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-beta
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for either 
> their old or new definition e.g. {{KiB/s}}, or we could support them and 
> simply log the value in bytes/s.



--
This message was sent b

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

2020-07-16 Thread Caleb Rackliffe (Jira)



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

Caleb Rackliffe edited comment on CASSANDRA-15234 at 7/17/20, 5:32 AM:
---

[~e.dimitrova] [~benedict] I've posted [a rough 
sketch|https://github.com/maedhroz/cassandra/commit/49e83c70eba3357978d1081ecf500bbbdee960d8]
 of what a fairly aggressive application of option grouping would look like for 
{{cassandra.yaml}}. Hopefully that helps keep the conversation moving forward. 
The biggest change I made to the existing structure was placing options for the 
same component in the same group, rather than having "commonly used" and 
"advanced" options (in some cases) in totally different parts of the file.


was (Author: maedhroz):
[~e.dimitrova] [~benedict] I've posted [a rough 
sketch|https://github.com/maedhroz/cassandra/commit/49e83c70eba3357978d1081ecf500bbbdee960d8]
 of what a fairly aggressive application of option grouping would look like for 
{{cassandra.yaml}}. Hopefully that helps keep the conversation moving forward...

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-beta
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for either 
> their old or new definition e.g. {{KiB/s}}, or we could support them and 
> simply log the value in bytes/s.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

2020-07-06 Thread Michael Semb Wever (Jira)

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

Michael Semb Wever edited comment on CASSANDRA-15234 at 7/6/20, 8:30 PM:
-

{quote}I am fine to be proved wrong in a justified way. Benedict Elliott Smith,
Benjamin Lerer, Michael Semb Wever, do you agree with me on my
suggestion(reorganizing the yaml file and doing the nested parameters approach
later)?
{quote}
Let's keep listening to what everyone has to say. Some of us are better with
the written word than others, it is a second language for some, and for me as a
native-english-speaker it is still all too easy to miss things the first time
they are said. On that, I believe everyone hears and recognises what
[~e.dimitrova] is saying here regarding frustrations about such a substantial
change being suggested so late in the game and the amount of time that's been
asked to re-invest. Especially when an almost identical user experience
improvement was presented two months ago. But it should be said again.

On a side-note, it would have really helped me a lot if the comment
[above|https://issues.apache.org/jira/browse/CASSANDRA-15234?focusedCommentId=17150521&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17150521]
back-referenced [this
discussion|https://github.com/apache/cassandra/pull/659#discussion_r449201020]
where it originated. I know the ticket was referenced, but that discussion
thread is the source of the suggestion.

{quote}This ticket’s API replaces the current API, is mutually exclusive with
the alternative proposal, and would be deprecated by it. If we introduce them
both in 4.0-beta, we must maintain them both and go through the full
deprecation process. So unfortunately no churn is avoided.
{quote}
AFAIK this is the only "grounded" justification for the veto. I don't agree
that we are forced into that premise. We can get around those compatibility
rules with a minimal amount of effort, by not deprecating the old API and not
announcing (in docs or yaml) the new API. (I would expect everyone to
intuitively treat private undocumented and un-referenced APIs, only ever
available in alpha and beta releases, as unsupported.) All that "compatibility
change" can be left and just done once in the separate ticket. The underlying
framework and bulk of this patch can still be merged.

Based on that I see three possible courses of action:
1. Accept investigating the alternative proposal, and include it in this
ticket, delaying our first 4.0-beta release,
2. As (1) but requesting this ticket to be merged during 4.0-beta, so we can
release 4.0-beta now,
3. Spin out the new suggestion and all public API changes to a separate
ticket, slated for 4.0-beta, and merging this ticket.

I suspect, since you have offered to help [~benedict], that most are in favour
of (2) ?

was (Author: michaelsembwever):
{quote}I am fine to be proved wrong in a justified way. Benedict Elliott Smith,
Benjamin Lerer, Michael Semb Wever, do you agree with me on my
suggestion(reorganizing the yaml file and doing the nested parameters approach
later)?
{quote}
Let's keep listening to what everyone has to say. Some of us are better with
the written word than others, it is a second language for some, and for me as a
native-english-speaker it is still all too easy to miss things the first time
they are said. On that, I believe everyone hears and recognises what
[~e.dimitrova] is saying here regarding frustrations about such a substantial
change being suggested so late in the game and the amount of time that's been
asked to re-invest. Especially when an almost identical user experience
improvement was presented two months ago. But it should be said again.

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

2020-07-06 Thread Michael Semb Wever (Jira)

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

Michael Semb Wever edited comment on CASSANDRA-15234 at 7/6/20, 7:09 PM:
-

{quote}This ticket’s API replaces the current API, is mutually exclusive with
the alternative proposal, and would be deprecated by it. If we introduce them
both in 4.0-beta, we must maintain them both and go through the full
deprecation process. So unfortunately no churn is avoided.
{quote}
AFAIK this is the only "grounded" justification for the veto. I don't agree
that we are forced into that premise. We can get around those compatibility
rules with a minimal amount of effort, by not deprecating the old API and not
announcing (in docs or yaml) the new API. (I would expect everyone to
intuitively treat private undocumented and un-referenced APIs, only ever
available in alpha and beta releases, to be considered unsupported.) All that
"compatibility change" can be left and just done once in the separate ticket.
The underlying framework and bulk of this patch can still be merged.

I suspect, since you have offered to help [~benedict], that most are in favour
of (2) ?

On a side-note, it would have really helped me a lot if the comment above
back-referenced [this
discussion|https://github.com/apache/cassandra/pull/659#discussion_r449201020]
where it originated. I know the ticket was referenced, but that discussion
thread is the source of the suggestion.

{quote}This ticket’s API replaces the current API, is mutually exclusive with
the alternative proposal, and would be deprecated by it. If we introduce them
both in 4.0-beta, we must maintain them both and go through the full
deprecation process. So unfortunately no churn is avoided.
{quote}
AFAIK this is the only "grounded" justification for the veto. I don't agree
that we are forced into that premise. We can get around those compatibility
rules with a minimal amount of effort, by not deprecating the old API and not
announcing (in docs or yaml) the new API. (I would expect everyone to
intuitively treat private undocumented and un-referenced APIs, only ever
available in alpha and beta releases, to be considered unsupported.) All that
"compatibil

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

2020-07-06 Thread Caleb Rackliffe (Jira)



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

Caleb Rackliffe edited comment on CASSANDRA-15234 at 7/6/20, 6:00 PM:
--

My mental model of why grouping _might_ be valuable:
 * It provides a logical place to describe/comment on entire features in the 
YAML.
 * It avoids duplicate/unwieldy prefixing without sacrificing 
intelligibility/specificity.
 * It doesn't rely on the presence of comments.

My understanding of the changes here is that there are dozens of options that 
have already been renamed. Assuming we proceed with grouping, supporting three 
different forms of these options doesn't seem like the outcome we want. There 
are really only a handful of groupings that would be interesting and obvious. 
Essentially, hinted handoff, commitlog, memtable, rpc, compaction, and maybe 
the caches. (Timeouts seem a bit scattered.)

What I'm most worried about is the number of versions we have to support at any 
given time, not whether we change some option grouping early in the beta 
period. My vote, at this point, would be to just move this issue to beta and 
hash out a proposal for the (somewhat obvious) option groups I've mentioned 
above.


was (Author: maedhroz):
My mental model of why grouping _might_ be valuable:
 * It provides a logical place to describe/comment on entire features in the 
YAML.
 * It avoids duplicate prefixing without sacrificing 
intelligibility/specificity.
 * It doesn't rely on the presence of comments.

My understanding of the changes here is that there are dozens of options that 
have already been renamed. Assuming we proceed with grouping, supporting three 
different forms of these options doesn't seem like the outcome we want. There 
are really only a handful of groupings that would be interesting and obvious. 
Essentially, hinted handoff, commitlog, memtable, rpc, compaction, and maybe 
the caches. (Timeouts seem a bit scattered.)

What I'm most worried about is the number of versions we have to support at any 
given time, not whether we change some option grouping early in the beta 
period. My vote, at this point, would be to just move this issue to beta and 
hash out a proposal for the (somewhat obvious) option groups I've mentioned 
above.

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for either 
> their old or new definition e.g. {{KiB/s}}, or we could support them and 
> simply log the value in bytes/s.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 7/6/20, 5:08 PM:
--

Apologize for my late response. I was a bit sick these days and tried to 
disengage from work and take some rest over the weekend.

With all my respect to everyone's opinion and experience on the project, I have 
two points here:
 - I truly support [~mck]'s questions. I believe they should be responded 
before any decision is taken and someone jumps into actual work.
{quote}how many settings does it apply to?
 is taxonomy based on a technical or user perspective?
 if user/operator based, how many people need to be involved to get it right?
 if user/operator based, what if one property applies to multiple concerns?
 how does the @Replace annotation work between levels in the grouping?
 does this introduce more complexity/variations in what has to be tested? 
(since yaml can consist of old and new setting names)
{quote}
 - I was also wondering today while I was trying to be open-minded and look 
from all perspectives at this ticket/patch... Did anyone check the first 
[commit 
|https://github.com/ekaterinadimitrova2/cassandra/blob/CASSANDRA-15234-1-outdated/conf/cassandra.yaml]
 where I was suggesting reorganizing of the text into the yaml into sections? I 
also put it into the ticket thread . 
 This was a quick draft shared two months ago that could be reworked to 
sections that satisfy the users' requirements for clarity and consistency.

Do we see any big difference for the users between:
{code:java}
#*Replica Filtering Protection*

cached_rows_warn_threshold: 1000
cached_rows_fail_threshold: 16000
{code}
and:
{code:java}
replica_filtering_protection:
 - cached_rows_warn_threshold: 1000
 - cached_rows_fail_threshold: 16000
{code}
>From that perspective, I think the C* community can accept this patch and then 
>we can raise a new ticket) to improve the internals from our engineering 
>perspective in Beta(refactoring the Config class and the backward 
>compatibility framework), as suggested by [~mck]. I think this work could be 
>really considered incremental work.

Having that in mind, honestly, I don't find a justification to spend my time to 
rework and fully re-test the patch at this point in time.

I am fine to be proved wrong in a justified way. [~benedict], [~blerer], 
[~mck], do you agree with me on my suggestion(reorganizing the yaml file and 
doing the nested parameters approach later)?

 

{quote} I think this is indeed preferable to releasing an API we already expect 
to deprecate, however I think we're overstating the difficulty here. We haven't 
debated the parameter naming much at all, and we can easily land this in 
4.0-beta. If [~e.dimitrova] doesn't have the time, and 4.0-beta is an 
acceptable window to land the work, I can take a look in a few weeks.  {quote}

 

I want to be clear - it is not about difficulty, this patch is time consuming. 
It needs attention to the detail and look at the whole config which touches the 
code at many places(also ccm, dtests, in-jvm tests, etc)

 


was (Author: e.dimitrova):
Apologize for my late response. I was a bit sick these days and tried to 
disengage from work and take some rest over the weekend.

With all my respect to everyone's opinion and experience on the project, I have 
two points here:
 - I truly support [~mck]'s questions. I believe they should be responded 
before any decision is taken and someone jumps into actual work.
{quote}how many settings does it apply to?
 is taxonomy based on a technical or user perspective?
 if user/operator based, how many people need to be involved to get it right?
 if user/operator based, what if one property applies to multiple concerns?
 how does the @Replace annotation work between levels in the grouping?
 does this introduce more complexity/variations in what has to be tested? 
(since yaml can consist of old and new setting names)
{quote}
 - I was also wondering today while I was trying to be open-minded and look 
from all perspectives at this ticket/patch... Did anyone check the first 
[commit 
|https://github.com/ekaterinadimitrova2/cassandra/blob/CASSANDRA-15234-1-outdated/conf/cassandra.yaml]
 where I was suggesting reorganizing of the text into the yaml into sections? I 
also put it into the ticket thread . 
 This was a quick draft shared two months ago that could be reworked to 
sections that satisfy the users' requirements for clarity and consistency.

Do we see any big difference for the users between:
{code:java}
#*Replica Filtering Protection*

cached_rows_warn_threshold: 1000
cached_rows_fail_threshold: 16000
{code}
and:
{code:java}
replica_filtering_protection:
 - cached_rows_warn_threshold: 1000
 - cached_rows_fail_threshold: 16000
{code}
>From that p

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 7/6/20, 5:07 PM:
--

Apologize for my late response. I was a bit sick these days and tried to 
disengage from work and take some rest over the weekend.

With all my respect to everyone's opinion and experience on the project, I have 
two points here:
 - I truly support [~mck]'s questions. I believe they should be responded 
before any decision is taken and someone jumps into actual work.
{quote}how many settings does it apply to?
 is taxonomy based on a technical or user perspective?
 if user/operator based, how many people need to be involved to get it right?
 if user/operator based, what if one property applies to multiple concerns?
 how does the @Replace annotation work between levels in the grouping?
 does this introduce more complexity/variations in what has to be tested? 
(since yaml can consist of old and new setting names)
{quote}
 - I was also wondering today while I was trying to be open-minded and look 
from all perspectives at this ticket/patch... Did anyone check the first 
[commit 
|https://github.com/ekaterinadimitrova2/cassandra/blob/CASSANDRA-15234-1-outdated/conf/cassandra.yaml]
 where I was suggesting reorganizing of the text into the yaml into sections? I 
also put it into the ticket thread . 
 This was a quick draft shared two months ago that could be reworked to 
sections that satisfy the users' requirements for clarity and consistency.

Do we see any big difference for the users between:
{code:java}
#*Replica Filtering Protection*

cached_rows_warn_threshold: 1000
cached_rows_fail_threshold: 16000
{code}
and:
{code:java}
replica_filtering_protection:
 - cached_rows_warn_threshold: 1000
 - cached_rows_fail_threshold: 16000
{code}
>From that perspective, I think the C* community can accept this patch and then 
>we can raise a new ticket) to improve the internals from our engineering 
>perspective in Beta(refactoring the Config class and the backward 
>compatibility framework), as suggested by [~mck]. I think this work could be 
>really considered incremental work.

Having that in mind, honestly, I don't find a justification to spend my time to 
rework and fully re-test the patch at this point in time.

I am fine to be proved wrong in a justified way. [~benedict], [~blerer], 
[~mck], do you agree with me on my suggestion(reorganizing the yaml file and 
doing the nested parameters approach later)?

 

{quote} I think this is indeed preferable to releasing an API we already expect 
to deprecate, however I think we're overstating the difficulty here. We haven't 
debated the parameter naming much at all, and we can easily land this in 
4.0-beta. If [~e.dimitrova] doesn't have the time, and 4.0-beta is an 
acceptable window to land the work, I can take a look in a few weeks. \{quote}

 

I want to be clear - it is not about difficulty, this patch is time consuming. 
It needs attention to the detail and look at the whole config which touches the 
code at many places(also ccm, dtests, in-jvm tests, etc)

 


was (Author: e.dimitrova):
Apologize for my late response. I was a bit sick these days and tried to 
disengage from work and take some rest over the weekend.

With all my respect to everyone's opinion and experience on the project, I have 
two points here:
 - I truly support [~mck]'s questions. I believe they should be responded 
before any decision is taken and someone jumps into actual work.
{quote}how many settings does it apply to?
 is taxonomy based on a technical or user perspective?
 if user/operator based, how many people need to be involved to get it right?
 if user/operator based, what if one property applies to multiple concerns?
 how does the @Replace annotation work between levels in the grouping?
 does this introduce more complexity/variations in what has to be tested? 
(since yaml can consist of old and new setting names)
{quote}
 - I was also wondering today while I was trying to be open-minded and look 
from all perspectives at this ticket/patch... Did anyone check the first 
[commit 
|https://github.com/ekaterinadimitrova2/cassandra/blob/CASSANDRA-15234-1-outdated/conf/cassandra.yaml]
 where I was suggesting reorganizing of the text into the yaml into sections? I 
also put it into the ticket thread . 
 This was a quick draft shared two months ago that could be reworked to 
sections that satisfy the users' requirements for clarity and consistency.

Do we see any big difference for the users between:
{code:java}
#*Replica Filtering Protection*

cached_rows_warn_threshold: 1000
cached_rows_fail_threshold: 16000
{code}
and:
{code:java}
replica_filtering_protection:
 - cached_rows_warn_threshold: 1000
 - cached_rows_fail_threshold: 16000
{code}
>From that p

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 7/6/20, 5:06 PM:
--

Apologize for my late response. I was a bit sick these days and tried to 
disengage from work and take some rest over the weekend.

With all my respect to everyone's opinion and experience on the project, I have 
two points here:
 - I truly support [~mck]'s questions. I believe they should be responded 
before any decision is taken and someone jumps into actual work.
{quote}how many settings does it apply to?
 is taxonomy based on a technical or user perspective?
 if user/operator based, how many people need to be involved to get it right?
 if user/operator based, what if one property applies to multiple concerns?
 how does the @Replace annotation work between levels in the grouping?
 does this introduce more complexity/variations in what has to be tested? 
(since yaml can consist of old and new setting names)
{quote}
 - I was also wondering today while I was trying to be open-minded and look 
from all perspectives at this ticket/patch... Did anyone check the first 
[commit 
|https://github.com/ekaterinadimitrova2/cassandra/blob/CASSANDRA-15234-1-outdated/conf/cassandra.yaml]
 where I was suggesting reorganizing of the text into the yaml into sections? I 
also put it into the ticket thread . 
 This was a quick draft shared two months ago that could be reworked to 
sections that satisfy the users' requirements for clarity and consistency.

Do we see any big difference for the users between:
{code:java}
#*Replica Filtering Protection*

cached_rows_warn_threshold: 1000
cached_rows_fail_threshold: 16000
{code}
and:
{code:java}
replica_filtering_protection:
 - cached_rows_warn_threshold: 1000
 - cached_rows_fail_threshold: 16000
{code}
>From that perspective, I think the C* community can accept this patch and then 
>we can raise a new ticket) to improve the internals from our engineering 
>perspective in Beta(refactoring the Config class and the backward 
>compatibility framework), as suggested by [~mck]. I think this work could be 
>really considered incremental work.

Having that in mind, honestly, I don't find a justification to spend my time to 
rework and fully re-test the patch at this point in time.

I am fine to be proved wrong in a justified way. [~benedict], [~blerer], 
[~mck], do you agree with me on my suggestion(reorganizing the yaml file and 
doing the nested parameters approach later)?

 

{quote}I think this is indeed preferable to releasing an API we already expect 
to deprecate, however I think we're overstating the difficulty here. We haven't 
debated the parameter naming much at all, and we can easily land this in 
4.0-beta. If [~e.dimitrova] doesn't have the time, and 4.0-beta is an 
acceptable window to land the work, I can take a look in a few weeks. \{quote}

 

I want to be clear - it is not about difficulty, this patch is time consuming. 
It needs attention to the detail and look at the whole config which touches the 
code at many places(also ccm, dtests, in-jvm tests, etc)

 


was (Author: e.dimitrova):
Apologize for my late response. I was a bit sick these days and tried to 
disengage from work and take some rest over the weekend.

With all my respect to everyone's opinion and experience on the project, I have 
two points here:
 - I truly support [~mck]'s questions. I believe they should be responded 
before any decision is taken and someone jumps into actual work.
{quote}how many settings does it apply to?
 is taxonomy based on a technical or user perspective?
 if user/operator based, how many people need to be involved to get it right?
 if user/operator based, what if one property applies to multiple concerns?
 how does the @Replace annotation work between levels in the grouping?
 does this introduce more complexity/variations in what has to be tested? 
(since yaml can consist of old and new setting names)
{quote}
 - I was also wondering today while I was trying to be open-minded and look 
from all perspectives at this ticket/patch... Did anyone check the first 
[commit 
|https://github.com/ekaterinadimitrova2/cassandra/blob/CASSANDRA-15234-1-outdated/conf/cassandra.yaml]
 where I was suggesting reorganizing of the text into the yaml into sections? I 
also put it into the ticket thread . 
 This was a quick draft shared two months ago that could be reworked to 
sections that satisfy the users' requirements for clarity and consistency.

Do we see any big difference for the users between:
{code:java}
#*Replica Filtering Protection*

cached_rows_warn_threshold: 1000
cached_rows_fail_threshold: 16000
{code}
and:
{code:java}
replica_filtering_protection:
 - cached_rows_warn_threshold: 1000
 - cached_rows_fail_threshold: 16000
{code}
>From that pe

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 7/6/20, 5:02 PM:
--

Apologize for my late response. I was a bit sick these days and tried to 
disengage from work and take some rest over the weekend.

With all my respect to everyone's opinion and experience on the project, I have 
two points here:
 - I truly support [~mck]'s questions. I believe they should be responded 
before any decision is taken and someone jumps into actual work.
{quote}how many settings does it apply to?
 is taxonomy based on a technical or user perspective?
 if user/operator based, how many people need to be involved to get it right?
 if user/operator based, what if one property applies to multiple concerns?
 how does the @Replace annotation work between levels in the grouping?
 does this introduce more complexity/variations in what has to be tested? 
(since yaml can consist of old and new setting names)
{quote}
 - I was also wondering today while I was trying to be open-minded and look 
from all perspectives at this ticket/patch... Did anyone check the first 
[commit 
|https://github.com/ekaterinadimitrova2/cassandra/blob/CASSANDRA-15234-1-outdated/conf/cassandra.yaml]
 where I was suggesting reorganizing of the text into the yaml into sections? I 
also put it into the ticket thread . 
 This was a quick draft shared two months ago that could be reworked to 
sections that satisfy the users' requirements for clarity and consistency.

Do we see any big difference for the users between:
{code:java}
#*Replica Filtering Protection*

cached_rows_warn_threshold: 1000
cached_rows_fail_threshold: 16000
{code}
and:
{code:java}
replica_filtering_protection:
 - cached_rows_warn_threshold: 1000
 - cached_rows_fail_threshold: 16000
{code}
>From that perspective, I think the C* community can accept this patch and then 
>we can raise a new ticket) to improve the internals from our engineering 
>perspective in Beta(refactoring the Config class and the backward 
>compatibility framework), as suggested by [~mck]. I think this work could be 
>really considered incremental work.

Having that in mind, honestly, I don't find a justification to spend my time to 
rework and fully re-test the patch at this point in time.

I am fine to be proved wrong in a justified way. [~benedict], [~blerer], 
[~mck], do you agree with me on my suggestion(reorganizing the yaml file and 
doing the nested parameters approach later)?

 

{quote} I think this is indeed preferable to releasing an API we already expect 
to deprecate, however I think we're overstating the difficulty here. We haven't 
debated the parameter naming much at all, and we can easily land this in 
4.0-beta. If [~e.dimitrova] doesn't have the time, and 4.0-beta is an 
acceptable window to land the work, I can take a look in a few weeks. \{quote}

I want to be clear - it is not about difficulty, this patch is time consuming. 
It needs attention to the detail and look at the whole config which touches the 
code at many places(also ccm, dtests, in-jvm tests, etc)

 


was (Author: e.dimitrova):
Apologize for my late response. I was a bit sick these days and tried to 
disengage from work and take some rest over the weekend.

With all my respect to everyone's opinion and experience on the project, I have 
two points here:
 - I truly support [~mck]'s questions. I believe they should be responded 
before any decision is taken and someone jumps into actual work.
{quote}how many settings does it apply to?
 is taxonomy based on a technical or user perspective?
 if user/operator based, how many people need to be involved to get it right?
 if user/operator based, what if one property applies to multiple concerns?
 how does the @Replace annotation work between levels in the grouping?
 does this introduce more complexity/variations in what has to be tested? 
(since yaml can consist of old and new setting names)
{quote}
 - I was also wondering today while I was trying to be open-minded and look 
from all perspectives at this ticket/patch... Did anyone check the first 
[commit 
|https://github.com/ekaterinadimitrova2/cassandra/blob/CASSANDRA-15234-1-outdated/conf/cassandra.yaml]
 where I was suggesting reorganizing of the text into the yaml into sections? I 
also put it into the ticket thread . 
 This was a quick draft shared two months ago that could be reworked to 
sections that satisfy the users' requirements for clarity and consistency.

Do we see any big difference for the users between:
{code:java}
#*Replica Filtering Protection*

cached_rows_warn_threshold: 1000
cached_rows_fail_threshold: 16000
{code}
and:
{code:java}
replica_filtering_protection:
 - cached_rows_warn_threshold: 1000
 - cached_rows_fail_threshold: 16000
{code}
>From that pers

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 7/6/20, 4:57 PM:
--

Apologize for my late response. I was a bit sick these days and tried to 
disengage from work and take some rest over the weekend.

With all my respect to everyone's opinion and experience on the project, I have 
two points here:
 - I truly support [~mck]'s questions. I believe they should be responded 
before any decision is taken and someone jumps into actual work.
{quote}how many settings does it apply to?
 is taxonomy based on a technical or user perspective?
 if user/operator based, how many people need to be involved to get it right?
 if user/operator based, what if one property applies to multiple concerns?
 how does the @Replace annotation work between levels in the grouping?
 does this introduce more complexity/variations in what has to be tested? 
(since yaml can consist of old and new setting names)
{quote}
 - I was also wondering today while I was trying to be open-minded and look 
from all perspectives at this ticket/patch... Did anyone check the first 
[commit 
|https://github.com/ekaterinadimitrova2/cassandra/blob/CASSANDRA-15234-1-outdated/conf/cassandra.yaml]
 where I was suggesting reorganizing of the text into the yaml into sections? I 
also put it into the ticket thread . 
 This was a quick draft shared two months ago that could be reworked to 
sections that satisfy the users' requirements for clarity and consistency.

Do we see any big difference for the users between:
{code:java}
#*Replica Filtering Protection*

cached_rows_warn_threshold: 1000
cached_rows_fail_threshold: 16000
{code}
and:
{code:java}
replica_filtering_protection:
 - cached_rows_warn_threshold: 1000
 - cached_rows_fail_threshold: 16000
{code}
>From that perspective, I think the C* community can accept this patch and then 
>we can raise a new ticket) to improve the internals from our engineering 
>perspective in Beta(refactoring the Config class and the backward 
>compatibility framework), as suggested by [~mck]. I think this work could be 
>really considered incremental work.

Having that in mind, honestly, I don't find a justification to spend my time to 
rework and fully re-test the patch at this point in time.

I am fine to be proved wrong in a justified way. [~benedict], [~blerer], 
[~mck], do you agree with me on my suggestion(reorganizing the yaml file and 
doing the nested parameters approach later)?

 


was (Author: e.dimitrova):
Apologize for my late response. I was a bit sick these days and tried to 
disengage from work and take some rest over the weekend.

With all my respect to everyone's opinion and experience on the project, I have 
two points here:
 - I truly support [~mck]'s questions. I believe they should be responded 
before any decision is taken and someone jumps into actual work.
{quote}how many settings does it apply to?
 is taxonomy based on a technical or user perspective?
 if user/operator based, how many people need to be involved to get it right?
 if user/operator based, what if one property applies to multiple concerns?
 how does the @Replace annotation work between levels in the grouping?
 does this introduce more complexity/variations in what has to be tested? 
(since yaml can consist of old and new setting names)
{quote}
 - I was also wondering today while I was trying to be open-minded and look 
from all perspectives at this ticket/patch... Did anyone check the first 
[commit 
|https://github.com/ekaterinadimitrova2/cassandra/blob/CASSANDRA-15234-1-outdated/conf/cassandra.yaml]
 where I was suggesting reorganizing of the text into the yaml into sections? I 
also put it into the ticket thread. 
This was a quick draft shared two months ago that could be reworked to sections 
that satisfy the users' requirements for clarity and consistency.

 Do we see any big difference for the users between:

{code:java}
#*Replica Filtering Protection*

cached_rows_warn_threshold: 1000
cached_rows_fail_threshold: 16000
{code}
and:
{code:java}
replica_filtering_protection:
 - cached_rows_warn_threshold: 1000
 - cached_rows_fail_threshold: 16000
{code}
>From that perspective, I think the C* community can accept this patch and then 
>we can raise a new ticket) to improve the internals from our engineering 
>perspective in Beta(refactoring the Config class and the backward 
>compatibility framework), as suggested by [~mck]. I think this work could be 
>really considered incremental work.

Having that in mind, honestly, I don't find a justification to spend my time to 
rework and fully re-test the patch at this point in time.

I am fine to be proved wrong in a justified way. [~benedict], [~blerer], 
[~mck], do you agree with me on my suggestion(reorganizing the yaml f

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

2020-07-06 Thread Benedict Elliott Smith (Jira)



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

Benedict Elliott Smith edited comment on CASSANDRA-15234 at 7/6/20, 10:38 AM:
--

bq. The valid concern around the api churn it introduces is addressed by 
committing the new ticket to 4.0-beta.

This ticket’s API replaces the current API, is mutually exclusive with the 
alternative proposal, and would be deprecated by it.  If we introduce them both 
in 4.0-beta, we must maintain them both and go through the full deprecation 
process.  So unfortunately no churn is avoided.

> I'd be curious what your perspective is on how we determine what qualifies as 
> justified

It is customary that, before work is committed, alternative proposals are 
engaged with on their technical merits.  It occurs to me we recently worked to 
mandate this as part of the process, in fact.  In this case we _seem_ in danger 
of subordinating this to beliefs about scheduling.

If you like, I can formulate a legally airtight veto, but my goal is only for 
you to engage briefly with the proposal and determine for yourselves which is 
superior.  If the new proposal is _technically_* superior, and of similar 
complexity, then you are my justification.  If you disagree, however - and 
importantly we agree that we do not intend to pursue the alternative approach 
in future - I would consider my veto invalid (and would anyway withdraw it).

> having heard of the proximity of the beta

Perhaps we can also directly address people’s thoughts on deferral to 4.0-beta? 
 This should surely alleviate concerns around delaying 4.0?  I do understand 
the imperative to get 4.0 out the door, but I also know we all want to ship the 
best product we can as well.  If we can achieve both, we should. APIs matter, 
and avoiding API churn is an important part of our user/operator story.

\* I _hope_ we can avoid an epistemic battle about the word "technical," and 
accept that API design is a technical endeavour to convey meaning.


was (Author: benedict):
bq. The valid concern around the api churn it introduces is addressed by 
committing the new ticket to 4.0-beta.

This ticket’s API replaces the current API, is mutually exclusive with the 
alternative proposal, and would be deprecated by it.  If we introduce them both 
in 4.0-beta, we must maintain them both and go through the full deprecation 
process.  So unfortunately no churn is avoided.

> I'd be curious what your perspective is on how we determine what qualifies as 
> justified

It is customary that, before work is committed, alternative proposals are 
engaged with on their technical merits.  It occurs to me we recently worked to 
mandate this as part of the process, in fact.  In this case we _seem_ in danger 
of subordinating this to beliefs about scheduling.

If you like, I can formulate a legally airtight veto, but my goal is only for 
you to engage briefly with the proposal and determine for yourselves which is 
superior.  If the new proposal is _technically_* superior, and of similar 
complexity, then you are my justification.  If you disagree, however - and 
importantly we agree that we do not intend to pursue the alternative approach 
in future - I would consider my veto invalid (and would anyway withdraw it).

> having heard of the proximity of the beta

Perhaps we can also directly address people’s thoughts on deferral to 4.0-beta? 
 This should surely alleviate concerns around delaying 4.0?  I do understand 
the imperative to get 4.0 out the door, but I also know we all want to ship the 
best product we can as well.  If we can achieve both, we should. APIs matter, 
and avoiding API churn is an important part of our user/operator story.

* I _hope_ we can avoid an epistemic battle about the word "technical," and 
accept that API design is a technical endeavour to convey meaning.

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
>

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

2020-07-04 Thread Benedict Elliott Smith (Jira)



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

Benedict Elliott Smith edited comment on CASSANDRA-15234 at 7/4/20, 2:24 PM:
-

> I am fairly opposed to shipping this in its current form and creating more 
> churn for operators when we change it again in the near future

To be more explicit: I am (binding) -1 knowingly shipping an _interim_ solution 
for a public API.  It is user unfriendly.

I agree it is suboptimal to bring this to the ticket late in the game, but that 
is how the world sometimes works.  This was not capricious or deliberate; 
nobody had thought of or suggested this until now, and everyone has since 
agreed (or implied) this is a superior approach.

If we change our minds and agree the current approach is the final and superior 
solution, that is another matter.

The approaching release of 4.0 should not reduce our attention to detail or 
quality.  We should merge tickets only when we agree they are ready.  This is 
particularly important for tickets whose main impact is improving a public API.

P.S. I would like to take a moment to thank [~e.dimitrova] for her work on this 
(and other tickets).  OSS work can be frustrating sometimes, and I'm sorry if 
this ticket becomes a source of frustration.  It's unfortunately not uncommon 
to have to revisit work, or have work delayed, but please know that it's 
valued.  I am excited for the end product; I think it will be a huge 
improvement when it lands.


was (Author: benedict):
> I am fairly opposed to shipping this in its current form and creating more 
> churn for operators when we change it again in the near future

To be more explicit: I am (binding) -1 knowingly shipping an _interim_ solution 
for a public API.  It is user unfriendly.

I agree it is suboptimal to bring this to the ticket late in the game, but that 
is how the world sometimes works.  This was not capricious or deliberate; 
nobody had thought of or suggested this until now, and everyone has since 
agreed (or implied) this is a superior approach.

If we change our minds and agree the current approach is the final and superior 
solution, that is another matter.

The approaching release of 4.0 should not reduce our attention to detail or 
quality.  We should merge tickets only when we agree they are ready.  This is 
particularly important for tickets whose main impact is improving a public API.

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for either 
> their old or new definition e.g. {{KiB/s}}, or we could support them and 
> simply log the value in bytes/s.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

2020-07-04 Thread Benedict Elliott Smith (Jira)



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

Benedict Elliott Smith edited comment on CASSANDRA-15234 at 7/4/20, 1:56 PM:
-

> I am fairly opposed to shipping this in its current form and creating more 
> churn for operators when we change it again in the near future

To be more explicit: I am (binding) -1 knowingly shipping an _interim_ solution 
for a public API.  It is user unfriendly.

I agree it is suboptimal to bring this to the ticket late in the game, but that 
is how the world sometimes works.  This was not capricious or deliberate; 
nobody had thought of or suggested this until now, and everyone has since 
agreed (or implied) this is a superior approach.

If we change our minds and agree the current approach is the final and superior 
solution, that is another matter.

The approaching release of 4.0 should not reduce our attention to detail or 
quality.  We should merge tickets only when we agree they are ready.  This is 
particularly important for tickets whose main impact is improving a public API.


was (Author: benedict):
> I am fairly opposed to shipping this in its current form and creating more 
> churn for operators when we change it again in the near future

To be more explicit: I am (binding) -1 knowingly shipping an _interim_ solution 
for a public API.  It is user unfriendly.

I agree it is suboptimal to bring this to the ticket late in the game, but that 
is how the world sometimes works.  This was not capricious or deliberate; 
nobody had thought of or suggested this until now, and everyone has since 
agreed this is a superior approach.

If everyone changes their mind and agrees the current approach is the final and 
_superior_ solution, that is another matter.  It would be a bit odd, however, 
given implied positions so far.

The approaching release of 4.0 should not reduce our attention to detail or 
quality.  We should merge tickets only when we agree they are ready.

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for either 
> their old or new definition e.g. {{KiB/s}}, or we could support them and 
> simply log the value in bytes/s.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

2020-07-04 Thread Benedict Elliott Smith (Jira)



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

Benedict Elliott Smith edited comment on CASSANDRA-15234 at 7/4/20, 1:53 PM:
-

> I am fairly opposed to shipping this in its current form and creating more 
> churn for operators when we change it again in the near future

To be more explicit: I am (binding) -1 knowingly shipping an _interim_ solution 
for a public API.  It is user unfriendly.

I agree it is suboptimal to bring this to the ticket late in the game, but that 
is how the world sometimes works.  This was not capricious or deliberate; 
nobody had thought of or suggested this until now, and everyone has since 
agreed this is a superior approach.

If everyone changes their mind and agrees the current approach is the final and 
_superior_ solution, that is another matter.  It would be a bit odd, however, 
given implied positions so far.

The approaching release of 4.0 should not reduce our attention to detail or 
quality.  We should merge tickets only when we agree they are ready.


was (Author: benedict):
> I am fairly opposed to shipping this in its current form and creating more 
> churn for operators when we change it again in the near future

To be more explicit: I am (binding) -1 knowingly shipping an _interim_ solution 
for a public API.  It is user unfriendly.

I agree it is suboptimal to bring this to the ticket late in the game, but that 
is how the world sometimes works.  This was not capricious or deliberate; 
nobody had thought of or suggested this until now, and everyone has since 
agreed this is a superior approach.

If everyone changes their mind and agrees the current approach is the final and 
_superior_ solution, that is another matter.  It would be a bit odd, however, 
implied positions so far.

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for either 
> their old or new definition e.g. {{KiB/s}}, or we could support them and 
> simply log the value in bytes/s.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

2020-07-04 Thread Michael Semb Wever (Jira)



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

Michael Semb Wever edited comment on CASSANDRA-15234 at 7/4/20, 9:21 AM:
-

bq. I don't think this is an absolute necessity for pre-beta, however, given 
that we have agreed for it to be backwards compatible. I don't see any issue 
with landing this in a later beta.

Move it out to a separate ticket, like was done for CASSANDRA-15876. To bring 
additional spec to the table, no matter how good it is, so late in the ticket 
and so close to the first beta, is particularly painful. As a separate ticket 
it can be done during the beta phase. 

Otherwise the settings now have a consistent naming pattern {{_}} 
which, with no unit suffix noise, and better grouping the settings in the yaml, 
already brings a huge improvement.


was (Author: michaelsembwever):
bq. I don't think this is an absolute necessity for pre-beta, however, given 
that we have agreed for it to be backwards compatible. I don't see any issue 
with landing this in a later beta.

Move it out to a separate ticket, like was done for CASSANDRA-15876. To bring 
additional spec to the table, no matter how good it is, so late in the ticket 
and so close to the first beta, is particularly painful. As a separate ticket 
it can be done during the beta phase. 

Otherwise the settings now have a consistent naming pattern {{_}} 
which, no unit suffix noise, and better grouping the settings in the yaml, 
already brings a huge improvement.

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for either 
> their old or new definition e.g. {{KiB/s}}, or we could support them and 
> simply log the value in bytes/s.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

2020-07-03 Thread Benedict Elliott Smith (Jira)



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

Benedict Elliott Smith edited comment on CASSANDRA-15234 at 7/3/20, 10:00 AM:
--

If we agree we will be changing the config parameters next version to this 
alternative approach, then I am fairly opposed to shipping this in its current 
form and creating more churn for operators when we change it again in the near 
future.  The point of this exercise is to clean things up, not make them 
messier, and this includes the perspective of the end user and their ability to 
keep up with our nomenclature.
 
I also think it would be a real shame not to include this work at all, given 
how awful and confusing our parameter naming situation is today.

I don't think this is an absolute necessity for pre-beta, however, given that 
we have agreed for it to be backwards compatible.  I don't see any issue with 
landing this in a later beta.


was (Author: benedict):
If we agree we will be changing the config parameters next version to this 
alternative approach, then I am fairly opposed to shipping this in its current 
form and creating more churn for operators when we change it again in the near 
future.  The point of this exercise is to clean things up, not make them 
messier, and this includes the perspective of the end user and their ability to 
keep up with our nomenclature.
 
I also think it would be a real shame not to include this work at all, given 
how awful and confusing our parameter naming situation is today.

I don't think this is an absolute necessity for pre-beta, however, given that 
it is backwards compatible.  I don't see any issue with landing this in a later 
beta.

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for either 
> their old or new definition e.g. {{KiB/s}}, or we could support them and 
> simply log the value in bytes/s.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 7/2/20, 10:46 PM:
---

Thanks everyone for making a review/ providing a valuable input/advice.
 
{quote}Has this been considered?
{quote}

No, it wasn't considered. I did the renaming as per  [the agreed plan | 
https://issues.apache.org/jira/browse/CASSANDRA-15234?focusedCommentId=17058024&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17058024]
 .

For the rest of the audience, I reached out [~maedhroz] in Slack to understand 
better what is the suggestion. 

The proposed idea is to group parameters in the yaml the way it already happens 
with the encryption options.

*Example:*

Moving in the yaml from:
{code:java}
     cached_rows_warn_threshold: 1000
     cached_rows_fail_threshold: 16000
{code}
{{to:}}
{code:java}
replica_filtering_protection:
     - cached_rows_warn_threshold: 1000
     - cached_rows_fail_threshold: 16000
{code}
*My personal opinion:*

if this is really last beta blocker I wouldn't go for a new round of rework and 
full validation. This patch touches already more than 50 parameters and 
requires backward compatibility. Every change of the framework requires full 
validation and discovers new edge cases as those parameters touch all over the 
code.

*My suggestion:* 

Follow the suggestion for new parameters creation. Implement the suggested 
refactoring in the next major version. 

 


was (Author: e.dimitrova):
Thanks everyone for making a review/ providing a valuable input/advice.

 
{quote}Has this been considered?
{quote}
 

 

No, it wasn't considered. I did the renaming as per  [the agreed plan | 
https://issues.apache.org/jira/browse/CASSANDRA-15234?focusedCommentId=17058024&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17058024]
 .

For the rest of the audience, I reached out [~maedhroz] in Slack to understand 
better what is the suggestion. 

The proposed idea is to group parameters in the yaml the way it already happens 
with the encryption options.

*Example:*

Moving in the yaml from:
{code:java}
     cached_rows_warn_threshold: 1000
     cached_rows_fail_threshold: 16000
{code}
{{to:}}
{code:java}
replica_filtering_protection:
     - cached_rows_warn_threshold: 1000
     - cached_rows_fail_threshold: 16000
{code}
*My personal opinion:*

if this is really last beta blocker I wouldn't go for a new round of rework and 
full validation. This patch touches already more than 50 parameters and 
requires backward compatibility. Every change of the framework requires full 
validation and discovers new edge cases as those parameters touch all over the 
code.

*My suggestion:* 

Follow the suggestion for new parameters creation. Implement the suggested 
refactoring in the next major version. 

 

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for either 
> their old or new definition e.g. {{KiB/s}}, or we could support them and 
> simply log the value in bytes/s.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 7/2/20, 10:46 PM:
---

Thanks everyone for making a review/ providing a valuable input/advice.
 
{quote}Has this been considered?
{quote}

No, it wasn't considered. I did the renaming and its backward compatibility as 
per  [the agreed plan | 
https://issues.apache.org/jira/browse/CASSANDRA-15234?focusedCommentId=17058024&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17058024]
 .

For the rest of the audience, I reached out [~maedhroz] in Slack to understand 
better what is the suggestion. 

The proposed idea is to group parameters in the yaml the way it already happens 
with the encryption options.

*Example:*

Moving in the yaml from:
{code:java}
     cached_rows_warn_threshold: 1000
     cached_rows_fail_threshold: 16000
{code}
{{to:}}
{code:java}
replica_filtering_protection:
     - cached_rows_warn_threshold: 1000
     - cached_rows_fail_threshold: 16000
{code}
*My personal opinion:*

if this is really last beta blocker I wouldn't go for a new round of rework and 
full validation. This patch touches already more than 50 parameters and 
requires backward compatibility. Every change of the framework requires full 
validation and discovers new edge cases as those parameters touch all over the 
code.

*My suggestion:* 

Follow the suggestion for new parameters creation. Implement the suggested 
refactoring in the next major version. 

 


was (Author: e.dimitrova):
Thanks everyone for making a review/ providing a valuable input/advice.
 
{quote}Has this been considered?
{quote}

No, it wasn't considered. I did the renaming as per  [the agreed plan | 
https://issues.apache.org/jira/browse/CASSANDRA-15234?focusedCommentId=17058024&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17058024]
 .

For the rest of the audience, I reached out [~maedhroz] in Slack to understand 
better what is the suggestion. 

The proposed idea is to group parameters in the yaml the way it already happens 
with the encryption options.

*Example:*

Moving in the yaml from:
{code:java}
     cached_rows_warn_threshold: 1000
     cached_rows_fail_threshold: 16000
{code}
{{to:}}
{code:java}
replica_filtering_protection:
     - cached_rows_warn_threshold: 1000
     - cached_rows_fail_threshold: 16000
{code}
*My personal opinion:*

if this is really last beta blocker I wouldn't go for a new round of rework and 
full validation. This patch touches already more than 50 parameters and 
requires backward compatibility. Every change of the framework requires full 
validation and discovers new edge cases as those parameters touch all over the 
code.

*My suggestion:* 

Follow the suggestion for new parameters creation. Implement the suggested 
refactoring in the next major version. 

 

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for either 
> their old or new definition e.g. {{KiB/s}}, or we could support them and 
> simply log the value in bytes/s.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 7/2/20, 10:46 PM:
---

Thanks everyone for making a review/ providing a valuable input/advice.

 
{quote}Has this been considered?
{quote}
 

 

No, it wasn't considered. I did the renaming as per  [the agreed plan | 
https://issues.apache.org/jira/browse/CASSANDRA-15234?focusedCommentId=17058024&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17058024]
 .

For the rest of the audience, I reached out [~maedhroz] in Slack to understand 
better what is the suggestion. 

The proposed idea is to group parameters in the yaml the way it already happens 
with the encryption options.

*Example:*

Moving in the yaml from:
{code:java}
     cached_rows_warn_threshold: 1000
     cached_rows_fail_threshold: 16000
{code}
{{to:}}
{code:java}
replica_filtering_protection:
     - cached_rows_warn_threshold: 1000
     - cached_rows_fail_threshold: 16000
{code}
*My personal opinion:*

if this is really last beta blocker I wouldn't go for a new round of rework and 
full validation. This patch touches already more than 50 parameters and 
requires backward compatibility. Every change of the framework requires full 
validation and discovers new edge cases as those parameters touch all over the 
code.

*My suggestion:* 

Follow the suggestion for new parameters creation. Implement the suggested 
refactoring in the next major version. 

 


was (Author: e.dimitrova):
Thanks everyone for making a review/ providing a valuable input/advice.

{quote}

Has this been considered?

{quote} 

No, it wasn't considered. I did the renaming as per  {color:#0052cc}+the agreed 
plan+{color} .

For the rest of the audience, I reached out [~maedhroz] in Slack to understand 
better what is the suggestion. 

The proposed idea is to group parameters in the yaml the way it already happens 
with the encryption options.

*Example:*

Moving in the yaml from:
{code:java}
     cached_rows_warn_threshold: 1000
     cached_rows_fail_threshold: 16000
{code}
{{to:}}
{code:java}
replica_filtering_protection:
     - cached_rows_warn_threshold: 1000
     - cached_rows_fail_threshold: 16000
{code}
*My personal opinion:*

if this is really last beta blocker I wouldn't go for a new round of rework and 
full validation. This patch touches already more than 50 parameters and 
requires backward compatibility. Every change of the framework requires full 
validation and discovers new edge cases as those parameters touch all over the 
code.

*My suggestion:* 

Follow the suggestion for new parameters creation. Implement the suggested 
refactoring in the next major version. 

 

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for either 
> their old or new definition e.g. {{KiB/s}}, or we could support them and 
> simply log the value in bytes/s.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 7/2/20, 10:42 PM:
---

Thanks everyone for making a review/ providing a valuable input/advice.

{quote}

Has this been considered?

{quote} 

No, it wasn't considered. I did the renaming as per  {color:#0052cc}+the agreed 
plan+{color} .

For the rest of the audience, I reached out [~maedhroz] in Slack to understand 
better what is the suggestion. 

The proposed idea is to group parameters in the yaml the way it already happens 
with the encryption options.

*Example:*

Moving in the yaml from:
{code:java}
     cached_rows_warn_threshold: 1000
     cached_rows_fail_threshold: 16000
{code}
{{to:}}
{code:java}
replica_filtering_protection:
     - cached_rows_warn_threshold: 1000
     - cached_rows_fail_threshold: 16000
{code}
*My personal opinion:*

if this is really last beta blocker I wouldn't go for a new round of rework and 
full validation. This patch touches already more than 50 parameters and 
requires backward compatibility. Every change of the framework requires full 
validation and discovers new edge cases as those parameters touch all over the 
code.

*My suggestion:* 

Follow the suggestion for new parameters creation. Implement the suggested 
refactoring in the next major version. 

 


was (Author: e.dimitrova):
Thanks everyone for making a review/ providing a valuable input/advice.

?? Has this been considered? ??

No, it wasn't considered. I did the renaming as per  {color:#0052cc}+the agreed 
plan+{color} .

For the rest of the audience, I reached out [~maedhroz] in Slack to understand 
better what is the suggestion. 

The proposed idea is to group parameters in the yaml the way it already happens 
with the encryption options.

*Example:*

Moving in the yaml from:
{code:java}
     cached_rows_warn_threshold: 1000
     cached_rows_fail_threshold: 16000
{code}
{{to:}}
{code:java}
replica_filtering_protection:
     - cached_rows_warn_threshold: 1000
     - cached_rows_fail_threshold: 16000
{code}
*My personal opinion:*

if this is really last beta blocker I wouldn't go for a new round of rework and 
full validation. This patch touches already more than 50 parameters and 
requires backward compatibility. Every change of the framework requires full 
validation and discovers new edge cases as those parameters touch all over the 
code.

*My suggestion:* 

Follow the suggestion for new parameters creation. Implement the suggested 
refactoring in the next major version. 

 

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for either 
> their old or new definition e.g. {{KiB/s}}, or we could support them and 
> simply log the value in bytes/s.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 7/2/20, 10:39 PM:
---

Thanks everyone for making a review/ providing a valuable input/advice.

?? Has this been considered? ??

No, it wasn't considered. I did the renaming as per  {color:#0052cc}+the agreed 
plan+{color} .

For the rest of the audience, I reached out [~maedhroz] in Slack to understand 
better what is the suggestion. 

The proposed idea is to group parameters in the yaml the way it already happens 
with the encryption options.

*Example:*

Moving in the yaml from:
{code:java}
     cached_rows_warn_threshold: 1000
     cached_rows_fail_threshold: 16000
{code}
{{to:}}
{code:java}
replica_filtering_protection:
     - cached_rows_warn_threshold: 1000
     - cached_rows_fail_threshold: 16000
{code}
*My personal opinion:*

if this is really last beta blocker I wouldn't go for a new round of rework and 
full validation. This patch touches already more than 50 parameters and 
requires backward compatibility. Every change of the framework requires full 
validation and discovers new edge cases as those parameters touch all over the 
code.

*My suggestion:* 

Follow the suggestion for new parameters creation. Implement the suggested 
refactoring in the next major version. 

 


was (Author: e.dimitrova):
Thanks everyone for making a review/ providing a valuable input/advice.

?? Has this been considered? ??

No, it wasn't considered. I did the renaming as per  {color:#0052cc}+the agreed 
plan+{color} .

For the rest of the audience, I reached out [~maedhroz] in Slack to understand 
better what is the suggestion. 

The proposed idea is to group parameters in the yaml the way it already happens 
with the encryption options.

*Example:*

Moving in the yaml from:

 
{code:java}
     cached_rows_warn_threshold: 1000
     cached_rows_fail_threshold: 16000
{code}
{{}}

{{to:}}

{{}}
{code:java}
replica_filtering_protection:
     - cached_rows_warn_threshold: 1000
     - cached_rows_fail_threshold: 16000
{code}
{{}}

*My personal opinion:* 

if this is really last beta blocker I wouldn't go for a new round of rework and 
full validation. This patch touches already more than 50 parameters and 
requires backward compatibility. Every change of the framework requires full 
validation and discovers new edge cases as those parameters touch all over the 
code.

*My suggestion:* 

Follow the suggestion for new parameters creation. Implement the suggested 
refactoring in the next major version. 

 

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for either 
> their old or new definition e.g. {{KiB/s}}, or we could support them and 
> simply log the value in bytes/s.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

2020-07-02 Thread Benjamin Lerer (Jira)



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

Benjamin Lerer edited comment on CASSANDRA-15234 at 7/2/20, 12:01 PM:
--

Some comments on the current patch:

* I would prefer to avoid reading twice the configuration file if possible. It 
should be possible to replace {{YamlConfigurationLoader.readStorageConfig}} and 
{{isConfigFileValid}} by some checks in {{getProperty}} or by using the 
specific converters. As a side note: {{isConfigFileValid}} checks twice for the 
same condition on each of the {{if}} conditions.
* The patch can be simplified by making {{Converter}} an {{enum}}. It will 
allow to use the enum value directly into the {{Replaces}} annotation. Doing so 
will remove the need to use reflection to instantiate the conveters and the use 
of a cache to avoid multiple instantiation.
* The change in {{ConfigurationException}} are from some experimentations and 
should be removed.
* I would as discussed previously defer the date of removal and remove 
{{scheduledRemoveBy}} from the {{Replaces}} annotation.
* It would be nice to have more javadoc on the new code.


was (Author: blerer):
Some high leve comments:

* I would prefer to avoid reading twice the configuration file if possible. It 
should be possible to replace {{YamlConfigurationLoader.readStorageConfig}} and 
{{isConfigFileValid}} by some checks in {{getProperty}} or by using the 
specific converters. As a side note: {{isConfigFileValid}} checks twice for the 
same condition on each of the {{if}} conditions.
* The patch can be simplified by making {{Converter}} an {{enum}}. It will 
allow to use the enum value directly into the {{Replaces}} annotation. Doing so 
will remove the need to use reflection to instantiate the conveters and the use 
of a cache to avoid multiple instantiation.
* The change in {{ConfigurationException}} are from some experimentations and 
should be removed.
* I would as discussed previously defer the date of removal and remove 
{{scheduledRemoveBy}} from the {{Replaces}} annotation.
* It would be nice to have more javadoc on the new code.

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for either 
> their old or new definition e.g. {{KiB/s}}, or we could support them and 
> simply log the value in bytes/s.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

2020-06-30 Thread David Capwell (Jira)



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

David Capwell edited comment on CASSANDRA-15234 at 6/30/20, 5:33 PM:
-

Given the framework provided by this patch, the following wouldn't be hard to 
support (all, not just 1 or 2)

1) no warning or plan to remove
2) warning that it will be removed some day
3) warning on specific version which will remove

So, we could do the following

{code}
// provide a warning that this will not longer be supported after 5.0
@Replaces(oldName = "native_transport_idle_timeout_in_ms", scheduledRemoveBy = 
"5.0")
public volatile Duration native_transport_idle_timeout = new Duration("0ms");

// provide a warning that the property is deprecated and will be removed one day
@Replaces(oldName = "native_transport_idle_timeout_in_ms", deprecated = true)
public volatile Duration native_transport_idle_timeout = new Duration("0ms");

// no warning, both properties are fully supported
@Replaces(oldName = "native_transport_idle_timeout_in_ms")
public volatile Duration native_transport_idle_timeout = new Duration("0ms");
{code}

Given the framework makes it trivial to support old names, having no properties 
marked for removal of 5.0 works for me. If we really want to migrate usage to a 
new name, then mark it to be removed one day, and stuff which is personal 
preference (such as enable at the start or end of the name) can have no 
warning; does this make sense?


was (Author: dcapwell):
Given the framework provided by this patch, the following wouldn't be hard to 
support (all, not just 1 or 2)

1) no warning or plan to remove
2) warning that it will be removed some day
3) warning on specific version which will remove

So, we could do the following

{code}
// provide a warning that this will not longer be supported after 5.0
@Replaces(oldName = "native_transport_idle_timeout_in_ms", converter = 
Converter.MillisDurationConverter.class, scheduledRemoveBy = "5.0")
public volatile Duration native_transport_idle_timeout = new Duration("0ms");

// provide a warning that the property is deprecated and will be removed one day
@Replaces(oldName = "native_transport_idle_timeout_in_ms", converter = 
Converter.MillisDurationConverter.class, deprecated = true)
public volatile Duration native_transport_idle_timeout = new Duration("0ms");

// no warning, both properties are fully supported
@Replaces(oldName = "native_transport_idle_timeout_in_ms", converter = 
Converter.MillisDurationConverter.class)
public volatile Duration native_transport_idle_timeout = new Duration("0ms");
{code}

Given the framework makes it trivial to support old names, having no properties 
marked for removal of 5.0 works for me. If we really want to migrate usage to a 
new name, then mark it to be removed one day, and stuff which is personal 
preference (such as enable at the start or end of the name) can have no 
warning; does this make sense?

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for either 
> their old or new definition e.g. {{KiB/s}}, or we could support them and 
> simply log the value in bytes/s.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

2020-06-28 Thread Michael Semb Wever (Jira)



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

Michael Semb Wever edited comment on CASSANDRA-15234 at 6/28/20, 6:33 PM:
--

I've added some (very minor) comments on the 
[commit|https://github.com/ekaterinadimitrova2/cassandra/commit/f7ed1e00db5cc5810779a3d71dc065c750ba8e6b].
 

Higher level comments (while testing)…
 - during startup warnings about legacy yaml names are logged multiple times…
 - {{"it is scheduled to be removed by 5.0"}} would be more precise as {{"the 
old name is scheduled to be removed by 5.0"}} (as opposed to the setting+ value 
being removed),
 - if I define setting  to a blank value, I get a error message like: 
{{"Invalid yaml. Those properties [max_hint_window] are not valid"}}.  This 
falsely tells me thtat the setting name is wrong, rather than the value. 
(Invalid non-blank values provide useful error messages.)
 - integer overflow could have a better error message, currently 
{{"NumberFormatException: For input string: "9223372036854775808""}}
 - the under/over flow protection between units is nice. 
{{Duration.toMilliseconds()}}  apidoc also describe the overflow to  MAX_VALUE. 
(same goes for similar default-unit methods in BitsRate and DataStorage)
 - awesome that you can use {{µs}} :-)


was (Author: michaelsembwever):
I've added some (very minor) comments on the 
[commit|https://github.com/ekaterinadimitrova2/cassandra/commit/f7ed1e00db5cc5810779a3d71dc065c750ba8e6b].
 

Higher level comments (while testing)…
 - during startup warnings about legacy yaml names are logged multiple times…
 - {{"it is scheduled to be removed by 5.0"}} would be more precise as "the old 
name is scheduled to be removed by 5.0" (as opposed to the setting+ value being 
removed),
 - if I define setting  to a blank value, I get a error message like: 
{{"Invalid yaml. Those properties [max_hint_window] are not valid"}}.  This 
falsely tells me thtat the setting name is wrong, rather than the value. 
(Invalid non-blank values provide useful error messages.)
 - integer overflow could have a better error message, currently 
{{"NumberFormatException: For input string: "9223372036854775808""}}
 - the under/over flow protection between units is nice. 
{{Duration.toMilliseconds()}}  apidoc also describe the overflow to  MAX_VALUE. 
(same goes for similar default-unit methods in BitsRate and DataStorage)
 - awesome that you can use {{µs}} :-)

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for either 
> their old or new definition e.g. {{KiB/s}}, or we could support them and 
> simply log the value in bytes/s.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

2020-06-28 Thread Michael Semb Wever (Jira)



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

Michael Semb Wever edited comment on CASSANDRA-15234 at 6/28/20, 6:32 PM:
--

I've added some (very minor) comments on the 
[commit|https://github.com/ekaterinadimitrova2/cassandra/commit/f7ed1e00db5cc5810779a3d71dc065c750ba8e6b].
 

Higher level comments (while testing)…
 - during startup warnings about legacy yaml names are logged multiple times…
 - {{"it is scheduled to be removed by 5.0"}} would be more precise as "the old 
name is scheduled to be removed by 5.0" (as opposed to the setting+ value being 
removed),
 - if I define setting  to a blank value, I get a error message like: 
{{"Invalid yaml. Those properties [max_hint_window] are not valid"}}.  This 
falsely tells me thtat the setting name is wrong, rather than the value. 
(Invalid non-blank values provide useful error messages.)
 - integer overflow could have a better error message, currently 
{{"NumberFormatException: For input string: "9223372036854775808""}}
 - the under/over flow protection between units is nice. 
{{Duration.toMilliseconds()}}  apidoc also describe the overflow to  MAX_VALUE. 
(same goes for similar default-unit methods in BitsRate and DataStorage)
 - awesome that you can use {{µs}} :-)


was (Author: michaelsembwever):
I've added some (very minor) comments on the 
[commit|https://github.com/ekaterinadimitrova2/cassandra/commit/f7ed1e00db5cc5810779a3d71dc065c750ba8e6b].
 

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for either 
> their old or new definition e.g. {{KiB/s}}, or we could support them and 
> simply log the value in bytes/s.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

2020-06-28 Thread Michael Semb Wever (Jira)



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

Michael Semb Wever edited comment on CASSANDRA-15234 at 6/28/20, 4:35 PM:
--

I've added some (very minor) comments on the 
[commit|https://github.com/ekaterinadimitrova2/cassandra/commit/f7ed1e00db5cc5810779a3d71dc065c750ba8e6b].
 


was (Author: michaelsembwever):
I've added some (very minor) comments on the 
[commit|]https://github.com/ekaterinadimitrova2/cassandra/commit/f7ed1e00db5cc5810779a3d71dc065c750ba8e6b.
 

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for either 
> their old or new definition e.g. {{KiB/s}}, or we could support them and 
> simply log the value in bytes/s.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

2020-06-25 Thread Ekaterina Dimitrova (Jira)



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 6/25/20, 7:29 AM:
---

This patch implements the functionality which gives the end users the 
opportunity to attach units suffixes to DataStorage, Duration, BitRates 
parameters. New custom types for the three group of parameters were added.

It renames certain parameters with main goal - standardization. 

Backward compatibility implemented on parameter level utilizing annotations.

[Branch 
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-new]

This patch requires custom [ [DTests 
|https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-new]]
 which run successfully with the following patch of [CCM 
|https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234-new]

(The failed test in circle are failing because the CCM patch didn't apply due 
to config issue. Also, one exclusion of warning about using the old parameters 
names should be added. Upgrade tests still running)

DTests - requirements.txt should be updated back to the original one before 
commit!

[ [JAVA8 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/257/workflows/98c356fb-b16a-4508-bda8-ff877569b0f5]]
 [ [JAVA11 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/257/workflows/d49295a8-d8f5-4836-a18a-df25ff955219]]

*TO DO:* IN-JVM tests are not using snakeyaml so I have to update them to use 
its converter in order for the tests to work with this patch. This is feasible 
solution aligned with Alex Petrov and [~dcapwell].

I will provide the additional patch/commit until the end of the week but didn't 
want to delay the review of the main patch further.

*WARNING:* Before commit return to the default requirements.txt file

*Order of commits:* 1) [ [CASSANDRA branch 
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-new]] 2) 
[ [CCM branch 
|https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234-new]] 3) [ 
[DTests branch 
|https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-new]]


was (Author: e.dimitrova):
This patch implements the functionality which gives the end users the 
opportunity to attach units suffixes to DataStorage, Duration, BitRates 
parameters.

It renames certain parameters with main goal - standardization. 

Backward compatibility implemented on parameter level utilizing annotations.

[Branch 
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-new]

This patch requires custom [ [DTests 
|https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-new]]
 which run successfully with the following patch of [CCM 
|https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234-new]

(The failed test in circle are failing because the CCM patch didn't apply due 
to config issue. Also, one exclusion of warning about using the old parameters 
names should be added. Upgrade tests still running)

DTests - requirements.txt should be updated back to the original one before 
commit!

[ [JAVA8 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/257/workflows/98c356fb-b16a-4508-bda8-ff877569b0f5]]
 [ [JAVA11 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/257/workflows/d49295a8-d8f5-4836-a18a-df25ff955219]]

*TO DO:* IN-JVM tests are not using snakeyaml so I have to update them to use 
its converter in order for the tests to work with this patch. This is feasible 
solution aligned with Alex Petrov and [~dcapwell].

I will provide the additional patch/commit until the end of the week but didn't 
want to delay the review of the main patch further.

*WARNING:* Before commit return to the default requirements.txt file

*Order of commits:* 1) [ [CASSANDRA branch 
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-new]] 2) 
[ [CCM branch 
|https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234-new]] 3) [ 
[DTests branch 
|https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-new]]

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ v

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

2020-06-25 Thread Ekaterina Dimitrova (Jira)



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 6/25/20, 7:27 AM:
---

This patch implements the functionality which gives the end users the 
opportunity to attach units suffixes to DataStorage, Duration, BitRates 
parameters.

It renames certain parameters with main goal - standardization. 

Backward compatibility implemented on parameter level utilizing annotations.

[Branch 
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-new]

This patch requires custom [ [DTests 
|https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-new]]
 which run successfully with the following patch of [CCM 
|https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234-new]

(The failed test in circle are failing because the CCM patch didn't apply due 
to config issue. Also, one exclusion of warning about using the old parameters 
names should be added. Upgrade tests still running)

DTests - requirements.txt should be updated back to the original one before 
commit!

[ [JAVA8 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/257/workflows/98c356fb-b16a-4508-bda8-ff877569b0f5]]
 [ [JAVA11 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/257/workflows/d49295a8-d8f5-4836-a18a-df25ff955219]]

*TO DO:* IN-JVM tests are not using snakeyaml so I have to update them to use 
its converter in order for the tests to work with this patch. This is feasible 
solution aligned with Alex Petrov and [~dcapwell].

I will provide the additional patch/commit until the end of the week but didn't 
want to delay the review of the main patch further.

*WARNING:* Before commit return to the default requirements.txt file

*Order of commits:* 1) [ [CASSANDRA branch 
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-new]] 2) 
[ [CCM branch 
|https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234-new]] 3) [ 
[DTests branch 
|https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-new]]


was (Author: e.dimitrova):
This patch implements the functionality which gives the end users the 
opportunity to attach units suffixes to DataStorage, Duration, BitRates 
parameters.

It renames certain parameters with main goal - standardization. 

Backward compatibility implemented on parameter level utilizing annotations.

[Branch 
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-new]

This patch requires custom [ [DTests 
|https://github.com/ekaterinadimitrova2/cassandra-dtest]] which run 
successfully with the following patch of [CCM 
|https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234-new]

(The failed test in circle are failing because the CCM patch didn't apply due 
to config issue. Also, one exclusion of warning about using the old parameters 
names should be added. Upgrade tests still running)

DTests - requirements.txt should be updated back to the original one before 
commit!

[ [JAVA8 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/257/workflows/98c356fb-b16a-4508-bda8-ff877569b0f5]]
 [ [JAVA11 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/257/workflows/d49295a8-d8f5-4836-a18a-df25ff955219]]

*TO DO:* IN-JVM tests are not using snakeyaml so I have to update them to use 
its converter in order for the tests to work with this patch. This is feasible 
solution aligned with Alex Petrov and [~dcapwell].

I will provide the additional patch/commit until the end of the week but didn't 
want to delay the review of the main patch further.

*WARNING:* Before commit return to the default requirements.txt file

*Order of commits:* 1) [ [CASSANDRA branch 
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-new]] 2) 
[ [CCM branch 
|https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234-new]] 3) [ 
[DTests branch |https://github.com/ekaterinadimitrova2/cassandra-dtest]]

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibili

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

2020-06-18 Thread Ekaterina Dimitrova (Jira)



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 6/18/20, 4:55 PM:
---

[~dcapwell], I am returning this to "in progress" as things have changed and to 
prevent people from confusion. Your concerns are valid and addressed. Change 
has happened because of some misunderstanding on my end but it was corrected 
already. New submission to follow soon:
 * custom types (as per the initial agreement)
 * annotations as suggested by you for easier maintenance
 * backward compatibility will be on property level instead of yaml file level

New branch will be shared soon. Thank you!


was (Author: e.dimitrova):
[~dcapwell], I am returning this to "in progress" as things have changed and to 
prevent people from confusion. Your concerns are valid and addressed. Change 
has happened because of some misunderstanding on my end but it was corrected. 
New submission to follow soon:
 * custom types (as per the initial agreement)
 * annotations as suggested by you for easier maintenance
 * backward compatibility will be on property level instead of yaml file level

New branch will be shared soon. Thank you!

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for either 
> their old or new definition e.g. {{KiB/s}}, or we could support them and 
> simply log the value in bytes/s.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

2020-06-18 Thread Ekaterina Dimitrova (Jira)



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 6/18/20, 4:54 PM:
---

[~dcapwell], I am returning this to "in progress" as things have changed and to 
prevent people from confusion. Your concerns are valid and addressed. Change 
has happened because of some misunderstanding on my end but it was corrected. 
New submission to follow soon:
 * custom types (as per the initial agreement)
 * annotations as suggested by you for easier maintenance
 * backward compatibility will be on property level instead of yaml file level

New branch will be shared soon. Thank you!


was (Author: e.dimitrova):
[~dcapwell], I am returning this to "in progress" as things have changed. Your 
concerns are valid and addressed. Change has happened because of some 
misunderstanding on my end but it was corrected. New submission to follow soon:
 * custom types (as per the initial agreement)
 * annotations as suggested by you for easier maintenance
 * backward compatibility will be on property level instead of yaml file level

New branch will be shared soon. Thank you!

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for either 
> their old or new definition e.g. {{KiB/s}}, or we could support them and 
> simply log the value in bytes/s.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

2020-06-18 Thread Ekaterina Dimitrova (Jira)



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 6/18/20, 4:53 PM:
---

[~dcapwell], I am returning this to "in progress" as things have changed. Your 
concerns are valid and addressed. Change has happened because of some 
misunderstanding on my end but it was corrected. New submission to follow soon:
 * custom types (as per the initial agreement)
 * annotations as suggested by you for easier maintenance
 * backward compatibility will be on property level instead of yaml file level

New branch will be shared soon. Thank you!


was (Author: e.dimitrova):
Still working on a couple of changes after review and discussions happened

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for either 
> their old or new definition e.g. {{KiB/s}}, or we could support them and 
> simply log the value in bytes/s.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 6/15/20, 10:03 PM:


[ [trunk 
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-3-rebase]
 ] [ [DTests 
|https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-3] 
] [ [CCM |https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234-3] ] 
[ [JAVA8 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/193/workflows/718c8a04-385b-4ddc-ac2e-9291c37b1f1e]
 ] [ [JAVA11 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/193/workflows/6cd6048d-5daf-4490-a5d3-b5c3178a0757]
 ]

Attached to the ticket is the log of the successful runs of the few failing 
JAVA8 DTests in CircleCI. I ran them locally after fixing lost line of code as 
it didn't make sense to me to rerun the whole suite of tests.

*Last update:* after rebase and a few nits on my end, we have only 1 DTest and 
1 Unit test failing in JAVA11. Unrelated known failures.
 - added additional note on the possible units to be used as suffixes in both 
NEWS.txt and cassandra.yaml

CQLSH JAVA11 tests are not currently available in CircleCI.

*EDIT:* This work has been moved to a separate ticket - CASSANDRA-15876.

-The last part is all green after rebase and CI run.-
 - -"line.separator" getter added-
 -[ [trunk 
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-5] ] [ 
[JAVA8 CI 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/195/workflows/ebd771ac-d71c-49ea-872b-00b534d9d5c6]
 ] [ [JAVA11 CI 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/195/workflows/19a3254b-cd7a-4e4f-856f-f314546ff9d7]
 ]-

-There are 1 DTest and 1 Unit unrelated failing tests in JAVA11. Should check 
for tickets logged.-

*NOTE:* Before commit return to the default config.yml and requirements.txt 
files


was (Author: e.dimitrova):
[ [trunk 
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-3-rebase 
] ] [ [DTests | 
https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-3] 
] [ [CCM |https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234-3] ] 
[ [JAVA8 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/193/workflows/718c8a04-385b-4ddc-ac2e-9291c37b1f1e]
 ] [ [JAVA11 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/193/workflows/6cd6048d-5daf-4490-a5d3-b5c3178a0757
 ] ] 

Attached to the ticket is the log of the successful runs of the few failing 
JAVA8 DTests in CircleCI. I ran them locally after fixing lost line of code as 
it didn't make sense to me to rerun the whole suite of tests. 

*Last update:* after rebase and a few nits on my end, we have only 1 DTest and 
1 Unit test failing in JAVA11. Unrelated known failures.

- added additional note on the possible units to be used as suffixes in both 
NEWS.txt and cassandra.yaml

CQLSH JAVA11 tests are not currently available in CircleCI.


The last part is all green after rebase and CI run. 
- "line.separator" getter added
[ [trunk 
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-5] ] [ 
[JAVA8 CI 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/195/workflows/ebd771ac-d71c-49ea-872b-00b534d9d5c6]
 ] [ [JAVA11 CI 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/195/workflows/19a3254b-cd7a-4e4f-856f-f314546ff9d7]
 ] 

There are 1 DTest and 1 Unit unrelated failing tests in JAVA11. Should check 
for tickets logged. 

*NOTE:* Before commit return to the default config.yml and requirements.txt 
files

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 6/15/20, 10:02 PM:


[ [Part 2 
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-3] ] [ 
[DTests 
|https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-3] 
] [ [CCM |https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234-3] ] 
[ [CI run 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/187/workflows/615cdebf-1d49-47ab-93a4-efad25a247b1]
 ]

 - Unit tests updated

- Getters and Setters names in the DatabaseDescriptor were updated to follow 
the new names of the parameters updated
 - The conversion of some of the parameters values which is happening in their 
getters is kept as it is needed in runtime. Some parameters are used with 
different units in the different areas of the codebase. So I left this part 
untouched.

 - New class created, ParseAndConvertUnits - it pulls all the functionality 
needed to cover the addition of units suffixes to the Memory, Duration, and 
Rate parameters in the cassandra.yaml

- the cassandra.yaml file in this branch contains currently the new parameters 
with new names and unit suffixes but the arrangement of the sections is the old 
one as this was causing me issues every time I rebase/commit. If we confirm the 
format, this will be the last step to switch to the new format

- Added some additional parsing and supporting conversion functions for the 
double duration parameters.

- The 2 failing cqlsh tests were fixed locally and tested. It was formatting 
issue. 

-1 unit test failed - it doesn't look a related issue but will check the config 
loaded to ensure that tomorrow

- 8 failing dtest, it doesn't look related but I am gonna compare tomorrow 
morning

 - Current version of the code needs a final rebase/merge of the last 6 commits 
on trunk.  Will do tomorrow after I recheck the CI and current version

- Have to return the default requirements.txt and config.yml files. The current 
versions were required only for testing purposes with CircleCI

*WARNING:* we should be careful with the dtests and ccm. One missed check for 
old/new parameter and default value of the respective parameter from Config 
will be loaded. This might not lead to failing test and thus silently cover the 
miss.

*NOTE:* Custom Types, as they were suggested, don't really work with SnakeYAML, 
unfortunately.  SnakeYAML supports nothing more than mapping between the yaml 
and the Config class.
 * _So something like that: Memory max_value = new Memory("5ms") wouldn't work. 
If there is no value in the yaml, the config default  max_value will be parsed 
properly but if there is value assigned to max_value at the yaml, it won't be 
assigned properly in Config. Classes are used for nested parameters. Also, 
currently there won't be a big benefit of the custom types as the different 
parameters validations in the DatabaseDescriptor are taking different 
approaches, there is no general framework/approach per group of parameters 
(Memory, Duration, Rate)._

_-_

_*EDIT:* Part3 has been moved to a separate ticket - CASSANDRA-15876._

-The last part was updated as per the recommendations. CI ran successfully. 
Need to rebase and recheck nothing that might need the attention of this patch 
has changed in the meanwhile. Three weeks passed since I took care of this 
one.- 
 -[ [Part3 
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-5] ] [  
[CI JAVA8 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/146/workflows/fae5da98-acf5-4824-bf61-3ffab3d86cd6]
 ] [ [CI Java11 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/146/workflows/21b088c4-8984-4b20-8302-2ff8adaf55f7]
 ]-


was (Author: e.dimitrova):
[ [Part 2 
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-3] ] [ 
[DTests 
|https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-3] 
] [ [CCM |https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234-3] ] 
[ [CI run 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/187/workflows/615cdebf-1d49-47ab-93a4-efad25a247b1]
 ]

 - Unit tests updated

- Getters and Setters names in the DatabaseDescriptor were updated to follow 
the new names of the parameters updated
 - The conversion of some of the parameters values which is happening in their 
getters is kept as it is needed in runtime. Some parameters are used with 
different units in the different areas of the codebase. So I left this part 
untouched.

 - New class created, ParseAndConvertUnits - it pulls all the functionality 
needed to cover the addition of units suffixes to the Memory, Duration, and 
Rate parameters in the cassand

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 6/15/20, 10:01 PM:


Latest update:
 Part1
 - format issues fixed
 - The isOldYAML logger info changed to warn, and it lists also the old 
properties used
 - The format of yaml props is noun_verb. native_transport props adjusted to 
follow this. Max sent to the back as in native_transport_threads_max.
 - MAP_OLD_TO_NEW_PARAMETERS is not static anymore(so it is freed memory after 
startup)

Part2 - will be completed in the suggested way probably tomorrow (working 
asynchronously)

*EDIT:* Part3 has been moved to a separate ticket - CASSANDRA-15876.

-Part3 - anyone any thoughts whether it should be 1 class or maybe divided into 
3 classes, as suggested by- [~dcapwell]-?-


was (Author: e.dimitrova):
Latest update:
Part1
   - format issues fixed
   - The isOldYAML logger info changed to warn, and it lists also the old 
properties used
   - The format of yaml props is noun_verb. native_transport props adjusted to 
follow this. Max sent to the back as in native_transport_threads_max.
   - MAP_OLD_TO_NEW_PARAMETERS is not static anymore(so it is freed memory 
after startup) 

Part2 - will be completed in the suggested way probably tomorrow (working 
asynchronously)

Part3 - anyone any thoughts whether it should be 1 class or maybe divided into 
3 classes, as suggested by [~dcapwell]?

 

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for either 
> their old or new definition e.g. {{KiB/s}}, or we could support them and 
> simply log the value in bytes/s.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 6/15/20, 10:01 PM:


@David, thanks for the review and the clarifications and Slack constructive 
discussion!

So looks like we have the same vision and I missed one thing. Let me wrap up 
here for the record and [~mck] who is also looking into it.
 Part2 - null is a legit issue and no one of us likes the idea of adding "" in 
the yaml file. Still have to spend time to think about a workaround and that we 
already have it there.

The Memory class is kind of what I meant when I said I have to pull the current 
implementation separately.
 So the suggestion is to pull into three additional classes - Memory, 
Throughput and TimeDuration (or something similar)

The confusion was about a thing I saw and forgot to take care. :\
 There are 11 getters in the DatabaseDescriptor. 
 They need to be changed to only getters without doing one more layer of 
conversion to bytes. Example:
 getMaxValueSizeInBytes()

{ return maxValue.toBytes(); }

-> Memory getMaxValueSize()

{ return maxValue}

This will clean the code and make it easy for maintenance.

*EDIT:* Part3 has been moved to a separate ticket - CASSANDRA-15876.

-Part 3 - code-wise not related to Part1 and 2, just additional small task 
which was requested in the previous comments, considering we are trying to do 
standardization as part of this ticket.- 
 -Whether we keep all of them in one class or we split is a matter of agreement 
I think. As soon as we get it, I will correct it. This is real quick.-


was (Author: e.dimitrova):
@David, thanks for the review and the clarifications and Slack constructive 
discussion!

So looks like we have the same vision and I missed one thing. Let me wrap up 
here for the record and [~mck] who is also looking into it.
Part2 - null is a legit issue and no one of us likes the idea of adding "" in 
the yaml file.  Still have to spend time to think about a workaround and that 
we already have it there. 

The Memory class is kind of what I meant when I said I have to pull the current 
implementation separately.
So the suggestion is to pull into three additional classes - Memory, Throughput 
and TimeDuration (or something similar)

The confusion was about a thing I saw and forgot to take care. :\
There are 11 getters in the DatabaseDescriptor. 
They need to be changed to only getters without doing one more layer of 
conversion to bytes. Example:
getMaxValueSizeInBytes() { return maxValue.toBytes(); }  -> Memory 
getMaxValueSize() { return maxValue}

This will clean the code and make it easy for maintenance.

Part 3 - code-wise not related to Part1 and 2, just additional small task which 
was requested in the previous comments, considering we are trying to do 
standardization as part of this ticket.  
Whether we keep all of them in one class or we split is a matter of agreement I 
think. As soon as we get it, I will correct it. This is real quick.

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for either 
> their old or new definition e.g. {{KiB/s}}, or we could support them and 
> simply log the value in bytes/s.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 6/15/20, 10:00 PM:

Done but with one caveat which was caught thankfully with the DTests. Unit
tests were even on 100% green at some runs. (And my unit test was not covering
the problem conversion explained below, I should add it!)
I am new to snakeyaml so I might be wrong, I would appreciate if someone who
has the experience proves me wrong.
From the DTest failures I realized that turning into Strings the values from
the YAML we hit one issue. To me it looks like we already have it actually with
Integer and String parameters, just they are not many so it didn't bite us up
to now. Not sure whether this was considered when the Config class was built or
not.

So the issue with int parameters in Config in my solution is:
Currently in trunk, when we parse to int variable, If a parameter is commented
in the cassandra.yaml, this is observed as null and it will raise an exception
in some cases. (i.e. commitlog_sync_period_in_ms) But if it is not commented,
just not assigned a value, then this is considered as 0 (as we parse to int).
The situation is different with String, Integer. They will be in both cases
null. No differentiator. But currently we don't have many parameters being
Integer and String and this wasn't a problem.
Now with the units attached to the parameters' values in the cassandra.yaml
file, we need to parse strings with snakeyaml and then convert to the proper
int values in Config.

A way to cope with this issue is to make the users use "". In this way, if we
have a parameter not commented, but not also having an assigned value in
cassandra.yaml, we can identify it by checking a string for being empty. If the
parameter is commented or not presented, it will be null. But this would be one
more new thing for the users to consider. That's why I came back to snakeyaml
again and tried to think of a different way utilizing it. Unfortunately, up to
now I didn't find any different solution. Also, the links to the examples in
the official snakeyaml documentation are broken. Not sure whether there they
had some interesting stuff. Maybe something with customized constructor but
also, I try to make as less as possible disruptive changes in the codebase in
order not to mess up something with the Config which might be extremely
unpleasant.

I will be happy to hear an experienced opinion here. Does anyone know a better
solution? Or are we ok to introduce "" in the yaml for empty parameters/Strings
recognition?

[Part1|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-2]
(This part was already revised by [~dcapwell] but I paste the explanation again
here for completeness).
- New cassandra.yaml ---> currently cassandra-new.yaml in the branch as I
wanted to test the backward compatibility on the old version (will have to
rename properly also these yaml files with version probably)
reorganization of the file renames to make the names more consistent
- Backward compatibility with the old names - my approach is:
Cassandra comes with the new version of the yaml to ensure any new builds will
be using it
During load of the yaml file I check whether old names are identified(means
someone upgraded to 4 and wants to still use the old yaml). If this is the
case, we load the values from the old yaml to the new variables (the already
renamed parameters). Also, there is a warning to the user that there is new
cassandra.yaml version and he/she can consider an update.

[Part2|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-3]
- units added to the values in the cassandra.yaml file. Parsing and unit
conversion in place. One unit test added, should be further developed.

[DTests|https://github.com/ekaterinadimitrova2/cassandra-dtest] updated
accordingly for v.4

*EDIT:* Part3 has been moved to a separate ticket - CASSANDRA-15876.

-[Part3|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-5]
- SysProperties class, accessors, hope I didn't miss anything... most of them
are actually just using System.getProperty method.-
TO DO: Extract the parser/converter in a separate class from Config

[~mck]? [~dcapwell]? [~benedict]? Anyone else any thoughts here?

NOTE: The branches are not fully cleaned, this is still work in progress but we
need to take a decision on the String issue first, I think.

was (Author: e.dimitrova):
Done but with one caveat which was caught thankfully with the DTests. Unit
tests were even on 100% green at some runs. (And my unit test was not covering
the problem conversion explained below, I should add it!)
I am new to snakeyaml so I might be wrong, I would appreciate if someone who
has the

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 6/15/20, 9:59 PM:
---

*Summary:*
 This branch contains:
 - [first commit 
|https://github.com/ekaterinadimitrova2/cassandra/commit/a8a9145a032a9f2d9b74369f2e4474a210aa5b99]
 which contains parameters name changes as requested; backward compatibility 
with the old names; Proposed new structure into sections for cassandra.yaml.
 - the [second commit 
|https://github.com/ekaterinadimitrova2/cassandra/commit/032fbd8cca1d7b5b96738bd96d9672864426d718]
 implements the functionality which gives the end users the opportunity to 
attach units suffixes to Memory, Duration, Rates parameters.
 - [third commit 
|https://github.com/ekaterinadimitrova2/cassandra/commit/68f89503e6e6f30e8f6df1374cb553f243f0068e]
 is a ninja fix of one line which was changed in a wrong way during the latest 
rebase.
 - [fourth commit 
|https://github.com/ekaterinadimitrova2/cassandra/commit/8389010d704a9524a1c36d96f9e4d8179a8e2044]
 is to return the default config.yml

This patch requires custom [ [DTests 
|https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-3] 
] which run successfully with the following patch of [CCM 
|https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234-3]
 DTests - requirements.txt should be updated back to the original one before 
commit!

The DTests are not backward compatible with the yaml file without units 
suffixes.
 This part is covered by a unit test which tests the successful load of the 
values of the parameters without units as per the old format.

[ [trunk 
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-3-rebase]
 ] [ [DTests 
|https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-3] 
] [ [CCM |https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234-3] ] 
[ [JAVA8 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/193/workflows/718c8a04-385b-4ddc-ac2e-9291c37b1f1e]
 ] [ [JAVA11 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/193/workflows/6cd6048d-5daf-4490-a5d3-b5c3178a0757]
 ]

Attached to the ticket is the log of the successful runs of the few failing 
JAVA8 DTests in CircleCI. I ran them locally after fixing lost line of code as 
it didn't make sense to me to rerun the whole suite of tests.

*Last update:* after rebase and a few nits on my end, we have only 1 DTest and 
1 Unit test failing in JAVA11. Unrelated known failures.
 CQLSH JAVA11 tests are not currently available in CircleCI.

*WARNING:* Before commit return to the default requirements.txt file

*Order of commits:* 1) [ [CASSANDRA branch 
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-3-rebase]
 ] 2) [ [CCM branch 
|https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234-3] ] 3) [ 
[DTests branch 
|https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-3] 
]

*EDIT:* This work has been moved to a separate ticket - CASSANDRA-15876.

-This [branch 
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-5] is a 
class of Accessors for System properties. *This patch could be considered 
separate of the previous one, it doesn't matter* *if it is committed* *first or 
second.* It also doesn't require custom DTests or custom CCM.-
 -[ [trunk 
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-5] ] [ 
[JAVA8 CI 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/195/workflows/ebd771ac-d71c-49ea-872b-00b534d9d5c6]
 ] [ [JAVA11 CI 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/195/workflows/19a3254b-cd7a-4e4f-856f-f314546ff9d7]
 ]-

-There are 1 DTest and 1 Unit unrelated failing tests in JAVA11. Should check 
for tickets logged.-


was (Author: e.dimitrova):
*Summary:*
 This branch contains:
 - [first commit 
|https://github.com/ekaterinadimitrova2/cassandra/commit/a8a9145a032a9f2d9b74369f2e4474a210aa5b99]
 which contains parameters name changes as requested; backward compatibility 
with the old names; Proposed new structure into sections for cassandra.yaml.
 - the [second commit 
|https://github.com/ekaterinadimitrova2/cassandra/commit/032fbd8cca1d7b5b96738bd96d9672864426d718]
 implements the functionality which gives the end users the opportunity to 
attach units suffixes to Memory, Duration, Rates parameters.
 - [third commit 
|https://github.com/ekaterinadimitrova2/cassandra/commit/68f89503e6e6f30e8f6df1374cb553f243f0068e]
 is a ninja fix of one line which was changed in a wrong way during the latest 
rebase.
 - [fourth commit 
|https://github.com/ekaterinadimitrova2/cassandra/commit/8389010d704a9524a1c36d96f9e4d8179a8e2044]
 is to return the default config.yml

This pat

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

2020-06-08 Thread Ekaterina Dimitrova (Jira)



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 6/8/20, 3:03 PM:
--

*Summary:*
 This branch contains:
 - [first commit 
|https://github.com/ekaterinadimitrova2/cassandra/commit/a8a9145a032a9f2d9b74369f2e4474a210aa5b99]
 which contains parameters name changes as requested; backward compatibility 
with the old names; Proposed new structure into sections for cassandra.yaml.
 - the [second commit 
|https://github.com/ekaterinadimitrova2/cassandra/commit/032fbd8cca1d7b5b96738bd96d9672864426d718]
 implements the functionality which gives the end users the opportunity to 
attach units suffixes to Memory, Duration, Rates parameters.
 - [third commit 
|https://github.com/ekaterinadimitrova2/cassandra/commit/68f89503e6e6f30e8f6df1374cb553f243f0068e]
 is a ninja fix of one line which was changed in a wrong way during the latest 
rebase.
 - [fourth commit 
|https://github.com/ekaterinadimitrova2/cassandra/commit/8389010d704a9524a1c36d96f9e4d8179a8e2044]
 is to return the default config.yml

This patch requires custom [ [DTests 
|https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-3] 
] which run successfully with the following patch of [CCM 
|https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234-3]
 DTests - requirements.txt should be updated back to the original one before 
commit!

The DTests are not backward compatible with the yaml file without units 
suffixes.
 This part is covered by a unit test which tests the successful load of the 
values of the parameters without units as per the old format.

[ [trunk 
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-3-rebase]
 ] [ [DTests 
|https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-3] 
] [ [CCM |https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234-3] ] 
[ [JAVA8 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/193/workflows/718c8a04-385b-4ddc-ac2e-9291c37b1f1e]
 ] [ [JAVA11 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/193/workflows/6cd6048d-5daf-4490-a5d3-b5c3178a0757]
 ]

Attached to the ticket is the log of the successful runs of the few failing 
JAVA8 DTests in CircleCI. I ran them locally after fixing lost line of code as 
it didn't make sense to me to rerun the whole suite of tests.

*Last update:* after rebase and a few nits on my end, we have only 1 DTest and 
1 Unit test failing in JAVA11. Unrelated known failures.
 CQLSH JAVA11 tests are not currently available in CircleCI.

*WARNING:* Before commit return to the default requirements.txt file

*Order of commits:* 1) [ [CASSANDRA branch 
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-3-rebase]
 ] 2) [ [CCM branch 
|https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234-3] ] 3) [ 
[DTests branch 
|https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-3] 
]

This [branch 
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-5] is a 
class of Accessors for System properties. *This patch could be considered 
separate of the previous one, it doesn't matter* *if it is committed* *first or 
second.* It also doesn't require custom DTests or custom CCM.
 [ [trunk 
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-5] ] [ 
[JAVA8 CI 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/195/workflows/ebd771ac-d71c-49ea-872b-00b534d9d5c6]
 ] [ [JAVA11 CI 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/195/workflows/19a3254b-cd7a-4e4f-856f-f314546ff9d7]
 ]

There are 1 DTest and 1 Unit unrelated failing tests in JAVA11. Should check 
for tickets logged.


was (Author: e.dimitrova):
*Summary:*
 This branch contains:
 - [first commit 
|https://github.com/ekaterinadimitrova2/cassandra/commit/a8a9145a032a9f2d9b74369f2e4474a210aa5b99]
 which contains parameters name changes as requested; backward compatibility 
with the old names; Proposed new structure into sections  for cassandra.yaml.
 - the [second commit 
|https://github.com/ekaterinadimitrova2/cassandra/commit/032fbd8cca1d7b5b96738bd96d9672864426d718]
 implements the functionality which gives the end users the opportunity to 
attach units suffixes to Memory, Duration, Rates parameters.
 - [third commit 
|https://github.com/ekaterinadimitrova2/cassandra/commit/68f89503e6e6f30e8f6df1374cb553f243f0068e]
 is a ninja fix of one line which was changed in a wrong way during the latest 
rebase.
 - [fourth commit 
|https://github.com/ekaterinadimitrova2/cassandra/commit/8389010d704a9524a1c36d96f9e4d8179a8e2044]
 is to return the default config.yml

This patch requires custom [ [DTests 
|https://github.com/ekaterinadimitrova2/cassandra-d

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters

2020-06-05 Thread Michael Semb Wever (Jira)



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

Michael Semb Wever edited comment on CASSANDRA-15234 at 6/5/20, 7:29 PM:
-

Thanks for the summary post [~e.dimitrova].

For the first 
[part|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:CASSANDRA-15234-3-rebase]
 (including the dtest and ccm changes), the ASF CI pipeline results are 
[here|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/144/].
 In addition the ASF CI dtest upgrade test results are 
[here|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-dtest-upgrade/10/].

For the second 
[part|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:CASSANDRA-15234-5]
 the ASF CI results are 
[here|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/145/pipeline].


was (Author: michaelsembwever):
Thanks for the summary post [~e.dimitrova].

For the first 
[part|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:CASSANDRA-15234-3-rebase]
 (including the dtest and ccm changes), the ASF CI pipeline results are 
[here|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/144/].
 In addition the ASF CI dtest upgrade test results are 
[here|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-dtest-upgrade/9/].

For the second 
[part|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:CASSANDRA-15234-5]
 the ASF CI results are 
[here|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/145/pipeline].

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for either 
> their old or new definition e.g. {{KiB/s}}, or we could support them and 
> simply log the value in bytes/s.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 6/5/20, 6:35 PM:
--

*Summary:*
 This branch contains:
 - [first commit 
|https://github.com/ekaterinadimitrova2/cassandra/commit/a8a9145a032a9f2d9b74369f2e4474a210aa5b99]
 which contains parameters name changes as requested; backward compatibility 
with the old names; Proposed new structure into sections  for cassandra.yaml.
 - the [second commit 
|https://github.com/ekaterinadimitrova2/cassandra/commit/032fbd8cca1d7b5b96738bd96d9672864426d718]
 implements the functionality which gives the end users the opportunity to 
attach units suffixes to Memory, Duration, Rates parameters.
 - [third commit 
|https://github.com/ekaterinadimitrova2/cassandra/commit/68f89503e6e6f30e8f6df1374cb553f243f0068e]
 is a ninja fix of one line which was changed in a wrong way during the latest 
rebase.
 - [fourth commit 
|https://github.com/ekaterinadimitrova2/cassandra/commit/8389010d704a9524a1c36d96f9e4d8179a8e2044]
 is to return the default config.yml

This patch requires custom [ [DTests 
|https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-3] 
] which run successfully with the following patch of [CCM 
|https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234-3]
 DTests - requirements.txt should be updated back to the original one before 
commit!

The DTests are not backward compatible with the yaml file without units 
suffixes.
 This part is covered by a unit test which tests the successful load of the 
values of the parameters without units as per the old format.

[ [trunk 
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-3-rebase]
 ] [ [DTests 
|https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-3] 
] [ [CCM |https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234-3] ] 
[ [JAVA8 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/193/workflows/718c8a04-385b-4ddc-ac2e-9291c37b1f1e]
 ] [ [JAVA11 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/193/workflows/6cd6048d-5daf-4490-a5d3-b5c3178a0757]
 ]

Attached to the ticket is the log of the successful runs of the few failing 
JAVA8 DTests in CircleCI. I ran them locally after fixing lost line of code as 
it didn't make sense to me to rerun the whole suite of tests.

*Last update:* after rebase and a few nits on my end, we have only 1 DTest and 
1 Unit test failing in JAVA11. Unrelated known failures.
 CQLSH JAVA11 tests are not currently available in CircleCI.

*WARNING:* Before commit return to the default requirements.txt file

*Order of commits:* 1) [ [CASSANDRA branch 
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-3-rebase]
 ] 2) [ [CCM branch 
|https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234-3] ] 3) [ 
[DTests branch 
|https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-3] 
]

This [branch 
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-5] is a 
class of Accessors for System properties. *This patch could be considered 
separate of the previous one, it doesn't matter first or second.* It also 
doesn't require custom DTests or custom CCM.
 [ [trunk 
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-5] ] [ 
[JAVA8 CI 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/195/workflows/ebd771ac-d71c-49ea-872b-00b534d9d5c6]
 ] [ [JAVA11 CI 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/195/workflows/19a3254b-cd7a-4e4f-856f-f314546ff9d7]
 ]

There are 1 DTest and 1 Unit unrelated failing tests in JAVA11. Should check 
for tickets logged.


was (Author: e.dimitrova):
*Summary:*
This branch contains:
- [first commit | 
https://github.com/ekaterinadimitrova2/cassandra/commit/a8a9145a032a9f2d9b74369f2e4474a210aa5b99]
 which contains parameters name changes as requested; backward compatibility 
with the old names; Proposed new structure into [sections 
|https://issues.apache.org/jira/browse/CASSANDRA-15234?focusedCommentId=17057969&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17057969]
 for cassandra.yaml. 
- the [second commit | 
https://github.com/ekaterinadimitrova2/cassandra/commit/032fbd8cca1d7b5b96738bd96d9672864426d718]
 implements the functionality which gives the end users the opportunity to 
attach units suffixes to Memory, Duration, Rates parameters. 
- [third commit 
|https://github.com/ekaterinadimitrova2/cassandra/commit/68f89503e6e6f30e8f6df1374cb553f243f0068e]
 is a ninja fix of one line which was changed in a wrong way during the latest 
rebase. 
- [fourth commit 
|https://github.com/ekaterinadimitrova2/cassandra/commit/8389010d704a9524a1

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 6/5/20, 6:28 PM:
--

*Summary:*
This branch contains:
- [first commit | 
https://github.com/ekaterinadimitrova2/cassandra/commit/a8a9145a032a9f2d9b74369f2e4474a210aa5b99]
 which contains parameters name changes as requested; backward compatibility 
with the old names; Proposed new structure into [sections 
|https://issues.apache.org/jira/browse/CASSANDRA-15234?focusedCommentId=17057969&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17057969]
 for cassandra.yaml. 
- the [second commit | 
https://github.com/ekaterinadimitrova2/cassandra/commit/032fbd8cca1d7b5b96738bd96d9672864426d718]
 implements the functionality which gives the end users the opportunity to 
attach units suffixes to Memory, Duration, Rates parameters. 
- [third commit 
|https://github.com/ekaterinadimitrova2/cassandra/commit/68f89503e6e6f30e8f6df1374cb553f243f0068e]
 is a ninja fix of one line which was changed in a wrong way during the latest 
rebase. 
- [fourth commit 
|https://github.com/ekaterinadimitrova2/cassandra/commit/8389010d704a9524a1c36d96f9e4d8179a8e2044]
 is to return the default config.yml

This patch requires custom [ [DTests | 
https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-3] 
] which run successfully with the following patch of [CCM 
|https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234-3]
DTests - requirements.txt should be updated back to the original one before 
commit! 

The DTests are not backward compatible with the yaml file without units 
suffixes.
This part is covered by a unit test which tests the successful load of the 
values of the parameters without units as per the old format.

[ [trunk 
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-3-rebase 
] ] [ [DTests | 
https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-3] 
] [ [CCM |https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234-3] ] 
[ [JAVA8 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/193/workflows/718c8a04-385b-4ddc-ac2e-9291c37b1f1e]
 ] [ [JAVA11 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/193/workflows/6cd6048d-5daf-4490-a5d3-b5c3178a0757
 ] ] 

Attached to the ticket is the log of the successful runs of the few failing 
JAVA8 DTests in CircleCI. I ran them locally after fixing lost line of code as 
it didn't make sense to me to rerun the whole suite of tests. 

*Last update:* after rebase and a few nits on my end, we have only 1 DTest and 
1 Unit test failing in JAVA11. Unrelated known failures.
CQLSH JAVA11 tests are not currently available in CircleCI.

*WARNING:* Before commit return to the default requirements.txt file

This [branch | 
https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-5]  is a 
class of Accessors for System properties. *This patch could be considered 
separate of the previous one.* It doesn't require custom DTests or custom CCM.
[ [trunk 
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-5] ] [ 
[JAVA8 CI 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/195/workflows/ebd771ac-d71c-49ea-872b-00b534d9d5c6]
 ] [ [JAVA11 CI 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/195/workflows/19a3254b-cd7a-4e4f-856f-f314546ff9d7]
 ] 

There are 1 DTest and 1 Unit unrelated failing tests in JAVA11. Should check 
for tickets logged. 




was (Author: e.dimitrova):
*Summary:*
This branch contains:
- [first commit | 
https://github.com/ekaterinadimitrova2/cassandra/commit/a8a9145a032a9f2d9b74369f2e4474a210aa5b99]
 which contains parameters name changes as requested; backward compatibility 
with the old names; Proposed new structure into [sections 
|https://issues.apache.org/jira/browse/CASSANDRA-15234?focusedCommentId=17057969&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17057969]
 for cassandra.yaml. 
- the [second commit | 
https://github.com/ekaterinadimitrova2/cassandra/commit/032fbd8cca1d7b5b96738bd96d9672864426d718]
 implements the functionality which gives the end users the opportunity to 
attach units suffixes to Memory, Duration, Rates parameters. 
- [third commit 
|https://github.com/ekaterinadimitrova2/cassandra/commit/68f89503e6e6f30e8f6df1374cb553f243f0068e]
 is a ninja fix of one line which was changed in a wrong way during the latest 
rebase. 
- [fourth commit 
|https://github.com/ekaterinadimitrova2/cassandra/commit/8389010d704a9524a1c36d96f9e4d8179a8e2044]
 is to return the default config.yml

This patch requires custom [ [DTests | 
https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-3]

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 6/5/20, 5:50 PM:
--

*Summary:*
This branch contains:
- [first commit | 
https://github.com/ekaterinadimitrova2/cassandra/commit/a8a9145a032a9f2d9b74369f2e4474a210aa5b99]
 which contains parameters name changes as requested; backward compatibility 
with the old names; Proposed new structure into [sections 
|https://issues.apache.org/jira/browse/CASSANDRA-15234?focusedCommentId=17057969&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17057969]
 for cassandra.yaml. 
- the [second commit | 
https://github.com/ekaterinadimitrova2/cassandra/commit/032fbd8cca1d7b5b96738bd96d9672864426d718]
 implements the functionality which gives the end users the opportunity to 
attach units suffixes to Memory, Duration, Rates parameters. 
- [third commit 
|https://github.com/ekaterinadimitrova2/cassandra/commit/68f89503e6e6f30e8f6df1374cb553f243f0068e]
 is a ninja fix of one line which was changed in a wrong way during the latest 
rebase. 
- [fourth commit 
|https://github.com/ekaterinadimitrova2/cassandra/commit/8389010d704a9524a1c36d96f9e4d8179a8e2044]
 is to return the default config.yml

This patch requires custom [ [DTests | 
https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-3] 
] which run successfully with the following patch of [CCM 
|https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234-3]
DTests - requirements.txt should be updated back to the original one before 
commit! 

The DTests are not backward compatible with the yaml file without units 
suffixes.
This part is covered by a unit test which tests the successful load of the 
values of the parameters without units as per the old format.

[ [trunk 
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-3-rebase 
] ] [ [DTests | 
https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-3] 
] [ [CCM |https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234-3] ] 
[ [JAVA8 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/193/workflows/718c8a04-385b-4ddc-ac2e-9291c37b1f1e]
 ] [ [JAVA11 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/193/workflows/6cd6048d-5daf-4490-a5d3-b5c3178a0757
 ] ] 

Attached to the ticket is the log of the successful runs of the few failing 
JAVA8 DTests in CircleCI. I ran them locally after fixing lost line of code as 
it didn't make sense to me to rerun the whole suite of tests. 

*Last update:* after rebase and a few nits on my end, we have only 1 DTest and 
1 Unit test failing in JAVA11. Unrelated known failures.
CQLSH JAVA11 tests are not currently available in CircleCI.

This branch is a class of Accessors for System properties. *This patch could be 
considered separate of the previous one.* It doesn't require custom DTests or 
custom CCM.
[ [trunk 
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-5] ] [ 
[JAVA8 CI 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/195/workflows/ebd771ac-d71c-49ea-872b-00b534d9d5c6]
 ] [ [JAVA11 CI 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/195/workflows/19a3254b-cd7a-4e4f-856f-f314546ff9d7]
 ] 

There are 1 DTest and 1 Unit unrelated failing tests in JAVA11. Should check 
for tickets logged. 

*WARNING:* Before commit return to the default requirements.txt file


was (Author: e.dimitrova):
*Summary:*
This branch contains:
- [first commit | 
https://github.com/ekaterinadimitrova2/cassandra/commit/a8a9145a032a9f2d9b74369f2e4474a210aa5b99]
 which contains parameters name changes as requested; backward compatibility 
with the old names; Proposed new structure into [sections 
|https://issues.apache.org/jira/browse/CASSANDRA-15234?focusedCommentId=17057969&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17057969]
 for cassandra.yaml. 
- the [second commit | 
https://github.com/ekaterinadimitrova2/cassandra/commit/032fbd8cca1d7b5b96738bd96d9672864426d718]
 implements the functionality which gives the end users the opportunity to 
attach units suffixes to Memory, Duration, Rates parameters. 
- [third commit 
|https://github.com/ekaterinadimitrova2/cassandra/commit/68f89503e6e6f30e8f6df1374cb553f243f0068e]
 is a ninja fix of one line which was changed in a wrong way during the latest 
rebase. 
- [fourth commit 
|https://github.com/ekaterinadimitrova2/cassandra/commit/8389010d704a9524a1c36d96f9e4d8179a8e2044]
 is to return the default config.yml

This patch requires custom [ [DTests | 
https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-3] 
] which run successfully with the following patch of [CCM 
|https://github.com/

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 6/5/20, 5:50 PM:
--

*Summary:*
This branch contains:
- [first commit | 
https://github.com/ekaterinadimitrova2/cassandra/commit/a8a9145a032a9f2d9b74369f2e4474a210aa5b99]
 which contains parameters name changes as requested; backward compatibility 
with the old names; Proposed new structure into [sections 
|https://issues.apache.org/jira/browse/CASSANDRA-15234?focusedCommentId=17057969&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17057969]
 for cassandra.yaml. 
- the [second commit | 
https://github.com/ekaterinadimitrova2/cassandra/commit/032fbd8cca1d7b5b96738bd96d9672864426d718]
 implements the functionality which gives the end users the opportunity to 
attach units suffixes to Memory, Duration, Rates parameters. 
- [third commit 
|https://github.com/ekaterinadimitrova2/cassandra/commit/68f89503e6e6f30e8f6df1374cb553f243f0068e]
 is a ninja fix of one line which was changed in a wrong way during the latest 
rebase. 
- [fourth commit 
|https://github.com/ekaterinadimitrova2/cassandra/commit/8389010d704a9524a1c36d96f9e4d8179a8e2044]
 is to return the default config.yml

This patch requires custom [ [DTests | 
https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-3] 
] which run successfully with the following patch of [CCM 
|https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234-3]
DTests - requirements.txt should be updated back to the original one before 
commit! 

The DTests are not backward compatible with the yaml file without units 
suffixes.
This part is covered by a unit test which tests the successful load of the 
values of the parameters without units as per the old format.

[ [trunk 
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-3-rebase 
] ] [ [DTests | 
https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-3] 
] [ [CCM |https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234-3] ] 
[ [JAVA8 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/193/workflows/718c8a04-385b-4ddc-ac2e-9291c37b1f1e]
 ] [ [JAVA11 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/193/workflows/6cd6048d-5daf-4490-a5d3-b5c3178a0757
 ] ] 

Attached to the ticket is the log of the successful runs of the few failing 
JAVA8 DTests in CircleCI. I ran them locally after fixing lost line of code as 
it didn't make sense to me to rerun the whole suite of tests. 

*Last update:* after rebase and a few nits on my end, we have only 1 DTest and 
1 Unit test failing in JAVA11. Unrelated known failures.
CQLSH JAVA11 tests are not currently available in CircleCI.

*WARNING:* Before commit return to the default requirements.txt file

This branch is a class of Accessors for System properties. *This patch could be 
considered separate of the previous one.* It doesn't require custom DTests or 
custom CCM.
[ [trunk 
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-5] ] [ 
[JAVA8 CI 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/195/workflows/ebd771ac-d71c-49ea-872b-00b534d9d5c6]
 ] [ [JAVA11 CI 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/195/workflows/19a3254b-cd7a-4e4f-856f-f314546ff9d7]
 ] 

There are 1 DTest and 1 Unit unrelated failing tests in JAVA11. Should check 
for tickets logged. 




was (Author: e.dimitrova):
*Summary:*
This branch contains:
- [first commit | 
https://github.com/ekaterinadimitrova2/cassandra/commit/a8a9145a032a9f2d9b74369f2e4474a210aa5b99]
 which contains parameters name changes as requested; backward compatibility 
with the old names; Proposed new structure into [sections 
|https://issues.apache.org/jira/browse/CASSANDRA-15234?focusedCommentId=17057969&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17057969]
 for cassandra.yaml. 
- the [second commit | 
https://github.com/ekaterinadimitrova2/cassandra/commit/032fbd8cca1d7b5b96738bd96d9672864426d718]
 implements the functionality which gives the end users the opportunity to 
attach units suffixes to Memory, Duration, Rates parameters. 
- [third commit 
|https://github.com/ekaterinadimitrova2/cassandra/commit/68f89503e6e6f30e8f6df1374cb553f243f0068e]
 is a ninja fix of one line which was changed in a wrong way during the latest 
rebase. 
- [fourth commit 
|https://github.com/ekaterinadimitrova2/cassandra/commit/8389010d704a9524a1c36d96f9e4d8179a8e2044]
 is to return the default config.yml

This patch requires custom [ [DTests | 
https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-3] 
] which run successfully with the following patch of [CCM 
|https://github.co

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 6/5/20, 5:49 PM:
--

*Summary:*
This branch contains:
- [first commit | 
https://github.com/ekaterinadimitrova2/cassandra/commit/a8a9145a032a9f2d9b74369f2e4474a210aa5b99]
 which contains parameters name changes as requested; backward compatibility 
with the old names; Proposed new structure into [sections 
|https://issues.apache.org/jira/browse/CASSANDRA-15234?focusedCommentId=17057969&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17057969]
 for cassandra.yaml. 
- the [second commit | 
https://github.com/ekaterinadimitrova2/cassandra/commit/032fbd8cca1d7b5b96738bd96d9672864426d718]
 implements the functionality which gives the end users the opportunity to 
attach units suffixes to Memory, Duration, Rates parameters. 
- [third commit 
|https://github.com/ekaterinadimitrova2/cassandra/commit/68f89503e6e6f30e8f6df1374cb553f243f0068e]
 is a ninja fix of one line which was changed in a wrong way during the latest 
rebase. 
- [fourth commit 
|https://github.com/ekaterinadimitrova2/cassandra/commit/8389010d704a9524a1c36d96f9e4d8179a8e2044]
 is to return the default config.yml

This patch requires custom [ [DTests | 
https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-3] 
] which run successfully with the following patch of [CCM 
|https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234-3]
DTests - requirements.txt should be updated back to the original one before 
commit! 

The DTests are not backward compatible with the yaml file without units 
suffixes.
This part is covered by a unit test which tests the successful load of the 
values of the parameters without units as per the old format.

[ [trunk 
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-3-rebase 
] ] [ [DTests | 
https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-3] 
] [ [CCM |https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234-3] ] 
[ [JAVA8 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/193/workflows/718c8a04-385b-4ddc-ac2e-9291c37b1f1e]
 ] [ [JAVA11 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/193/workflows/6cd6048d-5daf-4490-a5d3-b5c3178a0757
 ] ] 

Attached to the ticket is the log of the successful runs of the few failing 
JAVA8 DTests in CircleCI. I ran them locally after fixing lost line of code as 
it didn't make sense to me to rerun the whole suite of tests. 

*Last update:* after rebase and a few nits on my end, we have only 1 DTest and 
1 Unit test failing in JAVA11. Unrelated known failures.
CQLSH JAVA11 tests are not currently available in CircleCI.

This branch is a class of Accessors System properties. *This patch could be 
considered separate of the previous one.* It doesn't require custom DTests or 
custom CCM.
[ [trunk 
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-5] ] [ 
[JAVA8 CI 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/195/workflows/ebd771ac-d71c-49ea-872b-00b534d9d5c6]
 ] [ [JAVA11 CI 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/195/workflows/19a3254b-cd7a-4e4f-856f-f314546ff9d7]
 ] 

There are 1 DTest and 1 Unit unrelated failing tests in JAVA11. Should check 
for tickets logged. 

*WARNING:* Before commit return to the default requirements.txt file


was (Author: e.dimitrova):
*Summary:*
This branch contains:
- [first commit | 
https://github.com/ekaterinadimitrova2/cassandra/commit/a8a9145a032a9f2d9b74369f2e4474a210aa5b99]
 which contains parameters name changes as requested; backward compatibility 
with the old names; Proposed new structure into [sections 
|https://issues.apache.org/jira/browse/CASSANDRA-15234?focusedCommentId=17057969&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17057969]
 for cassandra.yaml. 
- the [second commit | 
https://github.com/ekaterinadimitrova2/cassandra/commit/032fbd8cca1d7b5b96738bd96d9672864426d718]
 implements the functionality which gives the end users the opportunity to 
attach units suffixes to Memory, Duration, Rates parameters. 
- [third commit 
|https://github.com/ekaterinadimitrova2/cassandra/commit/68f89503e6e6f30e8f6df1374cb553f243f0068e]
 is a ninja fix of one line which was changed in a wrong way during the latest 
rebase. 
- [fourth commit 
|https://github.com/ekaterinadimitrova2/cassandra/commit/8389010d704a9524a1c36d96f9e4d8179a8e2044]
 is to return the default config.yml

This patch requires custom [ [DTests | 
https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-3] 
] which run successfully with the following patch of [CCM 
|https://github.com/ekat

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 6/5/20, 3:37 AM:
--

[ [trunk 
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-3-rebase 
] ] [ [DTests | 
https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-3] 
] [ [CCM |https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234-3] ] 
[ [JAVA8 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/193/workflows/718c8a04-385b-4ddc-ac2e-9291c37b1f1e]
 ] [ [JAVA11 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/193/workflows/6cd6048d-5daf-4490-a5d3-b5c3178a0757
 ] ] 

Attached to the ticket is the log of the successful runs of the few failing 
JAVA8 DTests in CircleCI. I ran them locally after fixing lost line of code as 
it didn't make sense to me to rerun the whole suite of tests. 

*Last update:* after rebase and a few nits on my end, we have only 1 DTest and 
1 Unit test failing in JAVA11. Unrelated known failures.

- added additional note on the possible units to be used as suffixes in both 
NEWS.txt and cassandra.yaml

CQLSH JAVA11 tests are not currently available in CircleCI.


The last part is all green after rebase and CI run. 
- "line.separator" getter added
[ [trunk 
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-5] ] [ 
[JAVA8 CI 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/195/workflows/ebd771ac-d71c-49ea-872b-00b534d9d5c6]
 ] [ [JAVA11 CI 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/195/workflows/19a3254b-cd7a-4e4f-856f-f314546ff9d7]
 ] 

There are 1 DTest and 1 Unit unrelated failing tests in JAVA11. Should check 
for tickets logged. 

*NOTE:* Before commit return to the default config.yml and requirements.txt 
files


was (Author: e.dimitrova):
[ [trunk 
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-3-rebase 
] ] [ [DTests | 
https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-3] 
] [ [CCM |https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234-3] ] 
[ [JAVA8 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/193/workflows/718c8a04-385b-4ddc-ac2e-9291c37b1f1e]
 ] [ [JAVA11 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/193/workflows/6cd6048d-5daf-4490-a5d3-b5c3178a0757
 ] ] 

Attached to the ticket is the log of the successful runs of the few failing 
JAVA8 DTests in CircleCI. I ran them locally after fixing lost line of code as 
it didn't make sense to me to rerun the whole suite of tests. 

*Last update:* after rebase and a few nits on my end, we have only 1 DTest and 
1 Unit test failing in JAVA11. Unrelated known failures.

- added additional note on the possible units to be used as suffixes in both 
NEWS.txt and cassandra.yaml

CQLSH JAVA11 tests are not currently available in CircleCI.


The last part is all green after rebase and CI run. 
- "line.separator" getter added
[ [trunk 
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-5] ] [ 
[JAVA8 CI 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/195/workflows/ebd771ac-d71c-49ea-872b-00b534d9d5c6]
 ] [ [JAVA11 CI 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/195/workflows/19a3254b-cd7a-4e4f-856f-f314546ff9d7]
 ] 

There are 1 DTest and 1 Unit unrelated failing tests in JAVA11. Should check 
for tickets logged. 

*NOTE: *Before commit return to the default config.yml and requirements.txt 
files

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could n

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 6/5/20, 3:36 AM:
--

[ [trunk 
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-3-rebase 
] ] [ [DTests | 
https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-3] 
] [ [CCM |https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234-3] ] 
[ [JAVA8 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/193/workflows/718c8a04-385b-4ddc-ac2e-9291c37b1f1e]
 ] [ [JAVA11 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/193/workflows/6cd6048d-5daf-4490-a5d3-b5c3178a0757
 ] ] 

Attached to the ticket is the log of the successful runs of the few failing 
JAVA8 DTests in CircleCI. I ran them locally after fixing lost line of code as 
it didn't make sense to me to rerun the whole suite of tests. 

*Last update:* after rebase and a few nits on my end, we have only 1 DTest and 
1 Unit test failing in JAVA11. Unrelated known failures.

- added additional note on the possible units to be used as suffixes in both 
NEWS.txt and cassandra.yaml

CQLSH JAVA11 tests are not currently available in CircleCI.


The last part is all green after rebase and CI run. 
- "line.separator" getter added
[ [trunk 
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-5] ] [ 
[JAVA8 CI 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/195/workflows/ebd771ac-d71c-49ea-872b-00b534d9d5c6]
 ] [ [JAVA11 CI 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/195/workflows/19a3254b-cd7a-4e4f-856f-f314546ff9d7]
 ] 

There are 1 DTest and 1 Unit unrelated failing tests in JAVA11. Should check 
for tickets logged. 

*NOTE: *Before commit return to the default config.yml and requirements.txt 
files


was (Author: e.dimitrova):
[ [trunk 
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-3-rebase 
] ] [ [DTests | 
https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-3] 
] [ [CCM |https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234-3] ] 
[ [JAVA8 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/193/workflows/718c8a04-385b-4ddc-ac2e-9291c37b1f1e]
 ] [ [JAVA11 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/193/workflows/6cd6048d-5daf-4490-a5d3-b5c3178a0757
 ] ] 

Attached to the ticket is the log of the successful runs of the few failing 
JAVA8 DTests in CircleCI. I ran them locally after fixing lost line of code as 
it didn't make sense to me to rerun the whole suite of tests. 

*Last update:* after rebase and a few nits on my end, we have only 1 DTest and 
1 Unit test failing in JAVA11. Unrelated known failures.

- added additional note on the possible units to be used as suffixes in both 
NEWS.txt and cassandra.yaml

CQLSH JAVA11 tests are not currently available in CircleCI.


The last part is all green after rebase and CI run. 
- "line.separator" getter added
[ [trunk|] ] [ [JAVA8 CI 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/195/workflows/ebd771ac-d71c-49ea-872b-00b534d9d5c6]
 ] [ [JAVA11 CI 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/195/workflows/19a3254b-cd7a-4e4f-856f-f314546ff9d7]
 ] 

There are 1 DTest and 1 Unit unrelated failing tests in JAVA11. Should check 
for tickets logged. 

*NOTE: *Before commit return to the default config.yml and requirements.txt 
files

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 6/5/20, 3:35 AM:
--

[ [trunk 
|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-3-rebase 
] ] [ [DTests | 
https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-3] 
] [ [CCM |https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234-3] ] 
[ [JAVA8 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/193/workflows/718c8a04-385b-4ddc-ac2e-9291c37b1f1e]
 ] [ [JAVA11 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/193/workflows/6cd6048d-5daf-4490-a5d3-b5c3178a0757
 ] ] 

Attached to the ticket is the log of the successful runs of the few failing 
JAVA8 DTests in CircleCI. I ran them locally after fixing lost line of code as 
it didn't make sense to me to rerun the whole suite of tests. 

*Last update:* after rebase and a few nits on my end, we have only 1 DTest and 
1 Unit test failing in JAVA11. Unrelated known failures.

- added additional note on the possible units to be used as suffixes in both 
NEWS.txt and cassandra.yaml

CQLSH JAVA11 tests are not currently available in CircleCI.


The last part is all green after rebase and CI run. 
- "line.separator" getter added
[ [trunk|] ] [ [JAVA8 CI 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/195/workflows/ebd771ac-d71c-49ea-872b-00b534d9d5c6]
 ] [ [JAVA11 CI 
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/195/workflows/19a3254b-cd7a-4e4f-856f-f314546ff9d7]
 ] 

There are 1 DTest and 1 Unit unrelated failing tests in JAVA11. Should check 
for tickets logged. 

*NOTE: *Before commit return to the default config.yml and requirements.txt 
files


was (Author: e.dimitrova):

[ trunk ] [ DTests ] [ CCM ] [ JAVA8 ] [ JAVA11 ]
Attached to the ticket is the log of the successful runs of the few failing 
JAVA8 DTests in CircleCI. I ran them locally after fixing lost line of code as 
it didn't make sense to me to rerun the whole suite of tests.
Last update: after rebase and a few nits on my end, we have only 1 DTest and 1 
Unit test failing in JAVA11. Unrelated known failures.
added additional note on the possible units to be used as suffixes in both 
NEWS.txt and cassandra.yaml
CQLSH JAVA11 tests are not currently available in CircleCI.
The last part is all green after rebase and CI run.
"line.separator" getter added
[ [trunk|] ] [ JAVA8 CI ] [ JAVA11 CI ]
There are 1 DTest and 1 Unit unrelated failing tests in JAVA11. Should check 
for tickets logged.
*NOTE: *Before commit return to the default config.yml and requirements.txt 
files

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for either 
> their old or new definition e.g. {{KiB/s}}, or we could support them and 
> simply log the value in bytes/s.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters



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

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 6/4/20, 6:54 PM:
--

*UPDATE:* 
- the failing unit test is a flakey test. The configuration is properly loaded 
so it is not caused by this patch.
- small issue with Auth_test.py was fixed.
- the rest of the failing DTests are related to current failures we already see 
on trunk. Some of them are already fixed in the newer commits. Rebase and run 
new CI now to confirm the latest status.


was (Author: e.dimitrova):
*UPDATE:* 
- the failing unit test is a flakey test. The configuration is properly loaded 
so it is not caused by this patch.
- small issue with Auth_test.py was fixed.
- the rest of the failing unit tests are related to current failures we already 
see on trunk. Some of them are already fixed in the newer commits. Rebase and 
run new CI now to confirm the latest status.

> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> We have a bunch of inconsistent names and config patterns in the codebase, 
> both from the yams and JVM properties.  It would be nice to standardise the 
> naming (such as otc_ vs internode_) as well as the provision of values with 
> units - while maintaining perpetual backwards compatibility with the old 
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s, 
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or 
> powers of 1000 such as {{KB/s}}, given these are regularly used for either 
> their old or new definition e.g. {{KiB/s}}, or we could support them and 
> simply log the value in bytes/s.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters