mlsorensen commented on PR #7692: URL: https://github.com/apache/cloudstack/pull/7692#issuecomment-1651995819
> @nvazquez, could you explain the use case for this change? Also, there are a lot of changes being applied and none information/explanation; could you draft a workflow or specification about the changes, like it was done in #5124, #5891, #5935, #7369, #7654, and so on? It looks like it brings the hypervisor more in line with the network and storage plug-ability in CloudStack. It's not exact, but for example today a user can provide their own network implementation by simply implementing the NetworkElement and NetworkGuru interfaces, and ensuring their jar is in the classpath. This can't easily be done today with hypervisor since it's controlled by an enum. I don't think this is changing the workflow, it just makes the enum defining the hypervisor types CloudStack understands a bit more flexible. Almost every part of this change is about updating the handling of the enum, not changing how VMs get placed or processed, anything of that nature. If users have a site-specific hypervisor implementation, or want to experiment with building an alternative agent for existing hypervisor without disrupting the built-in, this change would enable them to control it through CloudStack. It would be on the site owner to implement the custom hypervisor how they see fit, but CloudStack would send all of the regular agent commands - StartCommand, StopCommand, etc to nodes registered as this "Custom" type. -- 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: commits-unsubscr...@cloudstack.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
