Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (athena.apache.org: domain of koushik.das@citrix.com
 designates 103.14.252.240 as permitted sender)
From: Koushik Das <koushik.das@citrix.com>
To: "<dev@cloudstack.apache.org>" <dev@cloudstack.apache.org>
Subject: Re: HypervisorType - possible feature idea
Thread-Topic: HypervisorType - possible feature idea
Thread-Index: AQHPX//8+hzIBMALE0y6n7Imef30iJsgvycAgABz+AA=
Date: Fri, 25 Apr 2014 04:12:43 +0000
Message-ID: <B551D223-5943-45B3-BDCE-CE6D2FE58B0E@citrix.com>
References: 
 <CAEdis58nswhJqTUEvn5E7b=LLO6V+qPHjSDu3K_rBWD0_jjB8g@mail.gmail.com>
 <CAKRHFXWeitX_0-V0LM7pVvrPpAbOCJaWmn6r_gCwK2hk-YprFw@mail.gmail.com>
In-Reply-To: 
 <CAKRHFXWeitX_0-V0LM7pVvrPpAbOCJaWmn6r_gCwK2hk-YprFw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-ID: <DB5B015EABB57B42B5A0DD73DCFB6755@citrix.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Ideally the API and orchestration layers shouldn't have any HV specific cod=
e.

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.hornyak@gmail.com> wrote=
:

> Hi Sam,
>=20
> 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 t=
he
> Hypervisor interface would grow big to support all these cases.
>=20
> There are 1097 references to HypervisorType according to eclipse.
>=20
>=20
> On Thu, Apr 24, 2014 at 10:57 PM, Sam Schmit <sam.schmit@appcore.com> wro=
te:
>=20
>> Hello everyone,
>>=20
>> 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 mak=
e
>> it more dynamic - have hypervisors be a pluggable type so that any
>> hypervisor can be added using the Cloudstack plugin architecture.
>>=20
>> 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 f=
or.
>>=20
>> Is there a reason it's done this way, instead of generating a dynamic li=
st
>> 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 suc=
h
>> an undertaking would reside?
>>=20
>> Thanks for any thoughts on this, and I look forward to working with
>> everyone in the near future.
>>=20
>> Sam Schmit
>>=20
>=20
>=20
>=20
> --=20
>=20
> EOF