You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As of release 0.8.1, we are making upgrades automatic. When you deploy a version of ACA-Py (as stated in version.py) that is higher than what is stored in the ACA-Py secure storage database, an upgrade is automatically run, based on the contents of the Upgrade Definition YML file. However, in some cases, an upgrade may be particularly risky, and we want to make sure it is run only offline. For example, if the upgrade has side effects that it must only run exactly once, we don't want to an automated upgrade in a Kubernetes environment where the upgrade might be run more than once.
To prevent that, please add a parameter that is optional but that can be added to YML upgrade definitions that prevents an "auto-update". I think there should be two flavours of the parameter -- one that triggers and error and stops the operation, and one that triggers only an entry in the log and continues with processing. The "error and stop" can be used when the upgrade MUST be run before the new version can be deployed. The "log" can be used when the upgrade must be run offline, but is not needed for the new version to be run. In the latter case, the version in storage MUST NOT be updated to the new current ACA-Py version -- it needs to be left as is.
The text was updated successfully, but these errors were encountered:
As of release 0.8.1, we are making upgrades automatic. When you deploy a version of ACA-Py (as stated in
version.py
) that is higher than what is stored in the ACA-Py secure storage database, an upgrade is automatically run, based on the contents of the Upgrade Definition YML file. However, in some cases, an upgrade may be particularly risky, and we want to make sure it is run only offline. For example, if the upgrade has side effects that it must only run exactly once, we don't want to an automated upgrade in a Kubernetes environment where the upgrade might be run more than once.To prevent that, please add a parameter that is optional but that can be added to YML upgrade definitions that prevents an "auto-update". I think there should be two flavours of the parameter -- one that triggers and error and stops the operation, and one that triggers only an entry in the log and continues with processing. The "error and stop" can be used when the upgrade MUST be run before the new version can be deployed. The "log" can be used when the upgrade must be run offline, but is not needed for the new version to be run. In the latter case, the version in storage MUST NOT be updated to the new current ACA-Py version -- it needs to be left as is.
The text was updated successfully, but these errors were encountered: