You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Chip Childers <ch...@sungard.com> on 2012/07/12 22:32:32 UTC

Update on wrapping DevCloud into a Vagrant Box

I've been working on encapsulating the DevCloud configuration into a
Vagrant [1] box this week.  This was something that was being
discussed on the DevCloud thread [2], but I wanted to break it out
into a different discussion.  I've realized that I hit a bit of a road
block, and want to get the opinion of others in the community about
how far I should go to get around it.

My intent was to break up the DevCloud creation process into two
phases.  Phase 1 could be done centrally, with the resulting image
being updated on semi-regular basis.  It would consist of an
unattended Ubuntu 12.04 installation (following the configuration
guidance that Edison already provided), plus install and config
xen/xcp/network (basically executing "devcloudsetup.sh -p").  Phase 1
isn't going to be a problem really, and has nothing to do with
Vagrant.

My issue is in getting to the second phase, for which I was intending
to do the code checkout, build and final configuration steps within
the VM.

A little bit of background on Vagrant might help those that haven't
used it before:

It's basically an elegant (IMO) way to encapsulate a set of
configuration and provisioning steps for a VM (or multiple VMs) within
VirtualBox.  It's very much designed with developers in mind.  Edison
has already provided a fully configured OVA, but the benefit we would
have of using something like this would be to ensure that everyone
using the Vagrant process would be able to consistently build and
teardown DevCloud instances with the most up to date code (or code
from an appropriate branch).

Vagrant has 2 functions really: VM control and "provisioning" logic.
The former simply manages the VM's hardware configuration and state
(registered, unregistered, running, sleeping, etc...).  The later is
intended to provision a developer's application and config into the VM
during a "vagrant up" call (i.e.: whenever the VM is newly started).
To accomplish this provisioning process, there are 3 different
"provisioner" plugins:  puppet, chef and ssh.  For these to work, the
guest OS needs to have the VirtualBox Guest Additions installed and
functioning...  specifically, they make heavy use of VirtualBox shared
folders to push artifacts into the VM.  They also use ssh to interact
with the guest OS, but it has the expectation that the shared folder
is available to stage temporary script files for each individual
command being sent.

The problem that I've hit is that the VirtualBox guest additions
kernel module is rendered non-functional when the VM is booted into
dom0.  I'm frankly not enough of a kernel guy to figure out if there
is a hack to make it work.  If someone else wants to give it a shot,
I'd be more than happy to walk through the steps to reproduce the
issue.

