1

Update:

More investigation shows that the LXC containers were not getting IPs during install.

But if left for several hours the LXC containers do eventually get an IP from the MAAS.

So this morning I took the Cluster and moved it from a very expensive L3 Cisco switch onto a cheap L2 Dell switch. DHCP addresses are obtained instantly by all LXC containers and the Openstack Installer completed without a single hitch. Probably some sort of configuration setting we need to make on the Cisco switch but for the time being we'll be keeping the network simple whilst we play around with the software in our lab.

Lots of time spent on this rather irritating and odd issue! Many thanks for your efforts.

We have a 5 node stack of machines which are configured in MAAS.

They come up and down just fine however deploying Ubuntu's Openstack Autopilot fails with:

./cloud-install/commands.log:

http://paste.ubuntu.com/10676002/

machine-0.log:

2015-03-24 16:49:19 ERROR juju.worker runner.go:219 exited "api": unable to connect to "wss://localhost:17070/"
2015-03-24 16:49:22 ERROR juju.rpc server.go:554 error writing response: EOF
2015-03-24 16:49:45 ERROR juju.state.unit unit.go:665 unit apache2/0 cannot get assigned machine: unit "apache2/0" is not assigned to a machine
2015-03-24 16:49:45 ERROR juju.state.unit unit.go:665 unit apache2/0 cannot get assigned machine: unit "apache2/0" is not assigned to a machine
2015-03-24 16:49:50 ERROR juju.state.unit unit.go:665 unit haproxy/0 cannot get assigned machine: unit "haproxy/0" is not assigned to a machine
2015-03-24 16:49:50 ERROR juju.state.unit unit.go:665 unit haproxy/0 cannot get assigned machine: unit "haproxy/0" is not assigned to a machine

-- More logs

From the juju bootstrap machine:

/var/log/juju/all-machines.log

http://paste.ubuntu.com/10724991/

I can't figure this out, it's just showing the below over and over again until it fails:

machine-0: 2015-04-02 13:50:10 INFO juju.worker runner.go:261 start "api"
machine-0: 2015-04-02 13:50:10 INFO juju.api apiclient.go:252 dialing "wss://localhost:17070/"
machine-0: 2015-04-02 13:50:10 INFO juju.api apiclient.go:260 error dialing "wss://localhost:17070/": websocket.Dial wss://localhost:17070/: dial tcp 127.0.0.1:17070: connection refused
machine-0: 2015-04-02 13:50:10 ERROR juju.worker runner.go:219 exited "api": unable to connect to "wss://localhost:17070/"
machine-0: 2015-04-02 13:50:10 INFO juju.worker runner.go:253 restarting "api" in 3s

Not sure if this is related but I have a working deployment in a different lab and the only difference I see is that is that in the non-working lab on the juju boostrap node in /var/lib/juju/agents/machine-0/agent.conf the value SECURE_STATESERVER_CONNECTION: "true" is set and the version is 1.22.0.

On the working environment SECURE_STATESERVER_CONNECTION: "true" is missing and the version is 1.21.3.

Improve this question
8
  • 1
    It gave up after reaching the timeout. Can you check if, while the deployment is happening, if the maas nodes are being powered on and if they seem to be installing things? Even better would be to try to drive MAAS directly with juju first and see that works: maas.ubuntu.com/docs1.7/juju-quick-start.html It's also much easier to debug. – Andreas Hasenack Mar 25 '15 at 13:23
  • From what I understand one of the nodes is powered up and Juju is deployed on it. Various LXCs are spun up on that node and Juju attempts to deploy landscape on those. It seems to hang somewhere there and never gets to the stage where it starts powering on any other MAAS nodes. I believe that happens once you click Install in the Landscape Autopilot wizard. – Leon Roy Mar 25 '15 at 15:00
  • Try grabbing the unit logs in /var/log/juju/ from the bootstrap node and the containers (I think the directory in the bootstrap node has the containers' logs too) and make them available somewhere, or inspect them. When the installation fails with a timeout at this early stage, it's usually something network related. – Andreas Hasenack Mar 25 '15 at 18:38
  • hi andreas, scanning through all-machines.log and lxc-monitord.log I'm at a loss as to the issue. Any insight from the logs given would be appreciated. – Leon Roy Mar 31 '15 at 23:35
  • Are you sure paste 10715336 is from all-machines.log? I suggest to paste all logs from /var/log/juju/. You could also try to provision nodes in MAAS directly with juju instead of going through the cloud installer, it should be easier to debug if the problem still happens (maas.ubuntu.com/docs1.7/juju-quick-start.html) – Andreas Hasenack Apr 1 '15 at 12:41
1

I'll add a general answer here that could help others.

When encountering such issues, where it's not clear what is failing, the general suggestion is to go simple.

In this case, try to provision nodes in MAAS directly with juju instead of going through the cloud installer. It should be much easier and faster to debug.

This URL has instructions on to use juju with MAAS directly: https://maas.ubuntu.com/docs1.7/juju-quick-start.html

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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