Re: [DISCUSS] Config Drive: Using the OpenStack format?

[Kris Sterckx]

FYI

Slides are here :
https://www.slideshare.net/2000monkeys/apache-cloudstack-collab-miami-user-data-alternatives-to-the-vr

Thanks

- Kris

On 19 May 2017 at 12:58, Wei ZHOU  wrote:

> gd idea
>
> 2017-05-19 15:33 GMT+02:00 Marc-Aurèle Brothier :
>
> > Hi Widoo,
> >
> > That sounds like a pretty good idea in my opinion. +1 for adding it
> >
> > Marco
> >
> >
> > > On 19 May 2017, at 15:15, Wido den Hollander  wrote:
> > >
> > > Hi,
> > >
> > > Yesterday at ApacheCon Kris from Nuage networks gave a great
> > presentation about alternatives for userdata from the VR: Config Drive
> > >
> > > In short, a CD-ROM/ISO attached to the Instance containing the
> > meta/userdata instead of having the VR serve it.
> > >
> > > The outstanding PR [0] uses it's own format on the ISO while cloud-init
> > already has support for config drive [1].
> > >
> > > This format uses 'openstack' in the name, but it seems to be in
> > cloud-init natively and well supported.
> > >
> > > I started the discussion yesterday during the talk and thought to take
> > it to the list.
> > >
> > > My opinion is that we should use the OpenStack format for the config
> > drive:
> > >
> > > - It's already in cloud-init
> > > - Easier to templates to be used on CloudStack
> > > - Easier adoption
> > >
> > > We can always write a file like "GENERATED_BY_APACHE_CLOUDSTACK" or
> > something on the ISO.
> > >
> > > We can also symlink the 'openstack' directory to a directory called
> > 'cloudstack' on the ISO.
> > >
> > > Does anybody else have a opinion on this one?
> > >
> > > Wido
> > >
> > > [0]: https://github.com/apache/cloudstack/pull/2097
> > > [1]: http://cloudinit.readthedocs.io/en/latest/topics/
> > datasources/configdrive.html#version-2
> >
> >
>

Re: Extend CloudStack for a new hypervisor

[Tessema Mindaye]

I have a similar question. I want to use VirtualBox for a project that I
have. And to the best of my knowledge, cloudstack doesn't support type II
hypervisors like VirtualBox. What should I do to support VirtualBox in
CloudStack.

Regards,

On Thu, May 18, 2017 at 5:06 PM, Simon Weller 
wrote:

> Which hypervisor are you wanting to implement​?
>
> Simon Weller/615-312-6068
>
> -Original Message-
> From: John Smith [john.smith@gmail.com]
> Received: Thursday, 18 May 2017, 5:29PM
> To: dev@cloudstack.apache.org [dev@cloudstack.apache.org]
> Subject: Extend CloudStack for a new hypervisor
>
> Greetings!
>
> I have a need to extend CloudStack to support an additional hypervisor.
> This is not something I consider strategic for CloudStack itself, but I
> have a project with a very specific need.
>
> I have a development background but am not an active developer right now
> ... so looking forward to getting back in the saddle!  I've never developed
> against the CloudStack tree before.
>
> I can't find any docs on how one would introduce support for a new
> hypervisor (eg. what classes, methods, etc, need to be implemented,
> extended, etc) and checking the source tree I can't easily see if there is
> a base to build from.  I would appreciate any pointers about where to start
> looking to save me going through the entire tree from scratch.
>
> The standard CloudStack concepts should be easy enough (ha!) to map 1:1 to
> this additional hypervisor (including primary & secondary storage, router &
> secondary storage VMs, the networking concepts, etc) so I'm hoping that I
> can simply implement it like a VMware or Xen backend ...
>
> Thanks in advance!
>
> John.
>



-- 
Tessema Mindaye Mengistu
Teaching Assistant and PhD Student
Department of Computer Science
Southern Illinois University, IL, USA

Tel:  (mob) +618-303-4788
E-mail: tessem a.mengi...@siu.edu

Re: [DISCUSS] Config Drive: Using the OpenStack format?

[David Mabry]

+1.  I like it!

On 5/19/17, 11:58 AM, "Wei ZHOU"  wrote:

gd idea

2017-05-19 15:33 GMT+02:00 Marc-Aurèle Brothier :

