Laszlo and Koushik, Thank you for your replies. I completely agree that the HV-specific code should be moved into the actual HV code. I'd like to see this feature added at some point, and I may even begin to work on it myself.
I was also curious if this was already being looked into by anyone, and if the other types that have similar type-specific code were being phased out and moved to a more plugin-friendly format as well. Sam On Thu, Apr 24, 2014 at 11:12 PM, Koushik Das <[email protected]>wrote: > 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 <[email protected]> > 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 <[email protected]> > 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 > >
