Running juju against a private openstack instance.

My laptop has somewhat less than 1/2 the grunt of my desktop at home, but I prefer to work on it as I can go sit in the sun etc, very hard to do that with a mini tower case 🙂

However, running everything through ssh to another machine makes editing and iterating more clumsy; I need to do agent forwarding etc – not terribly hard, but not free either, particularly when I travel, I need to remember to sync my source trees back to my laptop. So I prefer to live on my laptop and use my desktop for compute power.

I had a couple of Juju charms I wanted to investigate, but I needed enough compute power to make my laptop really quite warm – so I thought, its time to update my local cloud provider from Eucalyptus to Openstack. This was easy enough, until I came to run Juju. Turns out that Juju’s commands really want to talk to the public DNS name of the instance (in order to SSH tunnel a connection to Zookeeper).

But! Openstack returns DNS names like ‘Server-3’, and if you think about a home network, its fairly rare to have a local DNS server *anyway*, so putting a suffix on names like that won’t help at all: you either need to use a DNS naming provider (openstack ships with an LDAP provider, which adds even more complexity), and configure your clients to know how to find it, or you need to use the public IP addresses (which default to the FlatNetwork, which is routable within a home LAN by simply adding a route to to your wifi interface). Adding to confusion, some wifi routers fail to forward avahi messages, which is a) terrible and b) breaks the only obvious way of doing no-config local DNS :(.

So, I did some yak shaving this morning. Turns out other folk have already run into this and filed a Juju bug and a supporting txaws bug. The txaws bug was fixed, but just missed the release of Precise. Clint Byrum is going to SRU it this week though, so we’ll have it soon. I’ve put a patch up to address the Juju side, which is now pending review. Running the two together works very happily for me. \o/


4 thoughts on “Running juju against a private openstack instance.

  1. Hello, I’m not that sure that I understand your problems right, but…

    It looks like you need IPv6 on your machines and net. Then you will have a public address to all your machines without worry about NAT etc. You should still use dual stack, of course, but the IPv4 part should only be done by your vistiors/customers on the deployed machine(s).

    Hope it is a possible sollution for your problem.

  2. Thanks for the suggestion. The issue is DNS resolvability not the public/privateness of the address range. So, I’d still need the same patch to work with IPv6 (and would need to port Juju to IPv6 awareness too (it may work already, I just haven’t tested it and don’t know anyone who has).

    1. Sorry for this late, late, late responce.

      As your IPv6 addresses are global, they are easy to put into DNS that your infrastructure uses, like in your Laptop/Desktop machine. Or, not as good, in a global DNS that you rent.

      You should always have two sets of DNS:es. One or more recursive for your internal machines to use for internal information about your machines, only used internally. Then a couple of (more than two on different sites, read RFC:s) none recursive DNS:es where you publish external public information you want all others to see about your services and where they are located. That could be a subset of the internal DNS and then some more. But usually it will be less information if you uses a true subset for the external public DNS.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s