openstack team mailing list archive

[Adam Gandelman <adamg@xxxxxxxxxxxxx>]

On 05/03/2012 06:25 PM, Jorge Luiz Corrêa wrote:
> Hi!
>
> 2) Pointing the host running juju to use the dnsmasq from nova-network 
> is a solution. It's working. From where is it recommended to run juju? 
> From an external host? The problem is that when I run juju it tries to 
> connect to a name like server-12, server-13 … these names just make 
> sense inside the cloud. So, for that, I presume juju must be ran from 
> a host inside the cloud. Or not? Making automatic assign of floating 
> ip makes juju connect to the external IP?

This would work if it can be assumed that the Juju client is on the same 
internal network as the instances. In most cases, the user of the Juju 
client will be issuing the commands from her laptop outside of the cloud 
(imagine EC2, against which the initial Juju work flow was developed). 
Juju uses boto to call the EC2 API and find out the details of instances 
running in its environments. A call to 'juju ssh 0' or 'juju mysql/0' 
translates to a call to describe-instances, and an attempt to ssh to the 
public hostname of the instance described. As I said, by default, new 
nova instances have the private, internal hostname (or IP), associated 
with the instance in both the public and private hostname fields. It's 
not until you associate a public floating IP that Juju knows how to 
access the instance from outside the cloud. So, for the typical use case 
of an outside consumer of Juju and your cloud wanting to contact 
instances, the 'auto_assign_floating_ip' flag should be set. If you're 
running Juju as a client from within instances, you can skip this and 
have Juju address the instances directly at their private hostname (with 
the dns redireting) but this is not the typical use case (so far)

HTH,
Adam