> Hi Widoo,
>
> That sounds like a pretty good idea in my opinion. +1 for adding it
>
> Marco
>
>
> > On 19 May 2017, at 15:15, Wido den Hollander  wrote:
> >
> > Hi,
> >
> > Yesterday at ApacheCon Kris from Nuage networks gave a great
> presentation about alternatives for userdata from the VR: Config Drive
> >
> > In short, a CD-ROM/ISO attached to the Instance containing the
> meta/userdata instead of having the VR serve it.
> >
> > The outstanding PR [0] uses it's own format on the ISO while cloud-init
> already has support for config drive [1].
> >
> > This format uses 'openstack' in the name, but it seems to be in
> cloud-init natively and well supported.
> >
> > I started the discussion yesterday during the talk and thought to take
> it to the list.
> >
> > My opinion is that we should use the OpenStack format for the config
> drive:
> >
> > - It's already in cloud-init
> > - Easier to templates to be used on CloudStack
> > - Easier adoption
> >
> > We can always write a file like "GENERATED_BY_APACHE_CLOUDSTACK" or
> something on the ISO.
> >
> > We can also symlink the 'openstack' directory to a directory called
> 'cloudstack' on the ISO.
> >
> > Does anybody else have a opinion on this one?
> >
> > Wido
> >
> > [0]: https://github.com/apache/cloudstack/pull/2097
> > [1]: http://cloudinit.readthedocs.io/en/latest/topics/
> datasources/configdrive.html#version-2
>
>

Re: Extend CloudStack for a new hypervisor

[Rafael Weingärtner]

I wonder how you plan to present the OpenStack environment to CloudStack; a
huge host with lots of resources? Or, do you intend to present all of the
clusters and hosts that the OpenStack system may have?



I think you would be better with a direct attach solution; meaning,
CloudStack calling directly the API of OpenStack to execute its job. I
think system VMs might be a little tricky to handle, but let´s wait to see
what you come up with. When you have a draft of a development proposal,
please count on us to discuss this further. Have Fun ;)


Side note; are you able to share a bit more details for such necessity?



On Fri, May 19, 2017 at 8:29 AM, Daan Hoogland 
wrote:

> John, I never implemented one but I am about to investigate the ovm3 one
> to see if I can maintain it for a customer. I know the guy that wrote it
> and he says it’s fairly simple given the constraint of a hypervisor plugin,
> so I’d have a look at that one if I where you.
>
> Important thing to consider is the agent concept, most hypervisors have
> directly attached agents, i.e. running in the management server. You might
> not want that and have a look at KVM as well (hyperv as alternative but
> that one is the odd man out)
>
> This btw sounds like a strategic direction, but indeed not for cloudstack.
>
> Hope to hear a lot about your progress ;)
>
> On 19/05/2017, 13:36, "Erik Weber"  wrote:
> I can already hear the slogan in my head "CloudStack - making
> OpenStack great again" :-p
>
> On Fri, May 19, 2017 at 12:57 PM, John Smith 
> wrote:
> > Ok...so bear with me on this one.
> >
> > "Hypervisor" was a little white lie.  What I actually want to do is
> > implement OpenStack as a backend for CloudStack (yo dawg, I hear you
> like
> > cloud in your clouds, etc).  I know I can use KVM and OVS as
> backends for
> > CloudStack natively but, as I said, this is for a project with some
> very
> > specific needs...
> >
> > As OpenStack is completely API driven, I see no issues with the
> basics of
> > communication between CS and OS.
> >
> > This would, of course, bypass the OS concept of Linux network
> namespaces
> > for routing and I would implement the CS routing VM as a VM (just
> like in
> > VMware or Xen) connected between an OS tenant network and an OS
> external
> > network.  CS volumes would be OS volumes.  Secondary storage would
> be a VM
> > running NFS.
> >
> > In principle, I see that the CS concepts of compute, network and
> storage
> > could be implemented on OS.  I was hoping that I could basically
> write a
> > "driver" that would do the necessary actions against OS based on
> standard
> > calls to a CS class/method/whatever, based on some assumption that
> the
> > underlying hypervisor in CS was at least some sort of pluggable
> > architecture.
> >
> > Yes, this may sound a little crazy, and I did say this was probably
> not
> > something strategic to the CloudStack direction, but for me it
> actually
> > fits a funny shaped hole I've discovered and I'm interested in at
> least
> > understanding how such a thing could be done.
> >
> > Thanks,
> >
> > John.
> >
> >
> >
> > On Fri, May 19, 2017 at 12:06 AM, Simon Weller
> 
> > wrote:
> >
> >> Which hypervisor are you wanting to implement?
> >>
> >> Simon Weller/615-312-6068
> >>
> >> -Original Message-
> >> From: John Smith [john.smith@gmail.com]
> >> Received: Thursday, 18 May 2017, 5:29PM
> >> To: dev@cloudstack.apache.org [dev@cloudstack.apache.org]
> >> Subject: Extend CloudStack for a new hypervisor
> >>
> >> Greetings!
> >>
> >> I have a need to extend CloudStack to support an additional
> hypervisor.
> >> This is not something I consider strategic for CloudStack itself,
> but I
> >> have a project with a very specific need.
> >>
> >> I have a development background but am not an active developer
> right now
> >> ... so looking forward to getting back in the saddle!  I've never
> developed
> >> against the CloudStack tree before.
> >>
> >> I can't find any docs on how one would introduce support for a new
> >> hypervisor (eg. what classes, methods, etc, need to be implemented,
> >> extended, etc) and checking the source tree I can't easily see if
> there is
> >> a base to build from.  I would appreciate any pointers about where
> to start
> >> looking to save me going through the entire tree from scratch.
> >>
> >> The standard CloudStack concepts should be easy enough (ha!) to map
> 1:1 to
> >> this additional hypervisor (including primary & secondary storage,
> router &
> >> secondary storage VMs, the networking concepts, etc) so I'm hoping
> that I
> >> can simply implement it 

