You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@accumulo.apache.org by "dlmarion (via GitHub)" <gi...@apache.org> on 2025/04/18 14:14:03 UTC
[PR] Updated upgrade documentation for new upgrade process. [accumulo-website]
dlmarion opened a new pull request, #456:
URL: https://github.com/apache/accumulo-website/pull/456
Closes #455
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Updated upgrade documentation for new upgrade process. [accumulo-website]
Posted by "ctubbsii (via GitHub)" <gi...@apache.org>.
ctubbsii commented on PR #456:
URL: https://github.com/apache/accumulo-website/pull/456#issuecomment-2822554495
This seems very verbose. Can this be made more succinct, focusing on the things the user should do, and why, rather than the explanation about the reasons behind the changes on the developer side? It just seems like this might be too developer-centric, documenting the design decisions behind the changeset, rather than user-facing, documenting what to do in order to complete a smooth upgrade.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Updated upgrade documentation for new upgrade process. [accumulo-website]
Posted by "dlmarion (via GitHub)" <gi...@apache.org>.
dlmarion commented on code in PR #456:
URL: https://github.com/apache/accumulo-website/pull/456#discussion_r2052820339
##########
_docs-2/administration/upgrading.md:
##########
@@ -4,6 +4,48 @@ category: administration
order: 7
---
+## Changes to the upgrade process
+
+In upgrade notes for prior releases we have advised that users should ensure that no FATE
+transactions exist (see `Upgrading from 1.10 or 2.0 to 2.1` below). This is due to the
+fact that the internal serialization of FATE transactions is not guaranteed to be
+compatible between versions. Accumulo never provided any tooling around the upgrade process
+and left it up the user, which can cause problems if older versions of FATE transactions
+exist and the user already deployed the new version of software. The user would have to
+re-install the old version of software to remove the FATE transactions.
+
+Starting with Accumulo 4.0 we are modifying the upgrade process steps in an attempt to
+make it easier for the user to validate their instance is ready for upgrade. In earlier
+versions the upgrade process would start when the user started the instance with the
+new version of software. The process ran entirely in the Manager and it was the users
+responsibility to read the upgrade notes to perform any necessary pre-upgrade steps.
+
+The new upgrade process introduces a new `accumulo upgrade` command which will be used
Review Comment:
Starting with `4.0` it will be, the user will have to run `accumulo upgrade --start` before they start the Manager.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Updated upgrade documentation for new upgrade process. [accumulo-website]
Posted by "dlmarion (via GitHub)" <gi...@apache.org>.
dlmarion commented on code in PR #456:
URL: https://github.com/apache/accumulo-website/pull/456#discussion_r2052822986
##########
_docs-2/administration/upgrading.md:
##########
@@ -4,6 +4,48 @@ category: administration
order: 7
---
+## Changes to the upgrade process
+
+In upgrade notes for prior releases we have advised that users should ensure that no FATE
+transactions exist (see `Upgrading from 1.10 or 2.0 to 2.1` below). This is due to the
+fact that the internal serialization of FATE transactions is not guaranteed to be
+compatible between versions. Accumulo never provided any tooling around the upgrade process
+and left it up the user, which can cause problems if older versions of FATE transactions
+exist and the user already deployed the new version of software. The user would have to
+re-install the old version of software to remove the FATE transactions.
+
+Starting with Accumulo 4.0 we are modifying the upgrade process steps in an attempt to
+make it easier for the user to validate their instance is ready for upgrade. In earlier
+versions the upgrade process would start when the user started the instance with the
+new version of software. The process ran entirely in the Manager and it was the users
+responsibility to read the upgrade notes to perform any necessary pre-upgrade steps.
+
+The new upgrade process introduces a new `accumulo upgrade` command which will be used
+after shutting down the instance with the old version of software and before starting
+the instance with the new version of software. The `upgrade` command has two options,
+`--prepare` and `--start`. `--prepare` is designed to be executed by the user after shutting
+down the instance. This option will check that the Manager is down, validate that there
+are no existing FATE transactions, remove all of the server locks in ZooKeeper, and place
+a node in ZooKeeper that will prevent server processes from being started again. If there
Review Comment:
The node created by `--prepare` just prevents the server processes from starting. If the user decides to abort the upgrade, then they can manually delete this node. These instructions are provided if there are fate transactions. I point this out to say that completing the upgrade is not necessarily the only way to start the server processes again.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Updated upgrade documentation for new upgrade process. [accumulo-website]
Posted by "dlmarion (via GitHub)" <gi...@apache.org>.
dlmarion merged PR #456:
URL: https://github.com/apache/accumulo-website/pull/456
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Updated upgrade documentation for new upgrade process. [accumulo-website]
Posted by "dlmarion (via GitHub)" <gi...@apache.org>.
dlmarion commented on code in PR #456:
URL: https://github.com/apache/accumulo-website/pull/456#discussion_r2052823766
##########
_docs-2/administration/upgrading.md:
##########
@@ -4,6 +4,48 @@ category: administration
order: 7
---
+## Changes to the upgrade process
+
+In upgrade notes for prior releases we have advised that users should ensure that no FATE
+transactions exist (see `Upgrading from 1.10 or 2.0 to 2.1` below). This is due to the
+fact that the internal serialization of FATE transactions is not guaranteed to be
+compatible between versions. Accumulo never provided any tooling around the upgrade process
+and left it up the user, which can cause problems if older versions of FATE transactions
+exist and the user already deployed the new version of software. The user would have to
+re-install the old version of software to remove the FATE transactions.
+
+Starting with Accumulo 4.0 we are modifying the upgrade process steps in an attempt to
+make it easier for the user to validate their instance is ready for upgrade. In earlier
+versions the upgrade process would start when the user started the instance with the
+new version of software. The process ran entirely in the Manager and it was the users
+responsibility to read the upgrade notes to perform any necessary pre-upgrade steps.
+
+The new upgrade process introduces a new `accumulo upgrade` command which will be used
+after shutting down the instance with the old version of software and before starting
+the instance with the new version of software. The `upgrade` command has two options,
+`--prepare` and `--start`. `--prepare` is designed to be executed by the user after shutting
+down the instance. This option will check that the Manager is down, validate that there
+are no existing FATE transactions, remove all of the server locks in ZooKeeper, and place
+a node in ZooKeeper that will prevent server processes from being started again. If there
+are FATE transactions, the command will fail giving the user the opportunity to clean them
+up. The `--prepare` option can then be run again.
+
+The `--start` option is designed to be executed by the user before starting the instance
Review Comment:
Running `--prepare` with the old version of code is certainly preferred.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Updated upgrade documentation for new upgrade process. [accumulo-website]
Posted by "DomGarguilo (via GitHub)" <gi...@apache.org>.
DomGarguilo commented on code in PR #456:
URL: https://github.com/apache/accumulo-website/pull/456#discussion_r2051131784
##########
_docs-2/administration/upgrading.md:
##########
@@ -4,6 +4,48 @@ category: administration
order: 7
---
+## Changes to the upgrade process
+
+In upgrade notes for prior releases we have advised that users should ensure that no FATE
+transactions exist (see `Upgrading from 1.10 or 2.0 to 2.1` below). This is due to the
+fact that the internal serialization of FATE transactions is not guaranteed to be
+compatible between versions. Accumulo never provided any tooling around the upgrade process
+and left it up the user, which can cause problems if older versions of FATE transactions
+exist and the user already deployed the new version of software. The user would have to
+re-install the old version of software to remove the FATE transactions.
+
+Starting with Accumulo 4.0 we are modifying the upgrade process steps in an attempt to
+make it easier for the user to validate their instance is ready for upgrade. In earlier
+versions the upgrade process would start when the user started the instance with the
+new version of software. The process ran entirely in the Manager and it was the users
+responsibility to read the upgrade notes to perform any necessary pre-upgrade steps.
+
+The new upgrade process introduces a new `accumulo upgrade` command which will be used
+after shutting down the instance with the old version of software and before starting
+the instance with the new version of software. The `upgrade` command has two options,
+`--prepare` and `--start`. `--prepare` is designed to be executed by the user after shutting
+down the instance. This option will check that the Manager is down, validate that there
+are no existing FATE transactions, remove all of the server locks in ZooKeeper, and place
+a node in ZooKeeper that will prevent server processes from being started again. If there
+are FATE transactions, the command will fail giving the user the opportunity to clean them
+up. The `--prepare` option can then be run again.
+
+The `--start` option is designed to be executed by the user before starting the instance
Review Comment:
```suggestion
The `--start` option is designed to be executed by the user before starting the instance (and after running the `--prepare` step)
```
I'm not too sure if this should be included since we say below that its not absolutely necessary for `--prepare` to be run
##########
_docs-2/administration/upgrading.md:
##########
@@ -4,6 +4,48 @@ category: administration
order: 7
---
+## Changes to the upgrade process
+
+In upgrade notes for prior releases we have advised that users should ensure that no FATE
+transactions exist (see `Upgrading from 1.10 or 2.0 to 2.1` below). This is due to the
+fact that the internal serialization of FATE transactions is not guaranteed to be
+compatible between versions. Accumulo never provided any tooling around the upgrade process
+and left it up the user, which can cause problems if older versions of FATE transactions
+exist and the user already deployed the new version of software. The user would have to
+re-install the old version of software to remove the FATE transactions.
+
+Starting with Accumulo 4.0 we are modifying the upgrade process steps in an attempt to
+make it easier for the user to validate their instance is ready for upgrade. In earlier
+versions the upgrade process would start when the user started the instance with the
+new version of software. The process ran entirely in the Manager and it was the users
+responsibility to read the upgrade notes to perform any necessary pre-upgrade steps.
+
+The new upgrade process introduces a new `accumulo upgrade` command which will be used
+after shutting down the instance with the old version of software and before starting
+the instance with the new version of software. The `upgrade` command has two options,
+`--prepare` and `--start`. `--prepare` is designed to be executed by the user after shutting
+down the instance. This option will check that the Manager is down, validate that there
+are no existing FATE transactions, remove all of the server locks in ZooKeeper, and place
+a node in ZooKeeper that will prevent server processes from being started again. If there
Review Comment:
```suggestion
a node in ZooKeeper that will prevent server processes from being started again before the upgrade is complete. If there
```
##########
_docs-2/administration/upgrading.md:
##########
@@ -4,6 +4,48 @@ category: administration
order: 7
---
+## Changes to the upgrade process
+
+In upgrade notes for prior releases we have advised that users should ensure that no FATE
+transactions exist (see `Upgrading from 1.10 or 2.0 to 2.1` below). This is due to the
+fact that the internal serialization of FATE transactions is not guaranteed to be
+compatible between versions. Accumulo never provided any tooling around the upgrade process
+and left it up the user, which can cause problems if older versions of FATE transactions
+exist and the user already deployed the new version of software. The user would have to
+re-install the old version of software to remove the FATE transactions.
+
+Starting with Accumulo 4.0 we are modifying the upgrade process steps in an attempt to
+make it easier for the user to validate their instance is ready for upgrade. In earlier
+versions the upgrade process would start when the user started the instance with the
+new version of software. The process ran entirely in the Manager and it was the users
+responsibility to read the upgrade notes to perform any necessary pre-upgrade steps.
+
+The new upgrade process introduces a new `accumulo upgrade` command which will be used
Review Comment:
"will be used"
Would "should be" or "needs to be" fit better here?
##########
_docs-2/administration/upgrading.md:
##########
@@ -4,6 +4,48 @@ category: administration
order: 7
---
+## Changes to the upgrade process
+
+In upgrade notes for prior releases we have advised that users should ensure that no FATE
+transactions exist (see `Upgrading from 1.10 or 2.0 to 2.1` below). This is due to the
+fact that the internal serialization of FATE transactions is not guaranteed to be
+compatible between versions. Accumulo never provided any tooling around the upgrade process
+and left it up the user, which can cause problems if older versions of FATE transactions
+exist and the user already deployed the new version of software. The user would have to
+re-install the old version of software to remove the FATE transactions.
+
+Starting with Accumulo 4.0 we are modifying the upgrade process steps in an attempt to
+make it easier for the user to validate their instance is ready for upgrade. In earlier
+versions the upgrade process would start when the user started the instance with the
+new version of software. The process ran entirely in the Manager and it was the users
+responsibility to read the upgrade notes to perform any necessary pre-upgrade steps.
+
+The new upgrade process introduces a new `accumulo upgrade` command which will be used
+after shutting down the instance with the old version of software and before starting
+the instance with the new version of software. The `upgrade` command has two options,
+`--prepare` and `--start`. `--prepare` is designed to be executed by the user after shutting
+down the instance. This option will check that the Manager is down, validate that there
+are no existing FATE transactions, remove all of the server locks in ZooKeeper, and place
+a node in ZooKeeper that will prevent server processes from being started again. If there
+are FATE transactions, the command will fail giving the user the opportunity to clean them
+up. The `--prepare` option can then be run again.
+
+The `--start` option is designed to be executed by the user before starting the instance
+with the newer version of software. The `--start` option will perform any necessary pre-upgrade
+validation, any changes that are necessary for the new version of software to start, seed
Review Comment:
```suggestion
validation, make any changes that are necessary for the new version of software to start, seed
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org