JoaoJandre commented on PR #7808: URL: https://github.com/apache/cloudstack/pull/7808#issuecomment-1690423024
Sorry for the delayed response @dahn, I somehow missed the notification. I am against reverting #6420, as was explained there, keeping system VMs without CPU usage limits opens up space for different types of infrastructure attacks/misuses. Also, bugs like the ones fixed on #7826 and #6970 will affect much more the Cloud without a CPU cap on CPVMs, for example. The problem reported by @rohityadavcloud, where system VMs fail to start, is caused by another situation. When a system VM is provisioned, ACS sends commands to the system VM to generate the CSR and subsequently generate the certificate; these commands have a timeout of 60 seconds (hardcoded). When the CPU cap is enabled for the system VMs, the request and certificate generation procedures can take more than 60 seconds each to complete, causing a timeout in the execution of the commands and the non-provisioning of certificates for the system VMs. Thus, generating a handshake failure when the `ca.plugin.root.auth.strictness setting is true`. This config should be externalized. Also, I agree with @harikrishna-patnala, if the system VMs are too slow, you could just create new system offerings and use them. But the default offerings should protect users from attacks and possible bugs or misuses like the ones mentioned. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
