4

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?

1 Answer 1

1

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.

1
  • Quite long time since you posted this, but I'm currently facing the exact same problem (DNS, floating ip and proxies). It might be quite common for any private cloud in corporate environment. Did you find any solution to the proxy?
    – gdupont
    Jul 25, 2017 at 16:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .