Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

I'm seeing a number of problems trying to use Juju with our internally deployed Openstack cloud. Most of this appears to be centered around DNS host resolution as well as the need to deal with our company's internal HTTP proxies.

Our Openstack deployment relies upon an unroutable 172.16.0.0/12 block of addresses for VLAN allocation to each project (tenant) hosted on our internal cloud. User's have the option of assigning one or more floating addresses to instances, allocated from a block of routable addresses on our internal companies LAN.

Currently, Openstack doesn't register instance names with anything other than the DNSMASQ service running on the cloud controller. As such, there's no way to resolve this address through our internal DNS hierarchy (this issue has already been reported as Bug #945505). As such, even though I can bootstrap my Juju server node, I can't connect to it with the Juju client, since it can't resolve the local (private) network name. I am able to ssh to the node, once I've assigned it an internally routable (i.e. floating) address. Which leads to the next issue.

Next, to install software on an instance running in our cloud, it must have our internal proxy address defined - either in the apt.conf file or via environment variables. Unfortunately, when bootstrapping the server node, there's no provision to pass this info into a instance via JuJu environment.yaml file (if this is even the best way to handle this issue). As a result, the bootstrap node is unable to install the required packages.

I'm assuming (dangerous, I know) that the way that I've deployed Openstack in our internal environment is probably not unique. Has anyone else encountered these issues? And more importantly, are work arounds available?

share|improve this question
add comment

1 Answer

After deploying/bootstrapping, Juju will attempt to connect to the environment via the public address of the instances. AFAIK, it gets this address straight from EC2 API's describe_instance(s) call. In your environment, new instances spawn with an internal/private address and no public (floating) IP associated. The result is a private address in both the private and public address fields of describe_instances. After associating a floating IP to the instance, the public address field should now show the newly associated address.

Once its associated, Juju should be able to connect fine via SSH (just like you can). So, you should be able to 'juju bootstrap', associate IP to bootstrap node, 'juju status'. You'd need to also associate floating IPs to all other machines deployed. One option is to add the '--auto_assign_floating_ip' to nova.conf, so that floating IP association happens automatically on instance spawn.

As for the proxy-to-apt issue, it would be great if Juju allowed users to customize the cloud-config that gets passed to new nodes for bootstrapping the Juju agents. If it was possible, you can configure your apt proxies alongside the juju-specific cloud-config. Since thats not currently supported, one option would be to publish a customized cloud image into Glance that contains a apt.conf for your environment, and set default-image-id in environments.yaml to that AMI ID.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.