cloudstack-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GitBox <...@apache.org>
Subject [GitHub] [cloudstack] GabrielBrascher commented on a change in pull request #3600: Allow deploy Admin/System VMs in disabled zones/pods/clusters
Date Fri, 20 Sep 2019 10:11:03 GMT
GabrielBrascher commented on a change in pull request #3600: Allow deploy Admin/System VMs
in disabled zones/pods/clusters
URL: https://github.com/apache/cloudstack/pull/3600#discussion_r326562423
 
 

 ##########
 File path: engine/components-api/src/main/java/com/cloud/deploy/DeploymentPlanningManager.java
 ##########
 @@ -24,6 +26,12 @@
 
 public interface DeploymentPlanningManager extends Manager {
 
+    static final ConfigKey<Boolean> allowSytemVmInDisabledResource = new ConfigKey<Boolean>("Advanced",
Boolean.class, "allow.system.vm.disabled.resource", "true",
+            "Allow deploying System VMs in disabled Clusters, Pods, and Zones (does not require
restart)", true);
+
+    static final ConfigKey<Boolean> allowAdminVmInDisabledResource = new ConfigKey<Boolean>("Advanced",
Boolean.class, "allow.admin.vm.disabled.resources", "false",
 
 Review comment:
   @rhtyd I see your point. I understand that we need to avoid such surprises when upgrading.
Do you know a way to update it without surprising users? I ask this because, from my perspective,
such parameter should be set to true as default for system VMs.
   
   Just to provide some context on why this PR has been created. These changes are tackling
an issue regarding cases as the following:
   
   1. each pod requires a VR for a network 'A';
   2. network 'A' has been restarted and all VRs of that network have been re-deployed;
   3. VRs fail to be deployed on disabled Pods (that still running production VMs);
   4. network restarting fails for disabled Pods and cannot update network configurations
that we had expected to be updated on the VR.
   5. production VMs running on disabled Pods have no longer the VR services.
   
   The idea is that we should, by default, keep deploying such VMs to provide all the services
also for legacy environments.
   
   I see a disabled resource as a legacy environment where one shall not deploy new production
VMs; however, such an environment still need to provide the basic services for VMs that have
not been destroyed/migrated. Thus, system VMs (CCPVM, SSVM, VRs) are still necessary to be
deployed/re-deployed to keep serving the VMs that have not yet been migrated from the disabled
resource.
   
   Said that, if you still think that this should be set to false by default, I can add info
at error messages that point to this parameter when system VMs are not deployed on disable
resources. At least making the user/admin aware of this option.

----------------------------------------------------------------
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.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

Mime
View raw message