Code review comment for lp:~lifeless/pyjuju/bug-945505

You can talk to me, you can talk to everyone using canonistack. I'd be
delighted to step you through whats going on, including exactly what
private openstack instances hand out and what the challenges are. I
will note that Martin Packman has used IP in the openstack provider
*for exactly this reason*. So if you are -1 on this proposal because
of the way it uses DNS, it would be consistent to be -1 on the
openstack provider for the same reason.

This is whats going on - I thought I detailed it elsewhere already,
but apparently not :)

Openstack hands out DNS entries of the form 'Server-N' (see Ted
Gould's post to canonical-tech, for instance). for *both* its public
and private dns entries.

Thats not resolvable at all, unless you manually expose dnsmasq on
your nova-network controller *and* add that as your primary DNS
server. Which won't work at all when dealing with multi-region
openstack.

It is extensible by writing a custom 'public dns api provider' for
nova, which brokers DNS names, either setting them to be like the ec2
ones (which embed the IP address in them so that amazon can bulk-load
their entire zone at once for a region), or letting you do arbitrary
custom funky stuff like using an LDAP backed DNS server. There is no
sensible-default shipped, or (that I know of) publically available.
Certainly a helper for bind to do amazon's trick would be useful for
folk, but not very useful for people that throw maas at 5 machines
under their desk and bring up openstack on top of that.

The private dns name isn't extensible at all today. And its also just
'server-N' not 'server-N.$customzone'. euca-describe-instances for
canonistack, for instance:
INSTANCE i-00000080 ami-000000bf server-128
server-128 running 0 m1.small
2012-06-27T03:09:18.000Z nova
monitoring-disabled 10.55.63.14 10.55.63.14
instance-store

Note that the only way to tell that this is canonistack2 vs
canonistack1 is the ip address.

This gets worse though (and my patch doesn't help with the next bit -
though its on my list (to let juju ssh $unit work for private
openstack clouds): The machines themselves report hostnames that are
only resolvable within the cloud itself without special configuration:
'server-128.canonistack2' (hostname == server128', but unless you have
specially configured DNS (or for Canonistack users, ~/.ssh.config),
thats not resolvable at all.

Using IP addresses would provide a single point to configure to let
this work, and work with vpns, ssh etc with equal ease. I don't think
the same can be said for dns.

-Rob