Github user pdion891 commented on the issue:
https://github.com/apache/cloudstack/pull/1684
I've re-perform my upgrade test this morning with this PR, I just add to
change ``dynamic.apichecker.enabled`` value have the authentication working, so
nothing else have to change.
As @PaulAngus raised, in an upgrade scenario where the management-server is
build for scratch to perform a cloud upgrade, ``dynamic.apichecker.enabled``
will cause issues and headache.
So to me it would make more sense if during and upgrade the value of
``dynamic.apichecker.enabled`` is automatically set to "true" which is already
the value of a new deployment, then we should update the release notes so if
users have customized the ``commands.properties`` file, it's up to them to
rollback ``dynamic.apichecker.enabled`` to false and make sure they have a copy
of the commands.properties file. what do you think @PaulAngus ?
Maybe the ideal scenario would be that if the ``commands.properties`` file
exist, cloudstack during is upgrade phase when it's started would update is
dynamic apichecker values to those defined in the commands.properties
Does this should go in this PR or we consider this PR is ok?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