As far as I can tell though, the option that I have to make Vagrant
work is to get in contact with the maintainers of that project and
discuss options for an alternate "provisioner" plugin (or how to use
what's there in a different way).

I'm looking for comments on two questions:
1 - Does the community (besides myself) have a significant enough
interest in using Vagrant to make it worth the time to sort out the
provisioner issue?

2 - Does anyone have an alternate suggestion for how to achieve what I
had hoped to achieve?

Thanks all,
-chip


[1] http://vagrantup.com/

[2] http://mail-archives.apache.org/mod_mbox/incubator-cloudstack-dev/201207.mbox/%3CCA%2B96GG6Y19zjFtdeOZg1nXJV_Q0_qX77v3cjwRQ%2BABU%3D-rYyBg%40mail.gmail.com%3E

Re: Update on wrapping DevCloud into a Vagrant Box

Posted by David Nalley <da...@gnsa.us>.
On Thu, Jul 12, 2012 at 4:32 PM, Chip Childers
<ch...@sungard.com> wrote:
> I've been working on encapsulating the DevCloud configuration into a
> Vagrant [1] box this week.  This was something that was being
> discussed on the DevCloud thread [2], but I wanted to break it out
> into a different discussion.  I've realized that I hit a bit of a road
> block, and want to get the opinion of others in the community about
> how far I should go to get around it.
>
> My intent was to break up the DevCloud creation process into two
> phases.  Phase 1 could be done centrally, with the resulting image
> being updated on semi-regular basis.  It would consist of an
> unattended Ubuntu 12.04 installation (following the configuration
> guidance that Edison already provided), plus install and config
> xen/xcp/network (basically executing "devcloudsetup.sh -p").  Phase 1
> isn't going to be a problem really, and has nothing to do with
> Vagrant.
>
> My issue is in getting to the second phase, for which I was intending
> to do the code checkout, build and final configuration steps within
> the VM.
>
> A little bit of background on Vagrant might help those that haven't
> used it before:
>
> It's basically an elegant (IMO) way to encapsulate a set of
> configuration and provisioning steps for a VM (or multiple VMs) within
> VirtualBox.  It's very much designed with developers in mind.  Edison
> has already provided a fully configured OVA, but the benefit we would
> have of using something like this would be to ensure that everyone
> using the Vagrant process would be able to consistently build and
> teardown DevCloud instances with the most up to date code (or code
> from an appropriate branch).
>
> Vagrant has 2 functions really: VM control and "provisioning" logic.
> The former simply manages the VM's hardware configuration and state
> (registered, unregistered, running, sleeping, etc...).  The later is
> intended to provision a developer's application and config into the VM
> during a "vagrant up" call (i.e.: whenever the VM is newly started).
> To accomplish this provisioning process, there are 3 different
> "provisioner" plugins:  puppet, chef and ssh.  For these to work, the
> guest OS needs to have the VirtualBox Guest Additions installed and
> functioning...  specifically, they make heavy use of VirtualBox shared
> folders to push artifacts into the VM.  They also use ssh to interact
> with the guest OS, but it has the expectation that the shared folder
> is available to stage temporary script files for each individual
> command being sent.
>
> The problem that I've hit is that the VirtualBox guest additions
> kernel module is rendered non-functional when the VM is booted into
> dom0.  I'm frankly not enough of a kernel guy to figure out if there
> is a hack to make it work.  If someone else wants to give it a shot,
> I'd be more than happy to walk through the steps to reproduce the
> issue.
>
> As far as I can tell though, the option that I have to make Vagrant
> work is to get in contact with the maintainers of that project and
> discuss options for an alternate "provisioner" plugin (or how to use
> what's there in a different way).
>
> I'm looking for comments on two questions:
> 1 - Does the community (besides myself) have a significant enough
> interest in using Vagrant to make it worth the time to sort out the
> provisioner issue?

Are you installing the -headers -devel kernel packages for the Xen
kernel (I have no idea of Ubuntu/debian call the packages
-headers/-kernel - it could be that it's not not able to build the new
packages.

So the only other immediate idea is this:
Divide this up into runstages - 1 for the prep - and then when
everything is configured - change the kernel you boot too as the final
runstage, after which it should be ok that the vagrant plugin doesn't
load.

>
> 2 - Does anyone have an alternate suggestion for how to achieve what I
> had hoped to achieve?


libguestfs? It certainly won't do everything, but might do some of it.

RE: Update on wrapping DevCloud into a Vagrant Box

Posted by Edison Su <Ed...@citrix.com>.

> -----Original Message-----
> From: Chip Childers [mailto:chip.childers@sungard.com]
> Sent: Thursday, July 19, 2012 1:17 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: Update on wrapping DevCloud into a Vagrant Box
> 
> On Mon, Jul 16, 2012 at 9:10 PM, Edison Su <Ed...@citrix.com> wrote:
> 
> >
> >
> > > -----Original Message-----
> > > From: Chip Childers [mailto:chip.childers@sungard.com]
> > > Sent: Friday, July 13, 2012 8:17 AM
> > > To: cloudstack-dev@incubator.apache.org
> > > Subject: Re: Update on wrapping DevCloud into a Vagrant Box
> > >
> > > On Thu, Jul 12, 2012 at 6:17 PM, Edison Su <Ed...@citrix.com>
> wrote:
> > > > If automate doesn't work, document it?,..
> > >
> > > I'm going to pivot a bit here, and aim for the following:
> > >
> > > 1 - Unattended Ubuntu 12.04 installation, per Edison's specs.
> > > 2 - Puppet manifest to describe handle the pre-configuration phase.
> > > 3 - Puppet manifest to provision the post-configuration phase.
> >
> > Hi Chip, the ubuntu 12.04 build is fixed. You can check out the
> latest
> > master branch, "./waf deb" will build deb packages under
> artifacts/debbuild
> >
> > >
> > > We can use the unattended install and puppet manifests in a number
> of
> > > different ways, which might include a Vagrant provisioning config
> in
> > > the future.
> > >
> > > Folks from Citrix - The puppet manifest for cloudstack is hosted on
> > > Github still [1].  It's README file says that it's GPL (but also
> has a
> > > commentary about how manifests are probably not copyrightable).
> > > Anyone have an issue using this as a starting point for step 3
> above?
> > >
> > > [1] https://github.com/CloudStack/puppet-cloudstack
> >
> >
> Fantastic!
> 
> My "work-in-progress" is on GitHub here:
> https://github.com/chipchilders/CloudStack/tree/master/tools/devcloud
> 
> Specifically, please review the conversion of the devcloudsetup -p
> process
> to a "puppet-devcloudinitial" puppet module.

Great, at them same time, I am hacking on vagrant, get it work with devcloud, without VirtualBox addon.

> 
> -chip

Re: Update on wrapping DevCloud into a Vagrant Box

Posted by Chip Childers <ch...@sungard.com>.
On Tue, Jul 31, 2012 at 9:56 PM, David Nalley <da...@gnsa.us> wrote:
> That said, it's important to establish that the image isn't an
> official release of the project.

Agreed.

> Perhaps your people.apache.org space
> - though I'd certainly ask in #asfinfra before I DDoSed people.a.o :)

It's actually a bit more complicated.  I'd like to have it built on a
server somewhere, and that requires root access to load the VirtualBox
kernel module.  I opened a task with infra@ discussing the
requirements here > https://issues.apache.org/jira/browse/INFRA-5105

> A nice blogpost as well as a wiki page on how to generate your own
> images would be wonderful.

Absolutely.

-chip

Re: Update on wrapping DevCloud into a Vagrant Box

Posted by Chip Childers <ch...@sungard.com>.
s/GB/MB

Doh!

On Tue, Jul 31, 2012 at 9:56 PM, David Nalley <da...@gnsa.us> wrote:
> On Tue, Jul 31, 2012 at 9:36 PM, Chip Childers
> <ch...@sungard.com> wrote:
>
>> Does anyone know if there is an appropriate place within the ASF
>> infrastructure to be generating / hosting files that are around ~500
>> GB?  If I don't hear from anyone in a day or two, I'll open a ticket
>
> 500GB????
> Not all of us work for an ISP with fiber to our cubicle :)
>
> That said, it's important to establish that the image isn't an
> official release of the project. Perhaps your people.apache.org space
> - though I'd certainly ask in #asfinfra before I DDoSed people.a.o :)
> A nice blogpost as well as a wiki page on how to generate your own
> images would be wonderful.
>
> --David
>

Re: Update on wrapping DevCloud into a Vagrant Box

Posted by John Kinsella <jl...@stratosec.co>.
On Jul 31, 2012, at 6:56 PM, David Nalley wrote:

On Tue, Jul 31, 2012 at 9:36 PM, Chip Childers
<ch...@sungard.com>> wrote:

Does anyone know if there is an appropriate place within the ASF
infrastructure to be generating / hosting files that are around ~500
GB?  If I don't hear from anyone in a day or two, I'll open a ticket

500GB????
Not all of us work for an ISP with fiber to our cubicle :)

That said, it's important to establish that the image isn't an
official release of the project. Perhaps your people.apache.org<http://people.apache.org> space
- though I'd certainly ask in #asfinfra before I DDoSed people.a.o :)
A nice blogpost as well as a wiki page on how to generate your own
images would be wonderful.

What's ASF's policy on distributing via bittorrent? (I realize Chip meant 500MB not GB, still curious)


Re: Update on wrapping DevCloud into a Vagrant Box

Posted by David Nalley <da...@gnsa.us>.
On Tue, Jul 31, 2012 at 9:36 PM, Chip Childers
<ch...@sungard.com> wrote:

> Does anyone know if there is an appropriate place within the ASF
> infrastructure to be generating / hosting files that are around ~500
> GB?  If I don't hear from anyone in a day or two, I'll open a ticket

500GB????
Not all of us work for an ISP with fiber to our cubicle :)

