From 8b37da73f51e7ee4a2d08b6da96d88b2c994f5f3 Mon Sep 17 00:00:00 2001 From: Philip O'Toole Date: Mon, 11 Dec 2023 19:06:04 -0500 Subject: [PATCH 1/7] Update CHANGELOG.md https://github.com/rqlite/rqlite/issues/1474 --- CHANGELOG.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 06bf4bb9..5f7473d5 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -36,7 +36,7 @@ This release also eases operations, as well as adding new features and bug fixes Release 8.0 supports (mostly) seamless upgrades from the 7.x series, and upgrading from 7.x has been tested. However, it is still strongly recommended you backup any production cluster before attempting an upgrade. A more conservative approach would be to create a brand new 8.0 system, and load your backup into that cluster. Then switch production traffic over to the new 8.0 cluster. -8.0 and 7.x nodes should be able to interoperate, so a rolling upgrade should work fine. Again, it is strongly recommended you test this first. However it is not recommended that you run a cluster with a mix of 7.x and 8.0 code for any significant length of time, just the time required for a rolling upgrade. +8.0 and 7.x nodes should be able to interoperate, so a rolling upgrade should work fine **as long as all nodes are fully caught up with the Leader node**. In addition you cannot join a new 8.x node to a pre-existing 7.x cluster. Otherwise upgrade should operate but, again, it is strongly recommended you test this first. It is also not recommended that you run a cluster with a mix of 7.x and 8.0 code for any significant length of time, just the time required for a rolling upgrade. Important things to note if you decide to upgrade an existing 7.x system: - 8.0 always runs with an on-disk database, in-memory databases are no longer supported. Improvements made late in the 7.0 series mean there is little difference in write performance between in-memory and on-disk modes, but supporting both modes just meant confusion and higher development costs. If you were previously running in in-memory mode (the previous default), you don't need to do anything. But if you were previously passing `-on-disk` to `rqlited` so that rqlite ran in on-disk mode, you must now remove that flag. From 9b5edca9d26bfdba2f62ffddddc3b3582e380203 Mon Sep 17 00:00:00 2001 From: Philip O'Toole Date: Mon, 11 Dec 2023 19:08:58 -0500 Subject: [PATCH 2/7] Update CHANGELOG.md --- CHANGELOG.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index 5f7473d5..5090325b 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -39,6 +39,8 @@ Release 8.0 supports (mostly) seamless upgrades from the 7.x series, and upgradi 8.0 and 7.x nodes should be able to interoperate, so a rolling upgrade should work fine **as long as all nodes are fully caught up with the Leader node**. In addition you cannot join a new 8.x node to a pre-existing 7.x cluster. Otherwise upgrade should operate but, again, it is strongly recommended you test this first. It is also not recommended that you run a cluster with a mix of 7.x and 8.0 code for any significant length of time, just the time required for a rolling upgrade. Important things to note if you decide to upgrade an existing 7.x system: +- Backup your 7.x cluster first. +- Upgrade your 7.x cluster to the [7.21.4](https://github.com/rqlite/rqlite/releases/tag/v7.21.4) before upgrading to the 8.0 series. - 8.0 always runs with an on-disk database, in-memory databases are no longer supported. Improvements made late in the 7.0 series mean there is little difference in write performance between in-memory and on-disk modes, but supporting both modes just meant confusion and higher development costs. If you were previously running in in-memory mode (the previous default), you don't need to do anything. But if you were previously passing `-on-disk` to `rqlited` so that rqlite ran in on-disk mode, you must now remove that flag. - When forming a new cluster using 8.0, pass the **Raft** addresss of the remote node to the `-join` command, not the HTTP API address. If your cluster is already formed, upgrades will work without changing anything (`-join` options are ignored if nodes are already members of a cluster). You may need to change any scripting or automatic-configuration generation however. - A few rarely, if ever, used `rqlited` command-line flags have been removed. These flags just added operational overhead, while adding little value. From 3cf1db3afea5ae0178d4934ec86c0f0502a72e35 Mon Sep 17 00:00:00 2001 From: Philip O'Toole Date: Mon, 11 Dec 2023 19:09:42 -0500 Subject: [PATCH 3/7] Update CHANGELOG.md --- CHANGELOG.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 5090325b..b3fdfecb 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -36,7 +36,7 @@ This release also eases operations, as well as adding new features and bug fixes Release 8.0 supports (mostly) seamless upgrades from the 7.x series, and upgrading from 7.x has been tested. However, it is still strongly recommended you backup any production cluster before attempting an upgrade. A more conservative approach would be to create a brand new 8.0 system, and load your backup into that cluster. Then switch production traffic over to the new 8.0 cluster. -8.0 and 7.x nodes should be able to interoperate, so a rolling upgrade should work fine **as long as all nodes are fully caught up with the Leader node**. In addition you cannot join a new 8.x node to a pre-existing 7.x cluster. Otherwise upgrade should operate but, again, it is strongly recommended you test this first. It is also not recommended that you run a cluster with a mix of 7.x and 8.0 code for any significant length of time, just the time required for a rolling upgrade. +8.0 and 7.x nodes should be able to interoperate, so a rolling upgrade should work fine **as long as all nodes are fully caught up with the Leader node**. Note you also cannot join a new 8.x node to a pre-existing 7.x cluster. Otherwise upgrade should operate but, again, it is strongly recommended you test this first. It is also not recommended that you run a cluster with a mix of 7.x and 8.0 code for any significant length of time, just the time required for a rolling upgrade. Important things to note if you decide to upgrade an existing 7.x system: - Backup your 7.x cluster first. From b7a1bb7d7349e4f39f663c1c2c5b86df1db13407 Mon Sep 17 00:00:00 2001 From: Philip O'Toole Date: Mon, 11 Dec 2023 19:10:38 -0500 Subject: [PATCH 4/7] Update CHANGELOG.md --- CHANGELOG.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index b3fdfecb..a77557a8 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -40,7 +40,7 @@ Release 8.0 supports (mostly) seamless upgrades from the 7.x series, and upgradi Important things to note if you decide to upgrade an existing 7.x system: - Backup your 7.x cluster first. -- Upgrade your 7.x cluster to the [7.21.4](https://github.com/rqlite/rqlite/releases/tag/v7.21.4) before upgrading to the 8.0 series. +- Strongly recommended you upgrade your 7.x cluster to the [7.21.4](https://github.com/rqlite/rqlite/releases/tag/v7.21.4) release before upgrading to the 8.0 series. - 8.0 always runs with an on-disk database, in-memory databases are no longer supported. Improvements made late in the 7.0 series mean there is little difference in write performance between in-memory and on-disk modes, but supporting both modes just meant confusion and higher development costs. If you were previously running in in-memory mode (the previous default), you don't need to do anything. But if you were previously passing `-on-disk` to `rqlited` so that rqlite ran in on-disk mode, you must now remove that flag. - When forming a new cluster using 8.0, pass the **Raft** addresss of the remote node to the `-join` command, not the HTTP API address. If your cluster is already formed, upgrades will work without changing anything (`-join` options are ignored if nodes are already members of a cluster). You may need to change any scripting or automatic-configuration generation however. - A few rarely, if ever, used `rqlited` command-line flags have been removed. These flags just added operational overhead, while adding little value. From 8d35c252f2285dfa41df17502136cb890c9686ad Mon Sep 17 00:00:00 2001 From: Philip O'Toole Date: Mon, 11 Dec 2023 19:11:26 -0500 Subject: [PATCH 5/7] Update CHANGELOG.md --- CHANGELOG.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index a77557a8..50937f38 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -40,7 +40,7 @@ Release 8.0 supports (mostly) seamless upgrades from the 7.x series, and upgradi Important things to note if you decide to upgrade an existing 7.x system: - Backup your 7.x cluster first. -- Strongly recommended you upgrade your 7.x cluster to the [7.21.4](https://github.com/rqlite/rqlite/releases/tag/v7.21.4) release before upgrading to the 8.0 series. +- it is strongly recommended you upgrade your 7.x cluster to the [7.21.4](https://github.com/rqlite/rqlite/releases/tag/v7.21.4) release before upgrading to the 8.0 series. - 8.0 always runs with an on-disk database, in-memory databases are no longer supported. Improvements made late in the 7.0 series mean there is little difference in write performance between in-memory and on-disk modes, but supporting both modes just meant confusion and higher development costs. If you were previously running in in-memory mode (the previous default), you don't need to do anything. But if you were previously passing `-on-disk` to `rqlited` so that rqlite ran in on-disk mode, you must now remove that flag. - When forming a new cluster using 8.0, pass the **Raft** addresss of the remote node to the `-join` command, not the HTTP API address. If your cluster is already formed, upgrades will work without changing anything (`-join` options are ignored if nodes are already members of a cluster). You may need to change any scripting or automatic-configuration generation however. - A few rarely, if ever, used `rqlited` command-line flags have been removed. These flags just added operational overhead, while adding little value. From 6290ad801bc7476b9f5faa2b00cee260c9036a8a Mon Sep 17 00:00:00 2001 From: Philip O'Toole Date: Mon, 11 Dec 2023 21:30:51 -0500 Subject: [PATCH 6/7] Minor CLI improvements --- cmd/rqlite/main.go | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/cmd/rqlite/main.go b/cmd/rqlite/main.go index 94ec7093..a37696b2 100644 --- a/cmd/rqlite/main.go +++ b/cmd/rqlite/main.go @@ -88,20 +88,21 @@ func main() { return nil } + connectionStr := fmt.Sprintf("%s://%s:%d", argv.Protocol, argv.Host, argv.Port) version, err := getVersionWithClient(httpClient, argv) if err != nil { msg := err.Error() if errors.Is(err, syscall.ECONNREFUSED) { - msg = fmt.Sprintf("Unable to connect to rqlited at %s://%s:%d - is it running?", - argv.Protocol, argv.Host, argv.Port) + msg = fmt.Sprintf("Unable to connect to rqlited at %s - is it running?", + connectionStr) } ctx.String("%s %v\n", ctx.Color().Red("ERR!"), msg) return nil } - fmt.Println("Welcome to the rqlite CLI. Enter \".help\" for usage hints.") - fmt.Printf("Version %s, commit %s, branch %s\n", cmd.Version, cmd.Commit, cmd.Branch) - fmt.Printf("Connected to rqlited version %s\n", version) + fmt.Println("Welcome to the rqlite CLI.") + fmt.Printf("Enter \".help\" for usage hints.\n") + fmt.Printf("Connected to %s running version %s\n", connectionStr, version) timer := false consistency := "weak" From b4893ab4877c8f13a95161b8a16b9ab09afeb70d Mon Sep 17 00:00:00 2001 From: Philip O'Toole Date: Mon, 11 Dec 2023 21:31:49 -0500 Subject: [PATCH 7/7] CHANGELOG --- CHANGELOG.md | 1 + 1 file changed, 1 insertion(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index 06bf4bb9..55c69524 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -2,6 +2,7 @@ ### Implementation changes and bug fixes - [PR #1471](https://github.com/rqlite/rqlite/pull/1471), [PR #1472](https://github.com/rqlite/rqlite/pull/1472): Refactor query parameters into own code. - [PR #1473](https://github.com/rqlite/rqlite/pull/1471): `go mod` updates. +- [PR #1475](https://github.com/rqlite/rqlite/pull/1475): Minor rqlite CLI improvements. ## 8.0.3 (December 11th 2023) ### Implementation changes and bug fixes