HypervisorType - possible feature idea

[Sam Schmit <sa...@appcore.com>]

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

Re: HypervisorType - possible feature idea

[Sam Schmit <sa...@appcore.com>]

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 <ko...@citrix.com>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 <la...@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 <sa...@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
>
>

Re: HypervisorType - possible feature idea

[Koushik Das <ko...@citrix.com>]

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 <la...@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 <sa...@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

Re: HypervisorType - possible feature idea

[Laszlo Hornyak <la...@gmail.com>]

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 <sa...@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