Re: [DISCUSS] Config Drive: Using the OpenStack format?

[Wei ZHOU]

gd idea

2017-05-19 15:33 GMT+02:00 Marc-Aurèle Brothier :

> Hi Widoo,
>
> That sounds like a pretty good idea in my opinion. +1 for adding it
>
> Marco
>
>
> > On 19 May 2017, at 15:15, Wido den Hollander  wrote:
> >
> > Hi,
> >
> > Yesterday at ApacheCon Kris from Nuage networks gave a great
> presentation about alternatives for userdata from the VR: Config Drive
> >
> > In short, a CD-ROM/ISO attached to the Instance containing the
> meta/userdata instead of having the VR serve it.
> >
> > The outstanding PR [0] uses it's own format on the ISO while cloud-init
> already has support for config drive [1].
> >
> > This format uses 'openstack' in the name, but it seems to be in
> cloud-init natively and well supported.
> >
> > I started the discussion yesterday during the talk and thought to take
> it to the list.
> >
> > My opinion is that we should use the OpenStack format for the config
> drive:
> >
> > - It's already in cloud-init
> > - Easier to templates to be used on CloudStack
> > - Easier adoption
> >
> > We can always write a file like "GENERATED_BY_APACHE_CLOUDSTACK" or
> something on the ISO.
> >
> > We can also symlink the 'openstack' directory to a directory called
> 'cloudstack' on the ISO.
> >
> > Does anybody else have a opinion on this one?
> >
> > Wido
> >
> > [0]: https://github.com/apache/cloudstack/pull/2097
> > [1]: http://cloudinit.readthedocs.io/en/latest/topics/
> datasources/configdrive.html#version-2
>
>

RE: [DISCUSS] Config Drive: Using the OpenStack format?

[Kris Sterckx]

Awesome

We ll explore the symlink approach and document a suggested approach in the
design spec for review and upon consensus update the PR.

Thanks Wido!

Kris

On May 19, 2017 11:42, "Simon Weller"  wrote:

