Ideally the API and orchestration layers shouldn't have any HV specific code.
You may have already seen that there are places in the code which checks if an operation is supported based on HV type like below. if (Vmware) throw ex All these checks should rely on hypervisor_capabilities table instead. Then there is another kind where based on HV type the logic differs. if (XS) foo() else bar() These kind of code needs to go to the plugin module specific to HV. Some of these may be simple but for the rest you need to be careful not to break anything. On 25-Apr-2014, at 2:47 AM, Laszlo Hornyak <laszlo.horn...@gmail.com> wrote: > Hi Sam, > > I think it would take a big lot of work but the direction is nice. > A lot of classes would have to be modified to be plugable, and possibly the > Hypervisor interface would grow big to support all these cases. > > There are 1097 references to HypervisorType according to eclipse. > > > On Thu, Apr 24, 2014 at 10:57 PM, Sam Schmit <sam.sch...@appcore.com> wrote: > >> Hello everyone, >> >> I've recently started working with Cloudstack, and was going through the >> codebase and had a question about a possible feature for future versions - >> making the HypervisorType more dynamic. Right now, it seems there are >> several places where specific types are referenced. I would like to make >> it more dynamic - have hypervisors be a pluggable type so that any >> hypervisor can be added using the Cloudstack plugin architecture. >> >> I've taken a look at the existing code, and it seems as though the enum is >> used not just by the hypervisor's "discoverer" class, but also by other >> classes/methods to say which hypervisors they work with or are looking for. >> >> Is there a reason it's done this way, instead of generating a dynamic list >> of hypervisors that are supported at run-time? Have there been attempts to >> make this change in the past? Has anyone begun work on this feature >> already? Anyone have thoughts on where the easy/difficult areas for such >> an undertaking would reside? >> >> Thanks for any thoughts on this, and I look forward to working with >> everyone in the near future. >> >> Sam Schmit >> > > > > -- > > EOF