That said, it's important to establish that the image isn't an
official release of the project. Perhaps your people.apache.org space
- though I'd certainly ask in #asfinfra before I DDoSed people.a.o :)
A nice blogpost as well as a wiki page on how to generate your own
images would be wonderful.

--David

Re: Update on wrapping DevCloud into a Vagrant Box

Posted by Chip Childers <ch...@sungard.com>.
I have this working end to end now:
1 - veewee to build a base Ubuntu VM - (I saw this config in the repo
Edison, and just started using it as our starting point for the
overall process)
2 - vagrant / puppet to apply the devcloud pre-config to that base ubuntu box
3 - export of a new "box" based on the pre-config

At that point, we can bundle the box with the Vagrantfile / puppet
modules that developers can use.  I have all of the post configuration
steps configured in a puppet module too, so each time "vagrant up" is
run, the configuration is confirmed and the latest code from ASF
master is downloaded / built.

Unfortunately I think I'll need to clean up a few vagrant related
patches / modifications.  Hopefully some of the change will make it
into the actual Vagrant project itself (puppet provisioning via SCP
uploads), but we can actually create plugins to support our own use of
vagrant.

Does anyone know if there is an appropriate place within the ASF
infrastructure to be generating / hosting files that are around ~500
GB?  If I don't hear from anyone in a day or two, I'll open a ticket
with infra@.  I'd like to have an ASF hosted location to generate and
distribute the devcloud artifacts from.

-chip

RE: Update on wrapping DevCloud into a Vagrant Box

Posted by Edison Su <Ed...@citrix.com>.

> -----Original Message-----
> From: Chip Childers [mailto:chip.childers@sungard.com]
> Sent: Monday, July 30, 2012 6:02 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: Update on wrapping DevCloud into a Vagrant Box
> 
> Edison,
> 
> I'm working on converting the second phase of the devcloudsetup.sh
> script to puppet, but I ran into this issue.
> 
> Looking for help understanding what you were doing here:
> 
> In this section of the script:
> 
> 107     echo "configure xcp"
> 108     wget $fileSvr/echo -P /usr/lib/xcp/plugins/
> 109     chmod -R 777 /usr/lib/xcp
> 
> I'm not sure what the wget URL is supposed to be.  I currently get a
> 404 when I manually execute that step:
> 
> oot@devcloud:~# wget http://download.cloud.com/templates/devcloud/echo
> -P /usr/lib/xcp/plugins/
> --2012-07-30 02:31:55--
> http://download.cloud.com/templates/devcloud/echo
> Resolving download.cloud.com (download.cloud.com)... 205.251.242.165
> Connecting to download.cloud.com
> (download.cloud.com)|205.251.242.165|:80... connected.
> HTTP request sent, awaiting response... 404 Not Found
> 2012-07-30 02:31:56 ERROR 404: Not Found.

Can you try again? I uploaded http://download.cloud.com/templates/devcloud/echo already.

Re: Update on wrapping DevCloud into a Vagrant Box

Posted by Chip Childers <ch...@sungard.com>.
Edison,

I'm working on converting the second phase of the devcloudsetup.sh
script to puppet, but I ran into this issue.

Looking for help understanding what you were doing here:

In this section of the script:

107     echo "configure xcp"
108     wget $fileSvr/echo -P /usr/lib/xcp/plugins/
109     chmod -R 777 /usr/lib/xcp

I'm not sure what the wget URL is supposed to be.  I currently get a
404 when I manually execute that step:

oot@devcloud:~# wget http://download.cloud.com/templates/devcloud/echo
-P /usr/lib/xcp/plugins/
--2012-07-30 02:31:55--  http://download.cloud.com/templates/devcloud/echo
Resolving download.cloud.com (download.cloud.com)... 205.251.242.165
Connecting to download.cloud.com
(download.cloud.com)|205.251.242.165|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2012-07-30 02:31:56 ERROR 404: Not Found.

Re: Update on wrapping DevCloud into a Vagrant Box

Posted by Chip Childers <ch...@sungard.com>.
On Fri, Jul 20, 2012 at 2:21 PM, David Nalley <da...@gnsa.us> wrote:
> On Fri, Jul 20, 2012 at 2:19 PM, Edison Su <Ed...@citrix.com> wrote:
>>
>>
>>> -----Original Message-----
>>> From: Chip Childers [mailto:chip.childers@sungard.com]
>>> Sent: Friday, July 20, 2012 10:56 AM
>>> To: cloudstack-dev@incubator.apache.org
>>> Subject: Re: Update on wrapping DevCloud into a Vagrant Box
>>>
>>> Edison,
>>>
>>> A couple of questions for you:
>>>
>>> 1 - It looks like you are using password-based authentication for the
>>> scp command (changed in lib/vagrant/ssh.rb ).  Am I reading that
>>> change correctly?  I think we can get away with using the vagrant
>>> "user" and standard vagrant public / private keys (including the
>>> requirement to allow the vagrant user to run anything via sudo with no
>>> password).
>>
>> I did try to work it with password, but failed.
>> Only private key works. "vagrant ssh" will call ssh, not ruby::net::ssh.
>>
>>>
>>> 2 - Did you happen to reach out to the Vagrant project folks to see if
>>> the copy via ssh support for the puppet provisioner would be accepted?
>>>  I think it would be great to upstream this patch via a pull request
>>> to the mitchellh/vagrant repo!
>>
>> Not yet, will do.
>
>
> I briefly spoke to Mitchell about this at OSCON and he seemed interested.
>
> --David
>

