David, Sounds like a reasonable approach. I'll keep an eye out and test your patches.
-Adrian On Aug 30, 2011 9:45 AM, "David Alves" <davidral...@gmail.com> wrote: > HI Adrian > > The thing would be to run openstack inside a vbox managed by vagrant instead of having to interact directly with vbox. > You would then interact with openstack as you would with cloud servers. > Probably a lot slower, of course. > > Anyway I'm putting down some code, I'll create an issue so we can look at it. > > -david > > > > > On Aug 30, 2011, at 5:24 PM, Adrian Cole wrote: > >> Hi, all. >> >> What I've noticed is most openstack nova questions on the dev list come from >> those running a trunk and/or fork and/or patched version. We (dmitry >> mostly) test openstack and note whatever constraints there are on our doc >> page. As the Nova api is simple (and based on cloudservers api), these are >> always constraints in the specific build + patches in openstack. >> >> If what we want is vms on our laptops I doubt we need OpenStack for this, >> rather virtualbox or the like. However, virtualbox support in jclouds isn't >> yet complete, so we might consider a stop-gap. >> >> The way that I run tests that require setting up something on my local >> machine is using byon and the runScript stuff. >> >> You can use the runScript approach to install vbox, vagrant, eucalyptus, >> opennebula, cloudstack, openstack, lxc, or whatever you want. >> >> Then, depending on whether that system is jclouds enabled, you can either >> configure the provider endpoint or write a byon file. >> >> Probably, Andrea from jclouds can give some insight into vboxy stuff, too. >> >> Adrian >> On Aug 30, 2011 3:46 AM, "David Alves" <davidral...@gmail.com> wrote: >>> Hi Guillaume >>> >>> That is exactly the point. >>> The way I envision it would work like this: >>> >>> - A parent/base class boots a vagrant box (either pre-build to run >> openstack on configured just-in-time like most whirr deployments). >>> - The whirr test provider is configured to use openstack specifically at >> the address of the local vagrant box. >>> - Whirr tests spawn vms inside the vagrant vm. >>> - Tests are ran as any other tests (albeit probably a lot slower) >>> - When tests finish everything is disposed of. >>> >>> The main roadblock I can see is whether support for openstack in clouds is >> mature enough, but Adrian can probably answer this… Adrian? >>> >>> -david >>> >>> On Aug 30, 2011, at 11:14 AM, tog wrote: >>> >>>> Hi David, >>>> >>>> This is very interesting indeed for testing purpose ... >>>> Still I have some basic/naive questions. >>>> If I understand well what you are proposing is to be a able to >>>> kickstart your test platform (i.e. several vms) from a vagrant box. >>>> >>>> As whirr is working on top of jclouds which is supposed (I have not >>>> tested) to support openstack - wouldn't it be possible to kickstart >>>> your test environment using a kind of openstack provider >>>> (whirr.provider) using itself VirtualBox (or any other technology) ? >>>> >>>> What is is the pro/con of each approach ? >>>> >>>> Guillaume >>>> >>>> >>>> >>>> On Tue, Aug 30, 2011 at 2:44 PM, David Alves <davidral...@gmail.com> >> wrote: >>>>> Hi All >>>>> >>>>> Nice to see interest. >>>>> >>>>> What vagrant does is that it eases creation manipulation and >> provisioning of dev vms. >>>>> If inside one of these vms you run openstack then you have a local cloud >> where your initial vagrant box is running other vms inside. >>>>> >>>>> Andrei: Setting vagrant up to run openstack is feasible (i've done it) >> and there are several tutorials on how to do it. >>>>> >>>>> Still there are some important decisions/issues: >>>>> - Do we use a box pre-configured with open-stack or do we provision a >> base box (much like whirr already does). >>>>> - Ca we easily integrate vagrant with whirr (don't see any major >> problems but haven't tried). >>>>> - Will we have timeout issues? >>>>> >>>>> I can kickstart the effort but it would be cool to have someone else >> involved, as I'm a bit pressed for time at the moment. >>>>> >>>>> -david >>>>> >>>>> On Aug 30, 2011, at 9:04 AM, tog wrote: >>>>> >>>>>> Same questions here ;-) - and same confusion ! >>>>>> >>>>>> I thought that using openstack could for example solve that >>>>>> requirement (for example using Vbox). >>>>>> >>>>>> Has anyone tried this already ? Is there any show stopper ? >>>>>> >>>>>> Guillaume >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Aug 30, 2011 at 1:15 PM, Karel Vervaeke < ka...@outerthought.org> >> wrote: >>>>>>> I'm not sure I understand the concept... >>>>>>> Are you talking about running vms within your vm? (or, does the >>>>>>> openstack instance create sibling vm's? That probably implies that you >>>>>>> still run some openstack components locally). >>>>>>> >>>>>>> Why not just run openstack on your real (non-virtual) machine? >>>>>>> >>>>>>> I'm all confused :) >>>>>>> Karel >>>>>>> >>>>>>> On Tue, Aug 30, 2011 at 7:58 AM, Andrei Savu <savu.and...@gmail.com> >> wrote: >>>>>>>> It would be great to have a local test env - how hard is to setup >>>>>>>> vagrant to run openstack? >>>>>>>> >>>>>>>> -- Andrei >>>>>>>> >>>>>>>> On Mon, Aug 29, 2011 at 1:20 PM, David Alves <davidral...@gmail.com > >> wrote: >>>>>>>>> Hi All >>>>>>>>> >>>>>>>>> Have any of you considered using vagrant as a staging environment >> for development? >>>>>>>>> Would someone be interested in sharing some ideas putting some code >> down towards that goal? >>>>>>>>> >>>>>>>>> Here's what I'm thinking: >>>>>>>>> - Either create or script a vagrant box with openstack installed >> (there are several howtos to this effect). >>>>>>>>> - Create a base class that boots up the vagrant box prior to running >> ITests. >>>>>>>>> - Save time & money >>>>>>>>> >>>>>>>>> - Are there any big roadblocks? >>>>>>>>> >>>>>>>>> -david >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Karel Vervaeke >>>>>>> http://outerthought.org/ >>>>>>> Open Source Content Applications >>>>>>> Makers of Kauri, Daisy CMS and Lily >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> PGP KeyID: 2048R/EA31CFC9 subkeys.pgp.net >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> PGP KeyID: 2048R/EA31CFC9 subkeys.pgp.net >>> >
