On Jan 31, 2014, at 12:25 PM, chris snow <chsnow...@gmail.com> wrote:

> I finally got the packer built devcloud box to boot with vagrant, but
> running 'xe vm-list' in it results in:
> 
> Error: Connection refused (calling connect )
> 
> I'm going to do some more investigation, but could take a while as I
> get to learn xen.
> 
> To make things easy while working on this I've created a github project here 
> [2]
> 

I cloned it, the packer builds works and the vagrant export as well.
I was able to vagrant up/ssh.

I noticed couple things.

1-the Xen setup. Check Rohit's blog http://bhaisaab.org he has a section on DIY 
Devcloud, where he shows how to setup Xen, namely xapi toolstack and creating a 
echo plugin.I think that's what you are missing, you can probably add this to 
your posinstall script

2-We switched master to java 7, so you should switch to openjdk-7

3- you might be missing a mysql-python-connector package and you should setup 
the mysql password as null (for dev).

This is looking quite nice :)

> I've added the problem above as an issue on github.
> 
> ---
> [1] https://wiki.openstack.org/wiki/XenServer/VirtualBox#Installing_XCP
> [2] https://github.com/snowch/devcloud
> 
> On Thu, Jan 30, 2014 at 7:18 AM, Rohit Yadav <rohit.ya...@citrix.com> wrote:
>> On Thu, Jan 30, 2014 at 4:14 AM, Sebastien Goasguen <run...@gmail.com> wrote:
>>> 
>>> On Jan 29, 2014, at 1:57 PM, chris snow <chsnow...@gmail.com> wrote:
>>> 
>>>> I have started thinking about some options:
>>>> 
>>>> 1)  use packer to convert the devcloud2 veewee definition as a starting 
>>>> point
>>>> 2) create devcloud3 from scratch
>>>> 3) start with an existing packer definition (e.g. [1])
>>>> 
>>>> Do you have a view on which option may be most suitable?
>>>> 
>>> 
>>> My view would be to start from scratch but of course looking at what has 
>>> been done.
>>> 
>>> In an ideal world, I would love to see a packer/vagrant file that would do:
>>> 
>>> -Ubuntu and CentOS
>>> -Xen and KVM
>>> 
>>> That way we can decide on what to build. Of course there might be issues 
>>> due to the PV/HVM support in vbox and the OS chosen.
>>> I don't recall what the issue was that made Rohit use Debian (but see 
>>> http://bhaisaab.org/logs/devcloud/), but ideally it would be good to use 
>>> stock ubuntu 12.04 or 13.04
>> 
>> DevCloud is just an appliance that facilitates a virtual host
>> (hypervisor) for development with CloudStack. So, I chose Debian
>> because well it's the best in terms of packages, stability, security
>> and is usually rock solid. Ubuntu at the time had a networking issue
>> that did not let me use xenbr0 for use over host-only network, I did
>> not invest much time on it but rather switched to Debian.
>> 
>> I suggest we stick to Debian as it would be least painful for anyone
>> IMO and the problem we're trying to solve is to enable developers have
>> a robust (possibly multi-vm) hypervisor host in box (vm) over a
>> desktop virtualization platform (virtualbox, kvm etc.)
>> 
>> (IMHO -- I wonder if you've tried latest rock-solid Fedora 20, Ubuntu
>> should have been least recommended distro by now don't use it please).
>> 
>>> I list 13.04 because there seems to be an issue with libvirt in 12.04 in 
>>> the case that you want ceph 
>>> (http://ceph.com/docs/master/rbd/rbd-cloudstack/). Of course ceph on a 
>>> single node does not make sense, but for a devcloud3 setup we could imagine 
>>> setting up ceph in it and use it as primary storage.
>> 
>> Why not build libvirt version we want? In case we want to stay updated
>> I can help you with Fedora 20 based base or Arch based base for
>> devcloud. I've been using Fedora for some months now and I guess if
>> someone want latest and greatest but want to avoid a lot of sysadmin
>> work as with Arch Linux just go with Fedora. Linux users (new and old)
>> have more or less been inclined to Debian because yum-based distros
>> were in really bad shape few years ago and that's when like others I
>> shifted to using Ubuntu. But it's not the case anymore and Ubuntu has
>> tons of problems now and rpm-based distros deserver one shot.
>> 
>>> 
>>> I mention KVM because if one uses VMware workstation than KVM would be an 
>>> option.
>>> 
>>> What I am doing these days is taking a veewee bare definition and using 
>>> veewee-to-packer to get started with packer. I install chef/salt/puppet 
>>> agents in the image so that I can use the 3 of them if I want to.
>>> 
>>>> If we go with option 2 or 3, do you think debian 7.0 should be used as
>>>> a starting point, or another version such as 7.2 or 7.3?  Or even
>>>> another distro?
>> 
>> Feel free to choose whatever distro gives us all the tools and whatnot
>> to solve our problem. Distros and tools are not the problem having a
>> host in a box for CloudStack development is the problem.
>> 
>>>> 
>>>> Are these goals still valid for devcloud3?
>>>> 
>>>> - Two network interfaces, host-only adapter so that the VM is
>>>> reachable from host os and a NAT so VMs can access Internet.
>> 
>> This I guess will be most appreciated and useful for developers,
>> probably first time users and for demo. Last time for some reason, I
>> was unable to have Internet reach VMs inside DevCloud.
>> 
>>> 
>>> Yes
>>> 
>>>> - Can be used both as an all in one box solution like the original
>>>> DevCloud but the mgmt server and other services can run elsewhere (on
>>>> host os).
>> 
>> This already works with last DevCloud.
>> 
>>> 
>>> Yes
>>> 
>>>> - Reduce resource requirements, so one could run it in 1G limit.
>> 
>> +1 though I think size is not a major issue and reduce image size is a
>> good to have thing.
>> 
>>> 
>>> Would be great, but remember that systemvm and ttylinux will run within it, 
>>> so those 4 alone may use 1G
>>> 
>>>> - Allow multiple DevCloud VMs hosts.
>> 
>> +1
>> 
>>> 
>>> That would be great. Having some skeleton for multiple devcloud hosts in a 
>>> vagrant file so we can deploy "full" clouds.
>>> 
>>>> - x86 dom0 and xen-i386 so it runs on all host os.
>>>> - Reduce exported appliance (ova) file size.
>>>> - It should be seamless, it should work out of the box.
>> 
>> +1
>> 
>> Chris, appreciate you taking time working on this.
>> 
>> Regards.
>> 
>>> 
>>> yes
>>> 
>>>> 
>>>> Are there any new requirements in addition to the ones discussed in
>>>> this email chain, e.g.
>>>> 
>>>> - vagrant support (in addition to the ova/ovf image)
>>>> - packer and vagrant build environment
>>>> 
>>> 
>>> In simstack https://github.com/runseb/simstack I am trying to provide 
>>> chef/salt/puppet recipes for the install. So in devcloud3, I would lay 
>>> things out so that we can also do those 3 cfg mgt system in the future. 
>>> Note that simstack is not devcloud as I am trying to run the simulator and 
>>> have to compile from source because there is no simulator package.
>>> 
>>>> 
>>>> Many thanks,
>>>> 
>>>> Chris
>>>> 
>>>> 
>>>> [1] https://github.com/opscode/bento/tree/master/packer
>>>> 
>>>> On Wed, Jan 29, 2014 at 2:25 PM, Sebastien Goasguen <run...@gmail.com> 
>>>> wrote:
>>>>> 
>>>>> On Jan 29, 2014, at 8:49 AM, Rohit Yadav <bhais...@apache.org> wrote:
>>>>> 
>>>>>> Thanks for stepping in. That is much needed, in fact I think we should
>>>>>> use something like packer alongwith vagrant/veewee for both devcloud
>>>>>> and systemvmtemplate. Veewee can build vms, packer can export them to
>>>>>> various platforms/formats and a developer could use vagrant for local
>>>>>> devcloud/host automation.
>>>>>> 
>>>>> 
>>>>> I looked into it the other day and I agree we need to revamp this.
>>>>> 
>>>>> veewee development and maintenance is going to stop. So we need to prep a 
>>>>> packer version
>>>>> 
>>>>> So yes we should create a packer definition for devcloud3 :) and be able 
>>>>> to post-process it to vagrant.
>>>>> 
>>>>> 
>>>>> 
>>>>>> Regards.
>>>>>> 
>>>>>> On Wed, Jan 29, 2014 at 1:30 AM, chris snow <chsnow...@gmail.com> wrote:
>>>>>>> I would like to build the devcloud2 image [1] from scratch using
>>>>>>> veewee (or packer) and turn it into a vagrant box.
>>>>>>> 
>>>>>>> There seems to be several versions of Vagrant files and veewee
>>>>>>> definitions in the code base, making it difficult to know which one to
>>>>>>> start from, or whether they are still valid.
>>>>>>> 
>>>>>>> Many thanks,
>>>>>>> 
>>>>>>> Chris
>>>>>>> 
>>>>>>> [1] http://bhaisaab.org/logs/devcloud/
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Check out my professional profile and connect with me on LinkedIn.
>>>> http://lnkd.in/cw5k69
>>> 
> 
> 
> 
> -- 
> Check out my professional profile and connect with me on LinkedIn.
> http://lnkd.in/cw5k69

Reply via email to