juju fails to deploy with MAAS by default

[Robie Basak]

Verification needed, especially on amd64.

On armhf, running maas installed from quantal with everything as default, juju bootstrap succeeds as expected, but juju deploy fails.

Workaround: make the juju bootstrap node run quantal by changing default-series in environments.yaml to quantal, editing /etc/maas/import-pxe-files to download quantal images and re-running maas-import-pxe-files. However, then by default juju looks in the charm store for quantal charms and this has to be manually overridden.

juju 0.6-1ubuntu1
maas 0.1+bzr1264+dfsg-0ubuntu2

Version of juju on the bootstrap node: 0.5+bzr531-0ubuntu1.3

The error can be found on the bootstrap node in /var/log/juju/provision-agent.log:

2012-10-18 07:23:21,667: juju.agents.provision@ERROR: Cannot get machine list
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/juju/agents/provision.py", line 175, in process_machines
    provider_machines = yield self.provider.get_machines()
ProviderInteractionError: Unexpected TimeoutError interacting with provider: User timeout caused connection failure.
2012-10-18 07:23:27,451: juju.state.expose@DEBUG: Service 'ubuntu' is unexposed
2012-10-18 07:23:27,464: juju.state.expose@DEBUG: Service 'ubuntu' is unexposed
2012-10-18 07:23:27,465: juju.state.expose@DEBUG: Started watch of 'ubuntu' on changes to being exposed
2012-10-18 07:24:21,723: twisted@ERROR: Unhandled Error
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/twisted/application/app.py", line 402, in startReactor
    self.config, oldstdout, oldstderr, self.profiler, reactor)
  File "/usr/lib/python2.7/dist-packages/twisted/application/app.py", line 323, in runReactorWithLogging
    reactor.run()
  File "/usr/lib/python2.7/dist-packages/twisted/internet/base.py", line 1169, in run
    self.mainLoop()
  File "/usr/lib/python2.7/dist-packages/twisted/internet/base.py", line 1178, in mainLoop
    self.runUntilCurrent()
--- <exception caught here> ---
  File "/usr/lib/python2.7/dist-packages/twisted/internet/base.py", line 800, in runUntilCurrent
    call.func(*call.args, **call.kw)
  File "/usr/lib/python2.7/dist-packages/twisted/internet/tcp.py", line 362, in resolveAddress
    self._setRealAddress(self.addr[0])
  File "/usr/lib/python2.7/dist-packages/twisted/internet/tcp.py", line 369, in _setRealAddress
    self.doConnect()
  File "/usr/lib/python2.7/dist-packages/twisted/internet/tcp.py", line 395, in doConnect
    connectResult = self.socket.connect_ex(self.realAddress)
  File "/usr/lib/python2.7/socket.py", line 224, in meth
    return getattr(self._sock,name)(*args)
exceptions.TypeError: an integer is required

[Julian Edwards (julian-edwards)]

I've seen this happen on amd64 some time ago but could not recreate it lately, everything works out of the box. In fact, when it did happen, rebooting the bootstrap node seemed to fix it.

This needs more investigation, so setting to incomplete until we nail down exactly what's going on, because the bug title is not true as it stands but I don't know what to change it to.

[Julian Edwards (julian-edwards)]

I wonder if this is a bug in juju trying to deploy precise charms on quantal nodes?

[Diogo Matsubara (matsubara)]

I was unable to reproduce this using: maas - 0.1+bzr1264+dfsg-0ubuntu2 and juju - 0.6-1ubuntu1. I did:

$ juju boostrap --constraints="arch=arm"
$ juju deploy wordpress --constraints="arch=amd64 mem=0"
$ juju deploy mysql --constraints="arch=amd64 mem=0"

And after a long time (those arm nodes seem to take forever to bootstrap), I got everything deployed.

ubuntu@autopkgtest:~$ juju status
2012-10-19 23:54:22,012 INFO Connecting to environment...
2012-10-19 23:54:24,694 INFO Connected to environment.
machines:
  0:
    agent-state: running
    dns-name: node-fc2f40ec7340.local
    instance-id: /MAAS/api/1.0/nodes/node-d9844f5e-1a3c-11e2-bd17-525400123456/
    instance-state: unknown
  1:
    agent-state: running
    dns-name: node-00e081d1b147.local
    instance-id: /MAAS/api/1.0/nodes/node-d9d499aa-1a3c-11e2-803b-525400123456/
    instance-state: unknown
  2:
    agent-state: running
    dns-name: node-00e081ddd411.local
    instance-id: /MAAS/api/1.0/nodes/node-d99f1816-1a3c-11e2-803b-525400123456/
    instance-state: unknown
services:
  mysql:
    charm: cs:precise/mysql-8
    relations: {}
    units:
      mysql/0:
        agent-state: started
        machine: 2
        public-address: node-00e081ddd411.local
  wordpress:
    charm: cs:precise/wordpress-9
    relations:
      loadbalancer:
      - wordpress
    units:
      wordpress/0:
        agent-state: started
        machine: 1
        public-address: node-00e081d1b147.local
2012-10-19 23:54:24,923 INFO 'status' command finished successfully

[dann frazier (dannf)]

I can reproduce this w/ juju 0.5+bzr531-0ubuntu1.3 and maas 0.1+bzr1264+dfsg-0ubuntu2.
The problem persists with maas 0.1+bzr1269+dfsg-0ubuntu1 from proposed-updates. MAAS nodes are all armhf/highbank.

[Julian Edwards (julian-edwards)]

I think I know what's going on here.

Precise is being installed on the bootstrap node. It has the bug where you have to specify the port in the URL to the maas server. So when deploying, the provisioning agent, which is running the precise version code, will not work with the URL that worked fine with the fixed code used to bootstrap in the quantal client.

There are two workarounds:
1. add the port to the URL
2. Add:
juju-origin:ppa
to the environments.yaml file so that the bootstrap node uses a different (latest) version of the code.

[Martin Packman (gz)]

I don't understand from this bug report what the actual problem is or what specifically needs changing in juju.