[SOLVED] Creating a controller with Juju on Openstack

This post is linked to this one Use Juju on top of OpenStack to deploy apps

After I have added the new cloud with its credential and created the cloud image with this guide Cloud image metadata, it’s time to make the bootstrap. As reports the debug it creates the Instance on openstack and its Security Group .

But when it tries to connect that, the ssh failed:

Attempting to connect to 10.1.0.12:22
21:50:37 DEBUG juju.provider.common bootstrap.go:575 connection attempt for 10.1.0.12 failed: ssh: connect to host 10.1.0.12 port 22: Connection timed out
21:50:37 DEBUG juju.provider.common bootstrap.go:575 connection attempt for 10.1.0.12 failed: ssh: connect to host 10.1.0.12 port 22: Connection timed out

Is there a way to set my security groups during the bootstrap? If I use Openstack to create the instance using that I can reach that without problem.

Is it possible you need to pass --config use-floating-ip=true to bootstrap?

3 Likes

Already done, also with Floating IP I receive the same error.

Now I’ve a doubt/question, but to use JUJU on Openstack I’ve to use the physical node used for MAAS and where I’ve installed JUJU for the deploying of Openstack?.
Or I’ve to create a new Instance on Openstack and proceed with the installation of a new JUJU environment??.

@riccardo-magrini Sounds as networking problem. Is 10.1.0.12 accessible from the machine from which you are trying to bootstrap? When bootstrapping Juju will send a request to the OpenStack instance eg http://10.20.81.22:5000/v3 in your case which is on 10.20.81.0/24 network but the created instance will be on 10.1.0.0/24 network (OpenStack private network, I’m assuming, I don’t know your network topology) to which Juju will try to ssh in order to set up the controller.

It would be helpful if you could post an image of your OpenStack network topology and explain your or post a diagram of your infrastructure network eg the network on which you deployed OpenStack.

@schkovich The topology of my lab is the same shown in this post.
If I try to create a new Instance directly from Openstack, assign it an Floating IP and my security group, I can reach that via ssh from MAAS (10.20.81.1).

Today I’ve tried to make 2 think, the first one is make the bootstrap from MAAS (where I’ve installed JUJU and used it to deploy Openstack) and the second one using the same tasks on a new instance created on Openstack. In the both case the command using for the bootstrap is the following:

$: juju bootstrap openstack-cloud --bootstrap-series=bionic --config network="Private Network IPv4" --config external-network="Floating Network IPv4" --config use-floating-ip=true --metadata-source ~/simplestreams/images --debug

The debug of first case is that. Letting the command terminate without kill it on

21:18:03 DEBUG juju.provider.common bootstrap.go:575 connection attempt for 10.1.0.16 failed: ssh: connect to host 10.1.0.16 port 22: Connection refused
21:18:06 DEBUG juju.provider.common bootstrap.go:575 connection attempt for 10.20.81.227 failed: ssh: connect to host 10.20.81.227 port 22: No route to host

the error at the end is that:

21:22:20 ERROR juju.cmd.juju.commands bootstrap.go:596 failed to bootstrap model: subprocess encountered error code 1

and on Openstack it remove Instance and the security group. While using the same tasks on the second case, the debug reports that one and the error is that:

21:28:34 ERROR juju.cmd.juju.commands bootstrap.go:596 failed to bootstrap model: cannot start bootstrap instance: cannot set up groups: failed to create a security group with name: juju-03120d58-7a1e-42e2-857c-8344669ba2f5-e299f588-285d-4486-8217-bab4e6059678

OK, this is a completely different problem. What had happened to the controller with the IP 10.0.1.12?

In the first case the problem sounds to be here:

ERROR cannot read agent metadata in directory /var/lib/juju/tools/2.5.4-bionic-amd64: open /var/lib/juju/tools/2.5.4-bionic-amd64/downloaded-tools.txt: no such file or directory
2019-04-29 21:22:20 DEBUG cmd supercommand.go:496 error stack: 
cannot read agent metadata in directory /var/lib/juju/tools/2.5.4-bionic-amd64: open 
/var/lib/juju/tools/2.5.4-bionic-amd64/downloaded-tools.txt: no such file or directory

In regards to the second run, check if you reached the max number of security groups for the project. Even if you haven’t reached the limit, remove all security groups Juju created.

When bootstrapping, I would rather use network ids.

The test made yesterday has been made with a VPN connection, today I’m directly connected to my lab, I retry the same bootrap for both the cases.

In the first one the debug is different, here its result, the new instance created (juju-05862f-controller-0) has its own security group and I can’t reach it. Changing that with mine and reboot it, the instance is reachable.

ubuntu@os-compute04:~$ sudo ip netns exec qrouter-39c0a863-c306-4065-b7cf-d5fdeac7f2bc ping 10.1.0.13
64 bytes from 10.1.0.13: icmp_seq=1 ttl=64 time=0.574 ms
64 bytes from 10.1.0.13: icmp_seq=2 ttl=64 time=0.443 ms

ubuntu@os-compute04:~$ sudo ip netns exec qrouter-39c0a863-c306-4065-b7cf-d5fdeac7f2bc ping 10.20.81.227
64 bytes from 10.20.81.227: icmp_seq=1 ttl=64 time=0.666 ms
64 bytes from 10.20.81.227: icmp_seq=2 ttl=64 time=0.476 ms

While for other case the error is the same.

12:43:48 ERROR juju.cmd.juju.commands bootstrap.go:596 failed to bootstrap model: cannot start bootstrap instance: cannot set up groups: failed to create a security group with name: juju-32953f36-542e-483b-86a0-b362a38200ff-17687999-6cce-4be2-8a8a-ad19f85a6943

The max number of security group is only 6.

@schkovich Now this is the result of first case. After the bootstrap I’ve created a model and installed its gui:

$: juju gui
GUI 2.14.0 for model “admin/openstack-model” is enabled at:
https://10.20.81.227:17070/gui/u/admin/openstack-model
Your login credential is:
username: admin
password: xxxxxxxxxxxxxx

For the other case is still with that problem.

Thanks a lot for your support, also that one is done.

@schkovich I think it is a bug that we are not able to define a custom security group rather than default one when bootstrapping an openstack controller.