[jira] [Comment Edited] (CASSANDRA-15893) JAVA 11: test_short_read - consistency_test.TestConsistency
[ https://issues.apache.org/jira/browse/CASSANDRA-15893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17151446#comment-17151446 ] Ekaterina Dimitrova edited comment on CASSANDRA-15893 at 7/5/20, 12:37 AM: --- Locally I failed it also in java 8. Also, I checked it with older trunk versions from April and it was failing. So I wouldn't close it. The thing is that it was not failing up until recently neither in Jenkins, nor in CircleCI (but probably no one had the need to run it locally :-( ). Now It fails in CircleCI. So whatever is the issue, it got bigger. I will try to look at it more next week was (Author: e.dimitrova): Locally I failed it also in java 8. Also, I checked it with older trunk versions from April and it was failing. So I wouldn't close it. The thing is that it was not failing up until recently neither in Jenkins, nor in CircleCI. Now It fails in CircleCI. So whatever is the issue, it got bigger. I will try to look at it more next week > JAVA 11: test_short_read - consistency_test.TestConsistency > --- > > Key: CASSANDRA-15893 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15893 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Ekaterina Dimitrova >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-rc > > > JAVA 11: test_short_read - consistency_test.TestConsistency > Failing locally and in CircleCI: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/222/workflows/11202c7e-6c94-4d4e-bbbf-9e2fa9791ad0/jobs/1337 -- 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] [Commented] (CASSANDRA-15893) JAVA 11: test_short_read - consistency_test.TestConsistency
[ https://issues.apache.org/jira/browse/CASSANDRA-15893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17151446#comment-17151446 ] Ekaterina Dimitrova commented on CASSANDRA-15893: - Locally I failed it also in java 8. Also, I checked it with older trunk versions from April and it was failing. So I wouldn't close it. The thing is that it was not failing up until recently neither in Jenkins, nor in CircleCI. Now It fails in CircleCI. So whatever is the issue, it got bigger. I will try to look at it more next week > JAVA 11: test_short_read - consistency_test.TestConsistency > --- > > Key: CASSANDRA-15893 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15893 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Ekaterina Dimitrova >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-rc > > > JAVA 11: test_short_read - consistency_test.TestConsistency > Failing locally and in CircleCI: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/222/workflows/11202c7e-6c94-4d4e-bbbf-9e2fa9791ad0/jobs/1337 -- 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] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17151396#comment-17151396
]
Michael Semb Wever commented on CASSANDRA-15234:
I'm struggling to see how a request to break work down into separate tickets
and steps constitutes a technical reasoning that should block the work. The
valid concern around the api churn it introduces is addressed by committing the
new ticket to 4.0-beta.
The more we can do incrementally the better. From reviewing, to testing, to the
compartmentalising of jira ticket discussions. (I still miss jira comment
threads, even if folk never really used them consistently.)
bq. … everyone has since agreed (or implied) this is a superior approach.
Not on my behalf. And I don't believe all others presumed answers to all
questions that need to be asked for it to be a validated proposal. For my part,
it is a good suggestion that warrants further investigation. It still needs to
be investigated and spec'd out.
bq. If we change our minds and agree the current approach is the final and
superior solution, that is another matter.
Not sure I agree with the onus here, based on this being an un-investigated and
un-specified suggestion. The onus I think should be the opposite: those wanting
this to be a blocker should do the work in determining the value
(investigation) and design (specification) to the suggestion.
The suggestion is not a fault or bug in this ticket, there is nothing in the
suggestion that *breaks* the patch, it is imho rather a subsequent suggested
improvement. Even if it was a suggestion that replaced this patch it should be
dealt with in the same way. And of course making such a suggestion first here
is natural because the author _may_ take it on in-stride, but it should be the
author's prerogative to request it be "the next step".
In a new ticket: we can better investigate the value that grouping brings and
other questions like…
- 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)
> 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] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17151344#comment-17151344
]
Josh McKenzie commented on CASSANDRA-15234:
---
{quote}bq. To be more explicit: I am (binding) -1 knowingly shipping an
_interim_ solution for a public API. It is user unfriendly.
{quote}
We as a project need to mindfully balance when something is "good enough" and
when the trade-off is in favor of getting a release out vs. pursuing another
incremental improvement to an API. In my opinion this is classic bike-shedding.
Given a day focused on nothing but thinking of how to improve our config API I
firmly believe we could come up with something that a simple majority
considered an improvement over what's proposed on this ticket + config grouping
in a vacuum. _I personally prefer the config param grouping_, but not when
weighed against delaying the beta when it's this been long since a prior
release.
I perceive on balance what is in our users' best interests is having a release
with all the defect fixes and features available in 4.0. This point of view
stems from the empirical evidence of multiple users asking if the project is
dead and expressing a strong interest in running 4.0 having heard of the
proximity of the beta. I have no evidence of users stating that a lack of
configuration grouping in the project causes them equal or greater pain, nor
have I seen a cogent argument for that point of view.
The underlying question we face is how we balance the value to end-users of
having as optimal of an API as we can possibly come up in a specific domain vs.
the value to end-users of the other things that are delayed due to that effort.
Your point of view [~benedict] _appears to be_ that delaying the beta and the
engagement of the user community's testing of the 4.0 release is justified by
the value gained in grouping config params and not having a renamed paradigm
for 4.0 and subsequent grouping paradigm in our next major. My apologies if I'm
mis-characterizing your point of view here.
It's within any committers prerogative to binding -1 things on justified
technical grounds. I'd be curious what your perspective is on how we determine
what qualifies as justified [~benedict], [~mck2] , and [~maedhroz] in a context
such as this, as you all have expressed points of view here.
> 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=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
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17151336#comment-17151336
]
Benedict Elliott Smith commented on CASSANDRA-15234:
> 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
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17151255#comment-17151255
]
Michael Semb Wever commented on CASSANDRA-15234:
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