I had to make a few more changes to Vagrant (starting with the work
Edison did), and just submitted a pull request to Mitchell here:

https://github.com/mitchellh/vagrant/pull/1043

I'll start committing puppet configuration files for the first phase shortly.

-chip

Re: Update on wrapping DevCloud into a Vagrant Box

Posted by David Nalley <da...@gnsa.us>.
On Fri, Jul 20, 2012 at 2:19 PM, Edison Su <Ed...@citrix.com> wrote:
>
>
>> -----Original Message-----
>> From: Chip Childers [mailto:chip.childers@sungard.com]
>> Sent: Friday, July 20, 2012 10:56 AM
>> To: cloudstack-dev@incubator.apache.org
>> Subject: Re: Update on wrapping DevCloud into a Vagrant Box
>>
>> Edison,
>>
>> A couple of questions for you:
>>
>> 1 - It looks like you are using password-based authentication for the
>> scp command (changed in lib/vagrant/ssh.rb ).  Am I reading that
>> change correctly?  I think we can get away with using the vagrant
>> "user" and standard vagrant public / private keys (including the
>> requirement to allow the vagrant user to run anything via sudo with no
>> password).
>
> I did try to work it with password, but failed.
> Only private key works. "vagrant ssh" will call ssh, not ruby::net::ssh.
>
>>
>> 2 - Did you happen to reach out to the Vagrant project folks to see if
>> the copy via ssh support for the puppet provisioner would be accepted?
>>  I think it would be great to upstream this patch via a pull request
>> to the mitchellh/vagrant repo!
>
> Not yet, will do.


I briefly spoke to Mitchell about this at OSCON and he seemed interested.

--David

RE: Update on wrapping DevCloud into a Vagrant Box

Posted by Edison Su <Ed...@citrix.com>.

> -----Original Message-----
> From: Chip Childers [mailto:chip.childers@sungard.com]
> Sent: Friday, July 20, 2012 10:56 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: Update on wrapping DevCloud into a Vagrant Box
> 
> Edison,
> 
> A couple of questions for you:
> 
> 1 - It looks like you are using password-based authentication for the
> scp command (changed in lib/vagrant/ssh.rb ).  Am I reading that
> change correctly?  I think we can get away with using the vagrant
> "user" and standard vagrant public / private keys (including the
> requirement to allow the vagrant user to run anything via sudo with no
> password).

I did try to work it with password, but failed.
Only private key works. "vagrant ssh" will call ssh, not ruby::net::ssh.

> 
> 2 - Did you happen to reach out to the Vagrant project folks to see if
> the copy via ssh support for the puppet provisioner would be accepted?
>  I think it would be great to upstream this patch via a pull request
> to the mitchellh/vagrant repo!

Not yet, will do.

> 
> I'll install this patched version of Vagrant and start testing against
> the puppet config I'm working on.
> 
> -chip
> 
> On Fri, Jul 20, 2012 at 1:23 AM, Edison Su <Ed...@citrix.com> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Chip Childers [mailto:chip.childers@sungard.com]
> > > Sent: Thursday, July 19, 2012 1:17 AM
> > > To: cloudstack-dev@incubator.apache.org
> > > Subject: Re: Update on wrapping DevCloud into a Vagrant Box
> > >
> > > On Mon, Jul 16, 2012 at 9:10 PM, Edison Su <Ed...@citrix.com>
> wrote:
> > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Chip Childers [mailto:chip.childers@sungard.com]
> > > > > Sent: Friday, July 13, 2012 8:17 AM
> > > > > To: cloudstack-dev@incubator.apache.org
> > > > > Subject: Re: Update on wrapping DevCloud into a Vagrant Box
> > > > >
> > > > > On Thu, Jul 12, 2012 at 6:17 PM, Edison Su
> <Ed...@citrix.com>
> > > wrote:
> > > > > > If automate doesn't work, document it?,..
> > > > >
> > > > > I'm going to pivot a bit here, and aim for the following:
> > > > >
> > > > > 1 - Unattended Ubuntu 12.04 installation, per Edison's specs.
> > > > > 2 - Puppet manifest to describe handle the pre-configuration
> phase.
> > > > > 3 - Puppet manifest to provision the post-configuration phase.
> > > >
> > > > Hi Chip, the ubuntu 12.04 build is fixed. You can check out the
> > > latest
> > > > master branch, "./waf deb" will build deb packages under
> > > artifacts/debbuild
> > > >
> > > > >
> > > > > We can use the unattended install and puppet manifests in a
> number
> > > of
> > > > > different ways, which might include a Vagrant provisioning
> config
> > > in
> > > > > the future.
> > > > >
> > > > > Folks from Citrix - The puppet manifest for cloudstack is
> hosted on
> > > > > Github still [1].  It's README file says that it's GPL (but
> also
> > > has a
> > > > > commentary about how manifests are probably not copyrightable).
> > > > > Anyone have an issue using this as a starting point for step 3
> > > above?
> > > > >
> > > > > [1] https://github.com/CloudStack/puppet-cloudstack
> > > >
> > > >
> > > Fantastic!
> > >
> > > My "work-in-progress" is on GitHub here:
> > >
> https://github.com/chipchilders/CloudStack/tree/master/tools/devcloud
> > >
> > > Specifically, please review the conversion of the devcloudsetup -p
> > > process
> > > to a "puppet-devcloudinitial" puppet module.
> > >
> >
> > Vagrant is been fixed, without Addon, we can still provision devcloud.
> > Get the last code vagrant code from:
> https://github.com/sudison/vagrant
> > My sample Vagrantfile:
> >   config.vm.provision :puppet do |puppet|
> >      puppet.manifests_path = "puppet"
> >      puppet.manifest_file  = "init.pp"
> >      puppet.with_ssh       = true
> >      puppet.pp_path        = "/opt/puppet"
> >   end
> >
> > During "vagrant provision", vagrant will copy puppet/init.pp to
> /opt/puppet/manifest/ before execute puppet on devcloud.
> >
> > > -chip
> >

