[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17164627#comment-17164627
]
Ekaterina Dimitrova commented on CASSANDRA-15234:
-------------------------------------------------
[~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 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.
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}
> 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
