bwsw edited a comment on issue #3839: FEATURE-3823: kvm agent hooks URL: https://github.com/apache/cloudstack/pull/3839#issuecomment-585549981 @DaanHoogland @rhtyd @nvazquez Hi, the XML functionality is similar but differs very much. Read that discussion: https://github.com/apache/cloudstack/issues/3823 It may look similar in the way it acts, but completely different from the perspective of the ISP operation, especially for public cloud. This PR allows extending CS at a scale beyond the CS functionality implemented in the system. Your PR allows users adding the options to XML. E.g. Case1. In your PR there is no way to select *any* of the available NVME drives installed in the platform during VM deployment and attach it to the VM using some advanced logic. Case2. when VM is deployed, for every CS account, I create VXLAN unmanaged by CS. I create a bridge and would like to add a NIC into configuration dynamically. It's impossible to implement with your PR. Case 3. I would like to find any of available Quadro RTX 4000 GPU and pass it into VM. Case 4. Read Sakari Poussa's request from mailing list: ``` Thanks for the information. It was useful. Let me elaborate by use cases a bit more. I have PCI host devices with sriov capabilities. I may have 48 virtual functions (VF) on a host. I want to assign the VFs to some VM but not all. So I need some control which VMs gets the VF and others don't. Also, I need to keep track which VFs are already assigned and which are free. Lastly, I want to expose the VFs to containers running on VMs created by the upcoming Cloudstack Kubernetes Service (AKS, pull #3680). Looking at the first feature you mentioned, I don't think I can use that. It has no control on which VMs to add the extraconfig. It is all or nothing. The second feature, which you started to work on seems to have more potential. Do you see it can support my use case? Thanks, Sakari ``` None of those cases are possible with PR you mention. To sum up: * My PR is for public cloud operators, who percept CS as a constructor; * Your PR is for private cloud operators who percept CS as a final system. The PR is ready to be merged from my point of view. I suppose It's better to merge it to avoid diff accumulation.
---------------------------------------------------------------- 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: us...@infra.apache.org With regards, Apache Git Services