Re: Update on wrapping DevCloud into a Vagrant Box

Posted by Chip Childers <ch...@sungard.com>.
Edison,

A couple of questions for you:

1 - It looks like you are using password-based authentication for the
scp command (changed in lib/vagrant/ssh.rb ).  Am I reading that
change correctly?  I think we can get away with using the vagrant
"user" and standard vagrant public / private keys (including the
requirement to allow the vagrant user to run anything via sudo with no
password).

2 - Did you happen to reach out to the Vagrant project folks to see if
the copy via ssh support for the puppet provisioner would be accepted?
 I think it would be great to upstream this patch via a pull request
to the mitchellh/vagrant repo!

I'll install this patched version of Vagrant and start testing against
the puppet config I'm working on.

-chip

On Fri, Jul 20, 2012 at 1:23 AM, Edison Su <Ed...@citrix.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Chip Childers [mailto:chip.childers@sungard.com]
> > Sent: Thursday, July 19, 2012 1:17 AM
> > To: cloudstack-dev@incubator.apache.org
> > Subject: Re: Update on wrapping DevCloud into a Vagrant Box
> >
> > On Mon, Jul 16, 2012 at 9:10 PM, Edison Su <Ed...@citrix.com> wrote:
> >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Chip Childers [mailto:chip.childers@sungard.com]
> > > > Sent: Friday, July 13, 2012 8:17 AM
> > > > To: cloudstack-dev@incubator.apache.org
> > > > Subject: Re: Update on wrapping DevCloud into a Vagrant Box
> > > >
> > > > On Thu, Jul 12, 2012 at 6:17 PM, Edison Su <Ed...@citrix.com>
> > wrote:
> > > > > If automate doesn't work, document it?,..
> > > >
> > > > I'm going to pivot a bit here, and aim for the following:
> > > >
> > > > 1 - Unattended Ubuntu 12.04 installation, per Edison's specs.
> > > > 2 - Puppet manifest to describe handle the pre-configuration phase.
> > > > 3 - Puppet manifest to provision the post-configuration phase.
> > >
> > > Hi Chip, the ubuntu 12.04 build is fixed. You can check out the
> > latest
> > > master branch, "./waf deb" will build deb packages under
> > artifacts/debbuild
> > >
> > > >
> > > > We can use the unattended install and puppet manifests in a number
> > of
> > > > different ways, which might include a Vagrant provisioning config
> > in
> > > > the future.
> > > >
> > > > Folks from Citrix - The puppet manifest for cloudstack is hosted on
> > > > Github still [1].  It's README file says that it's GPL (but also
> > has a
> > > > commentary about how manifests are probably not copyrightable).
> > > > Anyone have an issue using this as a starting point for step 3
> > above?
> > > >
> > > > [1] https://github.com/CloudStack/puppet-cloudstack
> > >
> > >
> > Fantastic!
> >
> > My "work-in-progress" is on GitHub here:
> > https://github.com/chipchilders/CloudStack/tree/master/tools/devcloud
> >
> > Specifically, please review the conversion of the devcloudsetup -p
> > process
> > to a "puppet-devcloudinitial" puppet module.
> >
>
> Vagrant is been fixed, without Addon, we can still provision devcloud.
> Get the last code vagrant code from: https://github.com/sudison/vagrant
> My sample Vagrantfile:
>   config.vm.provision :puppet do |puppet|
>      puppet.manifests_path = "puppet"
>      puppet.manifest_file  = "init.pp"
>      puppet.with_ssh       = true
>      puppet.pp_path        = "/opt/puppet"
>   end
>
> During "vagrant provision", vagrant will copy puppet/init.pp to /opt/puppet/manifest/ before execute puppet on devcloud.
>
> > -chip
>

RE: Update on wrapping DevCloud into a Vagrant Box

Posted by Edison Su <Ed...@citrix.com>.

