-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Testing upgrade path from / downgrade path to v8.0.0 #7294
Testing upgrade path from / downgrade path to v8.0.0 #7294
Conversation
Signed-off-by: Shlomi Noach <[email protected]>
Signed-off-by: Shlomi Noach <[email protected]>
Signed-off-by: Shlomi Noach <[email protected]>
Signed-off-by: Shlomi Noach <[email protected]>
Signed-off-by: Shlomi Noach <[email protected]>
Signed-off-by: Shlomi Noach <[email protected]>
Signed-off-by: Shlomi Noach <[email protected]>
…G if reusing data Signed-off-by: Shlomi Noach <[email protected]>
…lace; if reusing existing data, we do not create and do not populate. In both cases, we now test for expected table data Signed-off-by: Shlomi Noach <[email protected]>
Signed-off-by: Shlomi Noach <[email protected]>
Signed-off-by: Shlomi Noach <[email protected]>
Signed-off-by: Shlomi Noach <[email protected]>
Signed-off-by: Shlomi Noach <[email protected]>
Signed-off-by: Shlomi Noach <[email protected]>
Signed-off-by: Shlomi Noach <[email protected]>
Signed-off-by: Shlomi Noach <[email protected]>
A "fun" loophole I got into is this: I've added a an |
Signed-off-by: Shlomi Noach <[email protected]>
Signed-off-by: Shlomi Noach <[email protected]>
Signed-off-by: Shlomi Noach <[email protected]>
Signed-off-by: Shlomi Noach <[email protected]>
Signed-off-by: Shlomi Noach <[email protected]>
Signed-off-by: Shlomi Noach <[email protected]>
Signed-off-by: Shlomi Noach <[email protected]>
Signed-off-by: Shlomi Noach <[email protected]>
Signed-off-by: Shlomi Noach <[email protected]>
Signed-off-by: Shlomi Noach <[email protected]>
Signed-off-by: Shlomi Noach <[email protected]>
Also copying this to main comment This PR introduced The test verifies that a vitess cluster which was built, started and populated by a The way this works:
So this test basically starts a "latest" version of Vitess on top of preexisting What kind of changes were made:
|
Ready for review. |
|
This PR should be backported to |
Signed-off-by: Shlomi Noach <[email protected]>
Signed-off-by: Shlomi Noach <[email protected]>
Signed-off-by: Shlomi Noach <[email protected]>
This PR now also includes a downgrade path test |
Signed-off-by: Shlomi Noach <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is excellent! Just one typo, can merge after fixing that.
rm -rf /tmp/vtdataroot | ||
mkdir -p /tmp/vtdataroot | ||
source build.env | ||
# We pass -skip-build so that we use he v8.0.0 binaries, not HEAD binaries |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
# We pass -skip-build so that we use he v8.0.0 binaries, not HEAD binaries | |
# We pass -skip-build so that we use the v8.0.0 binaries, not HEAD binaries |
This is a great start towards completely automating the upgrade/downgrade testing.
|
Signed-off-by: Shlomi Noach <[email protected]>
#7323 is a resubmission as a backport to 9.0 |
Description
Followup to team discussion, we wish to add CI (endtoend) tests that validate an upgrade from a previous tagged version.
This PR introduces
endtoend
version upgrade test, specifically testing an upgrade path fromv8.0.0
. (side note,v9.0.0
will be released later this month, and then we will add a test for av9.0.0
upgrade path).The test verifies that a vitess cluster which was built, started and populated by a
v8.0.0
release, is readable by aHEAD
(the PR branch) build.The way this works:
.github/workflows/cluster_endtoend_upgrade.yml
is the workflow filev8.0.0
, and builds the binariesHEAD
v8.0.0
go/test/endtoend/versionupgrade/upgrade_test.go
-keep-data
)HEAD
again, cleaning up the workflow running directoryHEAD
etcd2
loads from existing datamysqld
starts with existing datavttablet
s start with existing data (and are already inSERVING
mode)So this test basically starts a "latest" version of Vitess on top of preexisting
v8.0.0
data, andSELECT
s data from tables to prove the upgrade is good.We may add additional tests to verify the upgrade path is good.
What kind of changes were made:
endtoend
tests intentionally randomized paths, ports, etc. But we have to be able to run two vitess clusters on exact same paths, ports etc. To that effect we introduce these flags:-force-vtdataroot
(path)-force-port-start
(port number)-force-base-tablet-uid
(number)With these three supplied, all locations and ports are idempotent.
test.go
has a-skip-build
flag; this is required because we want to be able to run the latest upgrade test, on a past release, which may not have this test (specifically,v8.0.0
does not have this test). We use this to run a latest test on top of pre-builtv8.0.0
binaries.LocalProcessCluster
has a field calledReusingVTDATAROOT
which indicates whether this cluster started from empty, and initialized itself (false
), or whether the cluster reused an existing dataset (true
)cluster_process.go
uses that field to decide whether it should initializemysql
, or create keyspaces, or what state it expects tablet to start with, etc.-
go/test/endtoend/cluster/vtctlclient_process.go
uses that field to determine if it needs to populate database tables and data or not.EDIT
Symmetrically, the workflow now also runs a downgrade path test.
Related Issue(s)
Checklist
Deployment Notes
Impacted Areas in Vitess
Components that this PR will affect: