[
https://issues.apache.org/jira/browse/CASSANDRA-16873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17404624#comment-17404624
]
Michael Semb Wever edited comment on CASSANDRA-16873 at 8/25/21, 5:30 PM:
--------------------------------------------------------------------------
My two cents, this patch falls into that "small improvement that doesn't do
much else but fix something" category, and should be included in 4.0.x
bq. Either way, this exchange highlights an issue to address which is that an
absolutist policy leads to gamification of terminology. Clearly we shouldn't be
calling something a bug fix so it can be included in a release.
I agree that it is really important that we avoid any encouragement of gaming
what a bug is.
We do have some precedence for distinguishing "small improvements ok to go into
patch versions" versus normal improvements, and we have been seeing more of it
on the ML recently. But we have no guidelines in place how to make the
distinction (it's being worked on). IMHO this is going to bite us now that we
commit to annual releases (and are still ironing out what "stable trunk" means
for us and how to achieve it) with folk encouraged to see the severity or need
of an improvement as a reason to re-classify it. Including an improvement into
a Patch version should be a decision based on what the patch touches and does.
Until we clear up what that actually means, I am against improvements going
into a Patch version by default, without first some discussion and consensus
(on the ticket) to apply the waiver.
My reasoning for voting on taking a more limited approach is… if we are to grow
the community, and build momentum, it is going to be much harder for us to
ensure quality (stable branches) through reviews. And so it is for our sanity
to focus development on trunk as much as possible. That is, the stability of
the code remains dependent on reviews, where our ability to review is limited,
and reviewing patches for multiple branches does costs more (in both attention
and in time).
I can also see that by encouraging the discussions to establish the waivers we
can more organically grow the guideline documentation around it.
was (Author: michaelsembwever):
My two cents, this patch falls into that "small improvement that doesn't do
much else but fix something" category, and should be included in 4.0.x
bq. Either way, this exchange highlights an issue to address which is that an
absolutist policy leads to gamification of terminology. Clearly we shouldn't be
calling something a bug fix so it can be included in a release.
I agree that it is really important that we avoid any encouragement of gaming
what a bug is.
We do have some precedence for distinguishing "small improvements ok to go into
patch versions" versus normal improvements, and we have been seeing more of it
on the ML recently. But we have no guidelines in place how to make the
distinction (it's being worked on). IMHO this is going to bite us now that we
commit to annual releases (and are still ironing out what "stable trunk" means
for us and how to achieve it) with folk encouraged to see the severity or need
of an improvement as a reason to re-classify it. Including an improvement into
a Patch version should be a decision based on what the patch touches and does.
Until we clear up what that actually means, I am against improvements going
into a Patch version by default, without first some discussion and consensus
(on the ticket) to apply the waiver.
My reasoning for voting on taking a more limited approach is… if we are to grow
the community, and build momentum, it is going to be much harder for us to
ensure quality (stable branches) through reviews only. And so it is for our
sanity to focus development on trunk as much as possible. That is, the
stability of the code remains dependent on reviews, where our ability to review
is limited, and reviewing patches for multiple branches does costs more (in
both attention and in time).
I can also see that by encouraging the discussions to establish the waivers we
can more organically grow the guideline documentation around it.
> Tolerate missing DNS entry when completing a host replacement
> -------------------------------------------------------------
>
> Key: CASSANDRA-16873
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16873
> Project: Cassandra
> Issue Type: Improvement
> Components: Cluster/Membership
> Reporter: Josh McKenzie
> Assignee: Josh McKenzie
> Priority: Normal
> Fix For: 4.0.x
>
>
> In one of our deployments, after a host replacement a subset of nodes still
> saw the nodes as JOINING despite the rest of the cluster seeing it as NORMAL
> with a failure to gossip. This was traced to a DNS lookup failure on the
> nodes during an interim state leading to an exception being thrown and gossip
> state never transitioning.
> Rather than implicitly requiring operators to bounce the node by throwing an
> exception, we should instead suppress the exception when checking if a node
> is replacing the same host address and ID if we get an UnknownHostException.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