> -----Original Message-----
> From: Chip Childers [mailto:chip.childers@sungard.com]
> Sent: Thursday, July 19, 2012 1:17 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: Update on wrapping DevCloud into a Vagrant Box
> 
> On Mon, Jul 16, 2012 at 9:10 PM, Edison Su <Ed...@citrix.com> wrote:
> 
> >
> >
> > > -----Original Message-----
> > > From: Chip Childers [mailto:chip.childers@sungard.com]
> > > Sent: Friday, July 13, 2012 8:17 AM
> > > To: cloudstack-dev@incubator.apache.org
> > > Subject: Re: Update on wrapping DevCloud into a Vagrant Box
> > >
> > > On Thu, Jul 12, 2012 at 6:17 PM, Edison Su <Ed...@citrix.com>
> wrote:
> > > > If automate doesn't work, document it?,..
> > >
> > > I'm going to pivot a bit here, and aim for the following:
> > >
> > > 1 - Unattended Ubuntu 12.04 installation, per Edison's specs.
> > > 2 - Puppet manifest to describe handle the pre-configuration phase.
> > > 3 - Puppet manifest to provision the post-configuration phase.
> >
> > Hi Chip, the ubuntu 12.04 build is fixed. You can check out the
> latest
> > master branch, "./waf deb" will build deb packages under
> artifacts/debbuild
> >
> > >
> > > We can use the unattended install and puppet manifests in a number
> of
> > > different ways, which might include a Vagrant provisioning config
> in
> > > the future.
> > >
> > > Folks from Citrix - The puppet manifest for cloudstack is hosted on
> > > Github still [1].  It's README file says that it's GPL (but also
> has a
> > > commentary about how manifests are probably not copyrightable).
> > > Anyone have an issue using this as a starting point for step 3
> above?
> > >
> > > [1] https://github.com/CloudStack/puppet-cloudstack
> >
> >
> Fantastic!
> 
> My "work-in-progress" is on GitHub here:
> https://github.com/chipchilders/CloudStack/tree/master/tools/devcloud
> 
> Specifically, please review the conversion of the devcloudsetup -p
> process
> to a "puppet-devcloudinitial" puppet module.
> 

Vagrant is been fixed, without Addon, we can still provision devcloud.
Get the last code vagrant code from: https://github.com/sudison/vagrant
My sample Vagrantfile:
  config.vm.provision :puppet do |puppet|
     puppet.manifests_path = "puppet"
     puppet.manifest_file  = "init.pp"
     puppet.with_ssh       = true
     puppet.pp_path        = "/opt/puppet"
  end

During "vagrant provision", vagrant will copy puppet/init.pp to /opt/puppet/manifest/ before execute puppet on devcloud.

> -chip

Re: Update on wrapping DevCloud into a Vagrant Box

Posted by Chip Childers <ch...@sungard.com>.
On Mon, Jul 16, 2012 at 9:10 PM, Edison Su <Ed...@citrix.com> wrote:

>
>
> > -----Original Message-----
> > From: Chip Childers [mailto:chip.childers@sungard.com]
> > Sent: Friday, July 13, 2012 8:17 AM
> > To: cloudstack-dev@incubator.apache.org
> > Subject: Re: Update on wrapping DevCloud into a Vagrant Box
> >
> > On Thu, Jul 12, 2012 at 6:17 PM, Edison Su <Ed...@citrix.com> wrote:
> > > If automate doesn't work, document it?,..
> >
> > I'm going to pivot a bit here, and aim for the following:
> >
> > 1 - Unattended Ubuntu 12.04 installation, per Edison's specs.
> > 2 - Puppet manifest to describe handle the pre-configuration phase.
> > 3 - Puppet manifest to provision the post-configuration phase.
>
> Hi Chip, the ubuntu 12.04 build is fixed. You can check out the latest
> master branch, "./waf deb" will build deb packages under artifacts/debbuild
>
> >
> > We can use the unattended install and puppet manifests in a number of
> > different ways, which might include a Vagrant provisioning config in
> > the future.
> >
> > Folks from Citrix - The puppet manifest for cloudstack is hosted on
> > Github still [1].  It's README file says that it's GPL (but also has a
> > commentary about how manifests are probably not copyrightable).
> > Anyone have an issue using this as a starting point for step 3 above?
> >
> > [1] https://github.com/CloudStack/puppet-cloudstack
>
>
Fantastic!

My "work-in-progress" is on GitHub here:
https://github.com/chipchilders/CloudStack/tree/master/tools/devcloud

Specifically, please review the conversion of the devcloudsetup -p process
to a "puppet-devcloudinitial" puppet module.

-chip

RE: Update on wrapping DevCloud into a Vagrant Box

Posted by Edison Su <Ed...@citrix.com>.

> -----Original Message-----
> From: Chip Childers [mailto:chip.childers@sungard.com]
> Sent: Friday, July 13, 2012 8:17 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: Update on wrapping DevCloud into a Vagrant Box
> 
> On Thu, Jul 12, 2012 at 6:17 PM, Edison Su <Ed...@citrix.com> wrote:
> > If automate doesn't work, document it?,..
> 
> I'm going to pivot a bit here, and aim for the following:
> 
> 1 - Unattended Ubuntu 12.04 installation, per Edison's specs.
> 2 - Puppet manifest to describe handle the pre-configuration phase.
> 3 - Puppet manifest to provision the post-configuration phase.

Hi Chip, the ubuntu 12.04 build is fixed. You can check out the latest master branch, "./waf deb" will build deb packages under artifacts/debbuild

> 
> We can use the unattended install and puppet manifests in a number of
> different ways, which might include a Vagrant provisioning config in
> the future.
> 
> Folks from Citrix - The puppet manifest for cloudstack is hosted on
> Github still [1].  It's README file says that it's GPL (but also has a
> commentary about how manifests are probably not copyrightable).
> Anyone have an issue using this as a starting point for step 3 above?
> 
> [1] https://github.com/CloudStack/puppet-cloudstack

Re: Update on wrapping DevCloud into a Vagrant Box

Posted by David Nalley <da...@gnsa.us>.
On Fri, Jul 13, 2012 at 11:16 AM, Chip Childers
<ch...@sungard.com> wrote:
> On Thu, Jul 12, 2012 at 6:17 PM, Edison Su <Ed...@citrix.com> wrote:
>> If automate doesn't work, document it?,..
>
> I'm going to pivot a bit here, and aim for the following:
>
> 1 - Unattended Ubuntu 12.04 installation, per Edison's specs.
> 2 - Puppet manifest to describe handle the pre-configuration phase.prasanna
> 3 - Puppet manifest to provision the post-configuration phase.
>
> We can use the unattended install and puppet manifests in a number of
> different ways, which might include a Vagrant provisioning config in
> the future.
>
> Folks from Citrix - The puppet manifest for cloudstack is hosted on
> Github still [1].  It's README file says that it's GPL (but also has a
> commentary about how manifests are probably not copyrightable).
> Anyone have an issue using this as a starting point for step 3 above?
>
> [1] https://github.com/CloudStack/puppet-cloudstack