> +1
>
> Simon Weller/615-312-6068
>
> -Original Message-
> From: Rafael Weingärtner [rafaelweingart...@gmail.com]
> Received: Friday, 19 May 2017, 11:24AM
> To: dev@cloudstack.apache.org [dev@cloudstack.apache.org]
> Subject: Re: [DISCUSS] Config Drive: Using the OpenStack format?
>
> This seems a very interesting idea.
> +1
>
> On Fri, May 19, 2017 at 9:33 AM, Marc-Aurèle Brothier 
> wrote:
>
> > Hi Widoo,
> >
> > That sounds like a pretty good idea in my opinion. +1 for adding it
> >
> > Marco
> >
> >
> > > On 19 May 2017, at 15:15, Wido den Hollander  wrote:
> > >
> > > Hi,
> > >
> > > Yesterday at ApacheCon Kris from Nuage networks gave a great
> > presentation about alternatives for userdata from the VR: Config Drive
> > >
> > > In short, a CD-ROM/ISO attached to the Instance containing the
> > meta/userdata instead of having the VR serve it.
> > >
> > > The outstanding PR [0] uses it's own format on the ISO while cloud-init
> > already has support for config drive [1].
> > >
> > > This format uses 'openstack' in the name, but it seems to be in
> > cloud-init natively and well supported.
> > >
> > > I started the discussion yesterday during the talk and thought to take
> > it to the list.
> > >
> > > My opinion is that we should use the OpenStack format for the config
> > drive:
> > >
> > > - It's already in cloud-init
> > > - Easier to templates to be used on CloudStack
> > > - Easier adoption
> > >
> > > We can always write a file like "GENERATED_BY_APACHE_CLOUDSTACK" or
> > something on the ISO.
> > >
> > > We can also symlink the 'openstack' directory to a directory called
> > 'cloudstack' on the ISO.
> > >
> > > Does anybody else have a opinion on this one?
> > >
> > > Wido
> > >
> > > [0]: https://github.com/apache/cloudstack/pull/2097
> > > [1]: http://cloudinit.readthedocs.io/en/latest/topics/
> > datasources/configdrive.html#version-2
> >
> >
>
>
> --
> Rafael Weingärtner
>

RE: [DISCUSS] Config Drive: Using the OpenStack format?

[Simon Weller]

+1

Simon Weller/615-312-6068

-Original Message-
From: Rafael Weingärtner [rafaelweingart...@gmail.com]
Received: Friday, 19 May 2017, 11:24AM
To: dev@cloudstack.apache.org [dev@cloudstack.apache.org]
Subject: Re: [DISCUSS] Config Drive: Using the OpenStack format?

This seems a very interesting idea.
+1

On Fri, May 19, 2017 at 9:33 AM, Marc-Aurèle Brothier 
wrote:

> Hi Widoo,
>
> That sounds like a pretty good idea in my opinion. +1 for adding it
>
> Marco
>
>
> > On 19 May 2017, at 15:15, Wido den Hollander  wrote:
> >
> > Hi,
> >
> > Yesterday at ApacheCon Kris from Nuage networks gave a great
> presentation about alternatives for userdata from the VR: Config Drive
> >
> > In short, a CD-ROM/ISO attached to the Instance containing the
> meta/userdata instead of having the VR serve it.
> >
> > The outstanding PR [0] uses it's own format on the ISO while cloud-init
> already has support for config drive [1].
> >
> > This format uses 'openstack' in the name, but it seems to be in
> cloud-init natively and well supported.
> >
> > I started the discussion yesterday during the talk and thought to take
> it to the list.
> >
> > My opinion is that we should use the OpenStack format for the config
> drive:
> >
> > - It's already in cloud-init
> > - Easier to templates to be used on CloudStack
> > - Easier adoption
> >
> > We can always write a file like "GENERATED_BY_APACHE_CLOUDSTACK" or
> something on the ISO.
> >
> > We can also symlink the 'openstack' directory to a directory called
> 'cloudstack' on the ISO.
> >
> > Does anybody else have a opinion on this one?
> >
> > Wido
> >
> > [0]: https://github.com/apache/cloudstack/pull/2097
> > [1]: http://cloudinit.readthedocs.io/en/latest/topics/
> datasources/configdrive.html#version-2
>
>


--
Rafael Weingärtner

Re: [DISCUSS] Config Drive: Using the OpenStack format?

[Rafael Weingärtner]

This seems a very interesting idea.
+1

On Fri, May 19, 2017 at 9:33 AM, Marc-Aurèle Brothier 
wrote:

> Hi Widoo,
>
> That sounds like a pretty good idea in my opinion. +1 for adding it
>
> Marco
>
>
> > On 19 May 2017, at 15:15, Wido den Hollander  wrote:
> >
> > Hi,
> >
> > Yesterday at ApacheCon Kris from Nuage networks gave a great
> presentation about alternatives for userdata from the VR: Config Drive
> >
> > In short, a CD-ROM/ISO attached to the Instance containing the
> meta/userdata instead of having the VR serve it.
> >
> > The outstanding PR [0] uses it's own format on the ISO while cloud-init
> already has support for config drive [1].
> >
> > This format uses 'openstack' in the name, but it seems to be in
> cloud-init natively and well supported.
> >
> > I started the discussion yesterday during the talk and thought to take
> it to the list.
> >
> > My opinion is that we should use the OpenStack format for the config
> drive:
> >
> > - It's already in cloud-init
> > - Easier to templates to be used on CloudStack
> > - Easier adoption
> >
> > We can always write a file like "GENERATED_BY_APACHE_CLOUDSTACK" or
> something on the ISO.
> >
> > We can also symlink the 'openstack' directory to a directory called
> 'cloudstack' on the ISO.
> >
> > Does anybody else have a opinion on this one?
> >
> > Wido
> >
> > [0]: https://github.com/apache/cloudstack/pull/2097
> > [1]: http://cloudinit.readthedocs.io/en/latest/topics/
> datasources/configdrive.html#version-2
>
>


-- 
Rafael Weingärtner

Re: [DISCUSS] Config Drive: Using the OpenStack format?

[Marc-Aurèle Brothier]

Hi Widoo,

That sounds like a pretty good idea in my opinion. +1 for adding it

Marco


> On 19 May 2017, at 15:15, Wido den Hollander  wrote:
> 
> Hi,
> 
> Yesterday at ApacheCon Kris from Nuage networks gave a great presentation 
> about alternatives for userdata from the VR: Config Drive
> 
> In short, a CD-ROM/ISO attached to the Instance containing the meta/userdata 
> instead of having the VR serve it.
> 
> The outstanding PR [0] uses it's own format on the ISO while cloud-init 
> already has support for config drive [1].
> 
> This format uses 'openstack' in the name, but it seems to be in cloud-init 
> natively and well supported.
> 
> I started the discussion yesterday during the talk and thought to take it to 
> the list.
> 
> My opinion is that we should use the OpenStack format for the config drive:
> 
> - It's already in cloud-init
> - Easier to templates to be used on CloudStack
> - Easier adoption
> 
> We can always write a file like "GENERATED_BY_APACHE_CLOUDSTACK" or something 
> on the ISO.
> 
> We can also symlink the 'openstack' directory to a directory called 
> 'cloudstack' on the ISO.
> 
> Does anybody else have a opinion on this one?
> 
> Wido
> 
> [0]: https://github.com/apache/cloudstack/pull/2097
> [1]: 
> http://cloudinit.readthedocs.io/en/latest/topics/datasources/configdrive.html#version-2

[DISCUSS] Config Drive: Using the OpenStack format?

[Wido den Hollander]

Hi,

Yesterday at ApacheCon Kris from Nuage networks gave a great presentation about 
alternatives for userdata from the VR: Config Drive

In short, a CD-ROM/ISO attached to the Instance containing the meta/userdata 
instead of having the VR serve it.

The outstanding PR [0] uses it's own format on the ISO while cloud-init already 
has support for config drive [1].

This format uses 'openstack' in the name, but it seems to be in cloud-init 
natively and well supported.

I started the discussion yesterday during the talk and thought to take it to 
the list.

My opinion is that we should use the OpenStack format for the config drive:

- It's already in cloud-init
- Easier to templates to be used on CloudStack
- Easier adoption

We can always write a file like "GENERATED_BY_APACHE_CLOUDSTACK" or something 
on the ISO.

We can also symlink the 'openstack' directory to a directory called 
'cloudstack' on the ISO.

Does anybody else have a opinion on this one?

Wido

[0]: https://github.com/apache/cloudstack/pull/2097
[1]: 
http://cloudinit.readthedocs.io/en/latest/topics/datasources/configdrive.html#version-2

Re: Extend CloudStack for a new hypervisor

[Daan Hoogland]

John, I never implemented one but I am about to investigate the ovm3 one to see 
if I can maintain it for a customer. I know the guy that wrote it and he says 
it’s fairly simple given the constraint of a hypervisor plugin, so I’d have a 
look at that one if I where you.

Important thing to consider is the agent concept, most hypervisors have 
directly attached agents, i.e. running in the management server. You might not 
want that and have a look at KVM as well (hyperv as alternative but that one is 
the odd man out)

This btw sounds like a strategic direction, but indeed not for cloudstack.

Hope to hear a lot about your progress ;)

On 19/05/2017, 13:36, "Erik Weber"  wrote:
I can already hear the slogan in my head "CloudStack - making
OpenStack great again" :-p

On Fri, May 19, 2017 at 12:57 PM, John Smith  wrote:
> Ok...so bear with me on this one.
>
> "Hypervisor" was a little white lie.  What I actually want to do is
> implement OpenStack as a backend for CloudStack (yo dawg, I hear you like
> cloud in your clouds, etc).  I know I can use KVM and OVS as backends for
> CloudStack natively but, as I said, this is for a project with some very
> specific needs...
>
> As OpenStack is completely API driven, I see no issues with the basics of
> communication between CS and OS.
>
> This would, of course, bypass the OS concept of Linux network namespaces
> for routing and I would implement the CS routing VM as a VM (just like in
> VMware or Xen) connected between an OS tenant network and an OS external
> network.  CS volumes would be OS volumes.  Secondary storage would be a VM
> running NFS.
>
> In principle, I see that the CS concepts of compute, network and storage
> could be implemented on OS.  I was hoping that I could basically write a
> "driver" that would do the necessary actions against OS based on standard
> calls to a CS class/method/whatever, based on some assumption that the
> underlying hypervisor in CS was at least some sort of pluggable
> architecture.
>
> Yes, this may sound a little crazy, and I did say this was probably not
> something strategic to the CloudStack direction, but for me it actually
> fits a funny shaped hole I've discovered and I'm interested in at least
> understanding how such a thing could be done.
>
> Thanks,
>
> John.
>
>
>
> On Fri, May 19, 2017 at 12:06 AM, Simon Weller 
> wrote:
>
>> Which hypervisor are you wanting to implement?
>>
>> Simon Weller/615-312-6068
>>
>> -Original Message-
>> From: John Smith [john.smith@gmail.com]
>> Received: Thursday, 18 May 2017, 5:29PM
>> To: dev@cloudstack.apache.org [dev@cloudstack.apache.org]
>> Subject: Extend CloudStack for a new hypervisor
>>
>> Greetings!
>>
>> I have a need to extend CloudStack to support an additional hypervisor.
>> This is not something I consider strategic for CloudStack itself, but I
>> have a project with a very specific need.
>>
>> I have a development background but am not an active developer right now
>> ... so looking forward to getting back in the saddle!  I've never 
developed
>> against the CloudStack tree before.
>>
>> I can't find any docs on how one would introduce support for a new
>> hypervisor (eg. what classes, methods, etc, need to be implemented,
>> extended, etc) and checking the source tree I can't easily see if there 
is
>> a base to build from.  I would appreciate any pointers about where to 
start
>> looking to save me going through the entire tree from scratch.
>>
>> The standard CloudStack concepts should be easy enough (ha!) to map 1:1 
to
>> this additional hypervisor (including primary & secondary storage, 
router &
>> secondary storage VMs, the networking concepts, etc) so I'm hoping that I
>> can simply implement it like a VMware or Xen backend ...
>>
>> Thanks in advance!
>>
>> John.
>>



daan.hoogl...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 

Re: Extend CloudStack for a new hypervisor

[Erik Weber]

Cool, I like it ;-)

I can already hear the slogan in my head "CloudStack - making
OpenStack great again" :-p

Can't help you with the your actual questions, but best of luck :-)

-- 
Erik

On Fri, May 19, 2017 at 12:57 PM, John Smith  wrote:
> Ok...so bear with me on this one.
>
> "Hypervisor" was a little white lie.  What I actually want to do is
> implement OpenStack as a backend for CloudStack (yo dawg, I hear you like
> cloud in your clouds, etc).  I know I can use KVM and OVS as backends for
> CloudStack natively but, as I said, this is for a project with some very
> specific needs...
>
> As OpenStack is completely API driven, I see no issues with the basics of
> communication between CS and OS.
>
> This would, of course, bypass the OS concept of Linux network namespaces
> for routing and I would implement the CS routing VM as a VM (just like in
> VMware or Xen) connected between an OS tenant network and an OS external
> network.  CS volumes would be OS volumes.  Secondary storage would be a VM
> running NFS.
>
> In principle, I see that the CS concepts of compute, network and storage
> could be implemented on OS.  I was hoping that I could basically write a
> "driver" that would do the necessary actions against OS based on standard
> calls to a CS class/method/whatever, based on some assumption that the
> underlying hypervisor in CS was at least some sort of pluggable
> architecture.
>
> Yes, this may sound a little crazy, and I did say this was probably not
> something strategic to the CloudStack direction, but for me it actually
> fits a funny shaped hole I've discovered and I'm interested in at least
> understanding how such a thing could be done.
>
> Thanks,
>
> John.
>
>
>
> On Fri, May 19, 2017 at 12:06 AM, Simon Weller 
> wrote:
>
>> Which hypervisor are you wanting to implement?
>>
>> Simon Weller/615-312-6068
>>
>> -Original Message-
>> From: John Smith [john.smith@gmail.com]
>> Received: Thursday, 18 May 2017, 5:29PM
>> To: dev@cloudstack.apache.org [dev@cloudstack.apache.org]
>> Subject: Extend CloudStack for a new hypervisor
>>
>> Greetings!
>>
>> I have a need to extend CloudStack to support an additional hypervisor.
>> This is not something I consider strategic for CloudStack itself, but I
>> have a project with a very specific need.
>>
>> I have a development background but am not an active developer right now
>> ... so looking forward to getting back in the saddle!  I've never developed
>> against the CloudStack tree before.
>>
>> I can't find any docs on how one would introduce support for a new
>> hypervisor (eg. what classes, methods, etc, need to be implemented,
>> extended, etc) and checking the source tree I can't easily see if there is
>> a base to build from.  I would appreciate any pointers about where to start
>> looking to save me going through the entire tree from scratch.
>>
>> The standard CloudStack concepts should be easy enough (ha!) to map 1:1 to
>> this additional hypervisor (including primary & secondary storage, router &
>> secondary storage VMs, the networking concepts, etc) so I'm hoping that I
>> can simply implement it like a VMware or Xen backend ...
>>
>> Thanks in advance!
>>
>> John.
>>

Re: Extend CloudStack for a new hypervisor

[John Smith]

Ok...so bear with me on this one.

"Hypervisor" was a little white lie.  What I actually want to do is
implement OpenStack as a backend for CloudStack (yo dawg, I hear you like
cloud in your clouds, etc).  I know I can use KVM and OVS as backends for
CloudStack natively but, as I said, this is for a project with some very
specific needs...

As OpenStack is completely API driven, I see no issues with the basics of
communication between CS and OS.

This would, of course, bypass the OS concept of Linux network namespaces
for routing and I would implement the CS routing VM as a VM (just like in
VMware or Xen) connected between an OS tenant network and an OS external
network.  CS volumes would be OS volumes.  Secondary storage would be a VM
running NFS.

In principle, I see that the CS concepts of compute, network and storage
could be implemented on OS.  I was hoping that I could basically write a
"driver" that would do the necessary actions against OS based on standard
calls to a CS class/method/whatever, based on some assumption that the
underlying hypervisor in CS was at least some sort of pluggable
architecture.

Yes, this may sound a little crazy, and I did say this was probably not
something strategic to the CloudStack direction, but for me it actually
fits a funny shaped hole I've discovered and I'm interested in at least
understanding how such a thing could be done.

Thanks,

John.



On Fri, May 19, 2017 at 12:06 AM, Simon Weller 
wrote:

> Which hypervisor are you wanting to implement​?
>
> Simon Weller/615-312-6068
>
> -Original Message-
> From: John Smith [john.smith@gmail.com]
> Received: Thursday, 18 May 2017, 5:29PM
> To: dev@cloudstack.apache.org [dev@cloudstack.apache.org]
> Subject: Extend CloudStack for a new hypervisor
>
> Greetings!
>
> I have a need to extend CloudStack to support an additional hypervisor.
> This is not something I consider strategic for CloudStack itself, but I
> have a project with a very specific need.
>
> I have a development background but am not an active developer right now
> ... so looking forward to getting back in the saddle!  I've never developed
> against the CloudStack tree before.
>
> I can't find any docs on how one would introduce support for a new
> hypervisor (eg. what classes, methods, etc, need to be implemented,
> extended, etc) and checking the source tree I can't easily see if there is
> a base to build from.  I would appreciate any pointers about where to start
> looking to save me going through the entire tree from scratch.
>
> The standard CloudStack concepts should be easy enough (ha!) to map 1:1 to
> this additional hypervisor (including primary & secondary storage, router &
> secondary storage VMs, the networking concepts, etc) so I'm hoping that I
> can simply implement it like a VMware or Xen backend ...
>
> Thanks in advance!
>
> John.
>