cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From pdion891 <...@git.apache.org>
Subject [GitHub] cloudstack issue #1684: CLOUDSTACK-9489: the new config vars that are added ...
Date Sat, 01 Oct 2016 14:46:35 GMT
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Mime
View raw message