So no objection (and Eric Shamow and I are the sole authors of that,
and while I won't speak for him, I am pretty sure that we'd have no
issue relicensing that to ASL or something even more permissive.)

I'd also recommend you look at my fork - it's much further along.
https://github.com/ke4qqq/puppet-cloudstack   - and to boot it's
already relicensed.

--David

RE: Update on wrapping DevCloud into a Vagrant Box

Posted by Edison Su <Ed...@citrix.com>.

> -----Original Message-----
> From: Chip Childers [mailto:chip.childers@sungard.com]
> Sent: Friday, July 13, 2012 8:17 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: Update on wrapping DevCloud into a Vagrant Box
> 
> On Thu, Jul 12, 2012 at 6:17 PM, Edison Su <Ed...@citrix.com> wrote:
> > If automate doesn't work, document it?,..
> 
> I'm going to pivot a bit here, and aim for the following:
> 
> 1 - Unattended Ubuntu 12.04 installation, per Edison's specs.
> 2 - Puppet manifest to describe handle the pre-configuration phase.
> 3 - Puppet manifest to provision the post-configuration phase.
> 
> We can use the unattended install and puppet manifests in a number of
> different ways, which might include a Vagrant provisioning config in
> the future.

I tried https://github.com/jedi4ever/veewee, which works as it claims, provision a virtualbox vm is pretty easy.
Veewee configuration files are checked into tools/devcloud/veewee, we can use it as a base to create devcloud base image.

> 
> Folks from Citrix - The puppet manifest for cloudstack is hosted on
> Github still [1].  It's README file says that it's GPL (but also has a
> commentary about how manifests are probably not copyrightable).
> Anyone have an issue using this as a starting point for step 3 above?
> 
> [1] https://github.com/CloudStack/puppet-cloudstack

Re: Update on wrapping DevCloud into a Vagrant Box

Posted by Chip Childers <ch...@sungard.com>.
On Thu, Jul 12, 2012 at 6:17 PM, Edison Su <Ed...@citrix.com> wrote:
> If automate doesn't work, document it?,..

I'm going to pivot a bit here, and aim for the following:

1 - Unattended Ubuntu 12.04 installation, per Edison's specs.
2 - Puppet manifest to describe handle the pre-configuration phase.
3 - Puppet manifest to provision the post-configuration phase.

We can use the unattended install and puppet manifests in a number of
different ways, which might include a Vagrant provisioning config in
the future.

Folks from Citrix - The puppet manifest for cloudstack is hosted on
Github still [1].  It's README file says that it's GPL (but also has a
commentary about how manifests are probably not copyrightable).
Anyone have an issue using this as a starting point for step 3 above?

[1] https://github.com/CloudStack/puppet-cloudstack

RE: Update on wrapping DevCloud into a Vagrant Box

Posted by Edison Su <Ed...@citrix.com>.

