Merge lp://staging/~lifeless/pyjuju/bug-945505 into lp://staging/pyjuju

So, it's a little perverse putting ip_address in an attribute named dns_name but it's what I do with the openstack provider too.

Having this as a flag-day revision rather than continuing with the old behaviour for previous txaws releases I'm a bit wary of, given the lack of a txaws release that actually includes the required change.

Updating juju/machine/__init__.py or at least the comment there would be good.

Actually txaws 0.2.3 includes ipAddress.

Confusing, is there any record of when 0.2.3 was released or what changes it contains? I'm failing via the normal methods of looking at the release page, tags on the branch, log of when the version was changed... some means other than inspecting the tarball?

I'm -1 on changing this as suggested. If a DNS name is available, it should be provided instead of the IP address, and we shouldn't be changing such an API without better reasoning. What's breaking at the moment? Do we have cases where the DNS name does not exist? If so, we could fallback to the IP adddress.

this appears to be a common issue with private with private clouds where
the dns given is invalid outside of the cloud network, ie. not pubilcly
accessible dns names. which is problematic even connecting juju client to
the env.

-k

On Tue, Jun 26, 2012 at 1:07 PM, Gustavo Niemeyer <email address hidden>wrote:

> The proposal to merge lp:~lifeless/juju/bug-945505 into lp:juju has been
> updated.
>
> Status: Needs review => Work in progress
>
> For more details, see:
> https://code.launchpad.net/~lifeless/juju/bug-945505/+merge/111754
> --
> https://code.launchpad.net/~lifeless/juju/bug-945505/+merge/111754
> You are subscribed to branch lp:juju.
>

I'm instinct is that if the API is reporting a public DNS name that is not public, that isn't an issue with juju. We could argue equally that the public IP may well be private too, and be inaccessible.

I'm happy to understand more about the use case, though. Who can I talk to that is having this issue right now?

the bug reporter, there are a few others who have similiar issues as well..

On Tue, Jun 26, 2012 at 1:24 PM, Gustavo Niemeyer <email address hidden>wrote:

> I'm instinct is that if the API is reporting a public DNS name that is not
> public, that isn't an issue with juju. We could argue equally that the
> public IP may well be private too, and be inaccessible.
>
> I'm happy to understand more about the use case, though. Who can I talk to
> that is having this issue right now?
>
> --
> https://code.launchpad.net/~lifeless/juju/bug-945505/+merge/111754
> You are subscribed to branch lp:juju.
>

> the bug reporter, there are a few others who have similiar issues as well..

Okay, so hopefully we'll hear from him.

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

Thanks Rob.

I'm copy & pasting this to the bug and following up there.