[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17065133#comment-17065133
]
Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 3/23/20, 10:01 PM:
----------------------------------------------------------------------------
[Part1|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-2]
- dtests are still running and have to clear/correct some comments in config
but all in-jvm and unit tests look fine to me.
- 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). Might need some refactoring here and there
but I found this as the easiest and least disruptive approach. Also, there is a
warning to the user that there is new yaml version and he/she can consider an
update. Also TO DO for later: change cassandra.yaml in conf and test/conf and
put cassandra-old.yaml in the test/conf....Should update also CHANGES.txt and
NEWS.txt at some point when I am done...
Still have to complete some parts of the other stuff before sharing. For
example, still wondering a bit about the best place to incorporate the
parsing(also the unit converts...) to ensure least disruptions in the current
code logic. Looks to me that it might be good again to call it during the yaml
file load. Should think about it a bit more.
Any constructive feedback is always appreciated.
was (Author: e.dimitrova):
[Part1|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-2]
- dtests are still running and have to clear/correct some comments in config
but all in-jvm and unit tests look fine to me.
- 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). Might need some refactoring here and there
but I found this as the easiest and least disruptive approach. Also, there is a
warning to the user that there is new yaml version and he/she can consider an
update. Also TO DO for later: change cassandra.yaml in conf and test/conf and
put cassandra-old.yaml in the test/conf....Should update also CHANGES.txt and
NEWS.txt at some point when I am done...
Still have to complete some parts of the other stuff before sharing. For
example, still wondering a bit about the best place to incorporate the parsing
to ensure least disruptions in the current code logic. Looks to me that it
might be good again to call it during the yaml file load. Should think about it
a bit more.
Any constructive feedback is always appreciated.
> 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, 4.0-beta
>
>
> 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