> -----Original Message-----
> From: Chip Childers [mailto:chip.childers@sungard.com]
> Sent: Thursday, July 12, 2012 1:33 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: Update on wrapping DevCloud into a Vagrant Box
> 
> I've been working on encapsulating the DevCloud configuration into a
> Vagrant [1] box this week.  This was something that was being
> discussed on the DevCloud thread [2], but I wanted to break it out
> into a different discussion.  I've realized that I hit a bit of a road
> block, and want to get the opinion of others in the community about
> how far I should go to get around it.
> 
> My intent was to break up the DevCloud creation process into two
> phases.  Phase 1 could be done centrally, with the resulting image
> being updated on semi-regular basis.  It would consist of an
> unattended Ubuntu 12.04 installation (following the configuration
> guidance that Edison already provided), plus install and config
> xen/xcp/network (basically executing "devcloudsetup.sh -p").  Phase 1
> isn't going to be a problem really, and has nothing to do with
> Vagrant.
> 
> My issue is in getting to the second phase, for which I was intending
> to do the code checkout, build and final configuration steps within
> the VM.
> 
> A little bit of background on Vagrant might help those that haven't
> used it before:
> 
> It's basically an elegant (IMO) way to encapsulate a set of
> configuration and provisioning steps for a VM (or multiple VMs) within
> VirtualBox.  It's very much designed with developers in mind.  Edison
> has already provided a fully configured OVA, but the benefit we would
> have of using something like this would be to ensure that everyone
> using the Vagrant process would be able to consistently build and
> teardown DevCloud instances with the most up to date code (or code
> from an appropriate branch).
> 
> Vagrant has 2 functions really: VM control and "provisioning" logic.
> The former simply manages the VM's hardware configuration and state
> (registered, unregistered, running, sleeping, etc...).  The later is
> intended to provision a developer's application and config into the VM
> during a "vagrant up" call (i.e.: whenever the VM is newly started).
> To accomplish this provisioning process, there are 3 different
> "provisioner" plugins:  puppet, chef and ssh.  For these to work, the
> guest OS needs to have the VirtualBox Guest Additions installed and
> functioning...  specifically, they make heavy use of VirtualBox shared
> folders to push artifacts into the VM.  They also use ssh to interact
> with the guest OS, but it has the expectation that the shared folder
> is available to stage temporary script files for each individual
> command being sent.
> 
> The problem that I've hit is that the VirtualBox guest additions
> kernel module is rendered non-functional when the VM is booted into
> dom0.  I'm frankly not enough of a kernel guy to figure out if there
> is a hack to make it work.  If someone else wants to give it a shot,
> I'd be more than happy to walk through the steps to reproduce the
> issue.
> 
> As far as I can tell though, the option that I have to make Vagrant
> work is to get in contact with the maintainers of that project and
> discuss options for an alternate "provisioner" plugin (or how to use
> what's there in a different way).
> 
> I'm looking for comments on two questions:
> 1 - Does the community (besides myself) have a significant enough
> interest in using Vagrant to make it worth the time to sort out the
> provisioner issue?

If it can work without VirtualBox Addon(ssh/scp works, why the shared folder is a must?), then we will use it.
It's not worth to spend a lot of time on getting Addon work in dom0, Addon is not intended to work in dom0.

> 
> 2 - Does anyone have an alternate suggestion for how to achieve what I
> had hoped to achieve?
If automate doesn't work, document it?,..

> 
> Thanks all,
> -chip
> 
> 
> [1] http://vagrantup.com/
> 
> [2] http://mail-archives.apache.org/mod_mbox/incubator-cloudstack-
> dev/201207.mbox/%3CCA%2B96GG6Y19zjFtdeOZg1nXJV_Q0_qX77v3cjwRQ%2BABU%3D-
> rYyBg%40mail.gmail.com%3E

RE: Update on wrapping DevCloud into a Vagrant Box

Posted by Edison Su <Ed...@citrix.com>.

> -----Original Message-----
> From: sebgoa [mailto:runseb@gmail.com]
> Sent: Thursday, July 12, 2012 2:32 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: Update on wrapping DevCloud into a Vagrant Box
> 
> 
> On Jul 12, 2012, at 4:32 PM, Chip Childers wrote:
> 
> > 2 - Does anyone have an alternate suggestion for how to achieve what
> I
> > had hoped to achieve?
> 
> Hi Chip, I did not know about Vagrant, it sounds great, but if it does
> not work you might want to check out rpath:
> http://www.rpath.com/product/rpath-cloud-engine.php
> I think it could cut it.
> 
> Personally, I think it would be great to extend DevCloud into a set of
> VMs (Manager, Cloudbridge and host) that we can deploy on vbox or KVM
> and the like to create a fully virtualized cloudstack infrastructure.
> We could use it as a testbed to "teach" cloudstack and experiment with
> the networking.

Yes, I heard of other people have the same requirements, that need one mgt server vm + one or more hypervisor host vms, then glue them together as a testbed.
Or more radically, using the real nested virtualization(e.g. only VMware can have this capability that supports nested VT-x + EPT) + SDN, so that you can have real virtualized hypervisor hosts(ESXi/Xenserver/KVM hosts etc), plus any virtual networks you want. 

> 
> -Sebastien Goasguen
> Apache Cloudstack evangelist.

Re: Update on wrapping DevCloud into a Vagrant Box

Posted by sebgoa <ru...@gmail.com>.
On Jul 12, 2012, at 6:19 PM, Outback Dingo wrote:

> On Thu, Jul 12, 2012 at 5:32 PM, sebgoa <ru...@gmail.com> wrote:
>> 
>> On Jul 12, 2012, at 4:32 PM, Chip Childers wrote:
>> 
>>> 2 - Does anyone have an alternate suggestion for how to achieve what I
>>> had hoped to achieve?
>> 
>> Hi Chip, I did not know about Vagrant, it sounds great, but if it does not work you might want to check out rpath:
>> http://www.rpath.com/product/rpath-cloud-engine.php
>> I think it could cut it.
> 
> Id completely avoid rpath its way to proprietary....... vagrant rocks

Yes, that was probably a bad idea :) 
Vagrant seems to be only for vbox, and I was thinking of supporting multiple hypervisor.

-Sebastien


Re: Update on wrapping DevCloud into a Vagrant Box

Posted by Outback Dingo <ou...@gmail.com>.
On Thu, Jul 12, 2012 at 5:32 PM, sebgoa <ru...@gmail.com> wrote:
>
> On Jul 12, 2012, at 4:32 PM, Chip Childers wrote:
>
>> 2 - Does anyone have an alternate suggestion for how to achieve what I
>> had hoped to achieve?
>
> Hi Chip, I did not know about Vagrant, it sounds great, but if it does not work you might want to check out rpath:
> http://www.rpath.com/product/rpath-cloud-engine.php
> I think it could cut it.

Id completely avoid rpath its way to proprietary....... vagrant rocks

>
> Personally, I think it would be great to extend DevCloud into a set of VMs (Manager, Cloudbridge and host) that we can deploy on vbox or KVM and the like to create a fully virtualized cloudstack infrastructure. We could use it as a testbed to "teach" cloudstack and experiment with the networking.
>
> -Sebastien Goasguen
> Apache Cloudstack evangelist.

Re: Update on wrapping DevCloud into a Vagrant Box

Posted by sebgoa <ru...@gmail.com>.
On Jul 12, 2012, at 4:32 PM, Chip Childers wrote:

> 2 - Does anyone have an alternate suggestion for how to achieve what I
> had hoped to achieve?

Hi Chip, I did not know about Vagrant, it sounds great, but if it does not work you might want to check out rpath:
http://www.rpath.com/product/rpath-cloud-engine.php
I think it could cut it.

Personally, I think it would be great to extend DevCloud into a set of VMs (Manager, Cloudbridge and host) that we can deploy on vbox or KVM and the like to create a fully virtualized cloudstack infrastructure. We could use it as a testbed to "teach" cloudstack and experiment with the networking. 

-Sebastien Goasguen
Apache Cloudstack evangelist.