Open Stack

Hi Ewan,

Thanks *a lot* for your very accurate and long reply. That's going to
help me so much for working on the Nova + XCP packaging in Debian.

On 01/24/2012 06:19 AM, Ewan Mellor wrote:
>> I already started writing a README.xcp_and_openstack to document how to
>> do an Openstack + XCP setup.
> 
> Thanks for doing this!  Your hard work is very much appreciated.

I'm happy if I can do my part of the job too! :)

>> But would the VLan manage work? Also, should I use openvswitch? If yes,
>> how does this work?
> 
> Flat, VLAN, and the various HA modes should all work.
> Flat is by far the simplest for getting started with though.

My final goal is to be able to resell Openstack cloud instances, and in
that case, only VLAN is the way to go, IMO.

> Open vSwitch would be a good idea. It's what we use on XenServer 6.0 onwards,
> so it's well tested.

Very cool! That is, I believe, the best way you could have taken.

> Is it packaged for Sid?

Yes:
http://packages.debian.org/search?keywords=openvswitch

> If you have the Open vSwitch components installed in domain 0, then there
> are a few scripts that wrap around it to set up the isolation rules used
> in flat mode.  These are in nova/plugins/xenapi/networking.

I believe you mean: plugins/xenserver/networking

Nova in Debian now creates a nova-xcp-plugins taking files from
plugins/xenserver/xenapi/. I now believe that I should also make a
nova-xcp-network package.

Having a quick look at the files in the plugins/xenserver/networking
folder, these would need some re-work. For example, the init.d scripts
are lacking LSB headers (to be used by insserv for parallel booting),
and also there's an etc/sysconfig, which really, is too much CentOS /
RedHat centric (in Debian, it would go in /etc/default).

Now, I saw files in etc/xensource/scripts. I suppose that these, in
Debian, to respect both FHS and the work we've done with Mike and Jon,
these files should go in /usr/lib/xcp/scripts/. I just hope there's no
references to the wrong CentOS path in these scripts! If you know things
that should be adapted right away, it'd be great to have the fixes made
for runtime, rather than a Debian specific patch, IMO, because patches
are annoying to maintain.

You can expect that I will contribute these adaptations for Debian in
the next following days, and also fix the packaging to add this new
nova-xcp-network binary package.

I will let you know how it goes.

>> Does OpenStack + XCP still use nova-network? Is all traffic for the VMs
>> routed through it as with KVM and libvirt? Should I still create a
>> bridge on the nova-network domU?
> 
> It depends on which network mode you're using.  If you're using the
> HA modes, then yes, traffic goes through nova-network.  In flat mode
> it will come directly to domain 0 and the vSwitch.

And using the VLAN manager?

> Devstack has all of the domU setup for HA networking
> -- see https://blueprints.launchpad.net/nova/+spec/xenapi-ha-nova-network.

I've always been directed to devstack, however, I'm really not
interested at all in using it: I'm working on packaging things correctly
for Debian, and as a consequence, I want to use *only* the Debian
packages that we produce. Of course, I'll keep updating and modifying
them until it works.

>> How does Openstack injects IP addresses in an XCP VM? Can this even be
>> done? 
> 
> It talks to an in-guest agent, typically. It writes it to XenStore, and
> then this is picked up by the agent inside the VM.

So, running the XCP software inside the VM is mandatory? If so, this
should change IMO, it's really not hosting provider friendly: customers
expect to take any AMI image, possibly from AWS, and run them on the
cloud, we can't force customers to use specific VM images for XCP.

>> Should I use dnsmaq on my nova domU?
> 
> I don't think you need it. There's a comment in devstack that says
> that the dnsmasq packages are needed for dhcp_release though, so
> you may want to make sure that you have that at least.

Not a pb then! I'll have it setup, if it's there and not used, it's not
a big deal.

> I'm not sure, but I think you're asking about this:
> http://docs.openstack.org/diablo/openstack-compute/admin/content/associating-public-ip.html.

Thanks, that's what I was looking for.

> Security groups have only recently been implemented for XenAPI:
> https://blueprints.launchpad.net/nova/+spec/xenapi-security-groups.
> That got merged less than two weeks ago.

Will this be in e3? FYI, I chatted with Ghe Rivero on IRC, who is also
working on nova packaging. His plan is that, in Debian, we will release
e3 in SID when e3 is out.

>> 2/ Images
>> What are OVF images? How to generate it? Where to download some?
> 
> http://en.wikipedia.org/wiki/Open_Virtualization_Format
> 
> They can be exported from XenServer using XenCenter. VMware have a
> tool too, but I expect that those that VMware generate won't work
> with OpenStack yet, because they'll use VMDK for the disk images,
> and I'd be surprised if OpenStack can handle that.

Since I asked, I understood it. Do you know if the OVF files exported by
VirtualBox would work? I think Virtualbox is the most easy tool on the
desktop, and I think many would be happy to use it to build OVH images.
It's also packaged in Debian, so that's an easy thing to recommend for
our users.

>> 3/ Console
>> on the same wiki page, it tells about using VNC. While this does work,
>> I
>> didn't have access to the login prompt. What's the way, if using
>> openstack, to tell that the console is hvc0 (or whatever is the Xen
>> console device name)?
> 
> That's dependent on the in-guest setup.  I think on latest Sid you'll need to have an entry in /etc/init/hvc0.conf, similar to this:
> 
> start on stopped rc RUNLEVEL=[2345]
> stop on runlevel [!2345]
> 
> respawn
> exec /sbin/getty -L hvc0 9600 linux

This is an upstart script, that's really not for Debian, but for Ubuntu!
I can adapt it, however, the issue is that images that we find on the
net wont have this by default. So, I thought that best would be to have
added, automatically by XenServer / XCP, a parameter on the command like
like: tty1=hvc0 (or similar), so that such thing wouldn't be needed. Any
thoughts?

>> Then, what's the normal way to access to the console, without using
>> such
>> hack (eg: customers obviously, wouldn't have ssh access to the dom0 in
>> order to do port forwarding)?
> 
> Anthony Young at Rackspace has recently reworked all of this.
> It should be the same on XenAPI and KVM now.
> https://review.openstack.org/#change,2949. That went in last week.

Cool. I'll have a look to the latest version of Nova in Git then, and
use our weekly snapshot that we release in Experimental (or maybe, just
the e3 packages...).

>> For the moment, I have this:
>>
>> root at GPLHost:openstack>_ ~# euca-get-console-output i-00000002
>> i-00000002
>> 2012-01-12T16:53:09Z
>> FAKE CONSOLE OUTPUT of instance
>>
>> I'd like to have something better than a "FAKE CONSOLE"! :)
> 
> That still needs to be implemented.  Now that Anthony has done
> a lot of the heavy lifting on the VNC console side, getting text
> consoles done too shouldn't be too hard.

I'll be looking forward this happens then! Let's hope it's going to be
finished for the e release, and Wheezy.

Thomas Goirand (zigo)