Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

keys: remove compatibility with pre-VersionMeta2Splits nodes #26967

Merged
merged 2 commits into from
Jun 26, 2018

Conversation

nvanbenschoten
Copy link
Member

@nvanbenschoten nvanbenschoten commented Jun 25, 2018

This change removes the compatibility layer introduced with
VersionMeta2Splits that conditionally decided whether
splitting meta2 ranges was permitted. In doing so, it cleans
up some plumbing code that is no longer needed in 2.1 binaries.

Release note: None

@nvanbenschoten nvanbenschoten requested review from bdarnell and a team June 25, 2018 21:45
@nvanbenschoten
Copy link
Member Author

This change brings up an interesting question. We don't have a defined process for what to do when old cluster.VersionKeys are no longer needed. We could leave them as they are or we could delete the VersionKey and the associated keyedVersion struct in the versionsSingleton.

@cockroach-teamcity
Copy link
Member

This change is Reviewable

@bdarnell
Copy link
Contributor

:lgtm:

I think it's good idea to go back and remove old VersionKeys (and their associated runtime checks) when they're no longer needed. But we should probably go in order - don't remove VersionMeta2Splits before we've removed all the old ones.


Reviewed 12 of 12 files at r1.
Review status: :shipit: complete! 0 of 0 LGTMs obtained (and 1 stale)


Comments from Reviewable

This change removes the compatibility layer introduced with
`VersionMeta2Splits` that conditionally decided whether
splitting meta2 ranges was permitted. In doing so, it cleans
up some plumbing code that is no longer needed in 2.1 binaries.

Release note: None
@nvanbenschoten
Copy link
Member Author

I think it's good idea to go back and remove old VersionKeys (and their associated runtime checks) when they're no longer needed. But we should probably go in order - don't remove VersionMeta2Splits before we've removed all the old ones.

That sounds reasonable to me. I went through and marked unused version keys (those that have had their associated runtime checks removed) as such. I also added instructions on deleting unstable versions. PTAL @ the new commit.

@bdarnell
Copy link
Contributor

Review status: :shipit: complete! 0 of 0 LGTMs obtained (and 1 stale)


pkg/settings/cluster/cockroach_versions.go, line 37 at r3 (raw file):

//     file.
//   - If the version key after a major or minor version is unused, remove it
//     and its associated keyedVersion. However, don't remove major or minor

Why shouldn't major or minor versions be removed?

I realized this is missing a step: you need to adjust the starting point of the iota. Since that's easy to get catastrophically wrong, I now think we should keep entries in this const list forever (but maybe unexport them when they become unused).


Comments from Reviewable

This provides a set of instructions on deleting a `VersionKey`. They
mirror the existing instructions on adding a `VersionKey`.

Release note: None
@nvanbenschoten
Copy link
Member Author

Review status: :shipit: complete! 0 of 0 LGTMs obtained (and 1 stale)


pkg/settings/cluster/cockroach_versions.go, line 37 at r3 (raw file):

Why shouldn't major or minor versions be removed?

Removed that.

I realized this is missing a step: you need to adjust the starting point of the iota. Since that's easy to get catastrophically wrong, I now think we should keep entries in this const list forever (but maybe unexport them when they become unused).

I considered this but convinced myself that it's not actually an issue. VersionKeys are only used to index into versionsSingleton. They're not persisted and not communicated between nodes. As long as a given VersionKey still indexes to the same roachpb.Version in versionsSingleton between binaries, we won't have a problem.


Comments from Reviewable

@bdarnell
Copy link
Contributor

Review status: :shipit: complete! 0 of 0 LGTMs obtained (and 1 stale)


pkg/settings/cluster/cockroach_versions.go, line 37 at r3 (raw file):

Previously, nvanbenschoten (Nathan VanBenschoten) wrote…

Why shouldn't major or minor versions be removed?

Removed that.

I realized this is missing a step: you need to adjust the starting point of the iota. Since that's easy to get catastrophically wrong, I now think we should keep entries in this const list forever (but maybe unexport them when they become unused).

I considered this but convinced myself that it's not actually an issue. VersionKeys are only used to index into versionsSingleton. They're not persisted and not communicated between nodes. As long as a given VersionKey still indexes to the same roachpb.Version in versionsSingleton between binaries, we won't have a problem.

Ack. I forgot that the persisted values are elsewhere.


Comments from Reviewable

@nvanbenschoten
Copy link
Member Author

bors r+

craig bot pushed a commit that referenced this pull request Jun 26, 2018
26967: keys: remove compatibility with pre-VersionMeta2Splits nodes r=nvanbenschoten a=nvanbenschoten

This change removes the compatibility layer introduced with
`VersionMeta2Splits` that conditionally decided whether
splitting meta2 ranges was permitted. In doing so, it cleans
up some plumbing code that is no longer needed in 2.1 binaries.

Release note: None

26977: storage: factor out node dialer from RaftTransport r=bdarnell a=tschottdorf

RaftTransport wraps RPC connections between nodes with additional
circuit breaker logic to avoid spamming dead nodes (plus spamming the
logs). Upcoming work on follower reads needs similar machinery, and
there are various other components in the system that connect to other
nodes and should already be using such a mechanism.

This commit extracts this logic into a standalone component named
`NodeDialer`. In future work, a single `NodeDialer` will be shared
across a running node.

There is a semantic change in behavior that deserves being called out.
Prior to this change, the Raft circuit breakers were tripped not only
based on whether it was possible to connect to a given target node, but
also based on error codes returned from the calls, and notably
StoreNotFoundError.
This is no longer the case, as it would be at odds with the goal of
sharing these circuit breakers across multiple use cases and maintaining
the old behavior would require adding another layer of circuit breaking
inside the Raft transport.

Looking at the history of this behavior (#10266), it seems to have been
introduced because bringing a new node up under the address of an old
node could wedge the (ancient version of the) transport indefinitely as
it didn't reconnect in that case (taking the correct address from
Gossip) but kept sending messages to the wrong node. This is still fixed
with my changes; only the backoff is lost, which seems acceptable.

Release note: None

Co-authored-by: Nathan VanBenschoten <[email protected]>
Co-authored-by: Tobias Schottdorf <[email protected]>
@craig
Copy link
Contributor

craig bot commented Jun 26, 2018

Build succeeded

@craig craig bot merged commit 822965b into cockroachdb:master Jun 26, 2018
@nvanbenschoten nvanbenschoten deleted the nvanbenschoten/meta2splits branch July 11, 2018 16:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants