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

2017-05-20 Thread Wido den Hollander
Just to check all the +1's, they are about using the OpenStack format. Right?

Config Drive will be there no matter what.

Wido

> Op 19 mei 2017 om 19:45 heeft Kris Sterckx  
> het volgende geschreven:
> 
> 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

2017-05-20 Thread Funs Kessen
Been a while since I looked at this stuff. It might be worth it to look at
the VSphere implementation as that does something similar to what you're
trying to achieve and what Rafael mentions. In effect you could view
CloudStack as the federation of multiple VSphere endpoints, in your case
one or more OpenStack endpoints (or a combination of multiple!). To Daan's
point however with KVM, HyperV and OVM(2|3) the hypervisors are treated as
separate entities, under control of CloudStack, and not as a proxied
semi-orchestrator. The Xenserver implementation is a bit of both, with the
master of the cluster being the point of focus (at least last time I looked
at it). Mind you that this is more geared around the bookkeeping done in CS
then a real "problem" as such, just something to keep in mind when
spelunking the existing hypervisor implementations. Pretty awesome idea
though, and reminds me of long discussions on implementing OpenStack
Neutron in CloudStack for networking :P

With regard to the VirtualBox desire, which I think is pretty awesome and
funny, I really don't see a problem with implementing. VirtualBox has an
API which you can talk to. Getting a VM up and running should not pose a
major challenge I would think, and is not related to what type of
"hypervisor" it is. The host OS might however require some specifics.

Cheers,

Funs

On Fri, May 19, 2017 at 11:22 AM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:

> 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 <
> daan.hoogl...@shapeblue.com>
> 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:
> >

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

2017-05-20 Thread Simon Weller
Yes, I don't see any point in reinventing the wheel.

Simon Weller/615-312-6068

-Original Message-
From: Wido den Hollander [w...@widodh.nl]
Received: Saturday, 20 May 2017, 8:45AM
To: dev@cloudstack.apache.org [dev@cloudstack.apache.org]
Subject: Re: [DISCUSS] Config Drive: Using the OpenStack format?

Just to check all the +1's, they are about using the OpenStack format. Right?

Config Drive will be there no matter what.

Wido

> Op 19 mei 2017 om 19:45 heeft Kris Sterckx  
> het volgende geschreven:
>
> 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
>>>
>>>
>>