Juju deploy wordpress fails with MaaS

Bug #1629113 reported by Mike
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
juju-core
Expired
Undecided
Unassigned

Bug Description

When attempting to deploy the wordpress charm a node is properly allocated by MaaS but it seems like the juju agent is never properly installed on the machine and it eventually times out leading to Failed deployment in the MaaS GUI.

MAAS Version 1.9.4+bzr4592-0ubuntu1 (trusty1)
Juju - 1.25.6

The machine hosting MaaS and Juju is running 14.04.5 LTS

Mike (krispyclean)
description: updated
Revision history for this message
Mark Brown (mstevenbrown) wrote :

Hi, could you please add the location of the charm being used (it will look similar to https://jujucharms.com/wordpress/trusty/4 or cs:trusty/wordpress-4) ?

Also, the output of "juju status" when this occurs would be helpful.

Revision history for this message
Mike (krispyclean) wrote :

Hey Mark,

Please see below:

cs:trusty/wordpress-4

sdn@ubuntu-openstack1:~$ juju status --format tabular
[Services]
NAME STATUS EXPOSED CHARM
juju-gui unknown true cs:trusty/juju-gui-135
wordpress unknown true cs:trusty/wordpress-4

[Units]
ID WORKLOAD-STATE AGENT-STATE VERSION MACHINE PORTS PUBLIC-ADDRESS MESSAGE
juju-gui/0 unknown idle 1.25.6.1 0 80/tcp,443/tcp soggy-temper.maas
wordpress/2 unknown allocating 3 tremendous-yarn.maas Waiting for agent initialization to finish

[Machines]
ID STATE VERSION DNS INS-ID SERIES HARDWARE
0 started 1.25.6.1 soggy-temper.maas /MAAS/api/1.0/nodes/node-6226861c-8404-11e6-8f32-0025903bdf32/ trusty arch=amd64 cpu-cores=4 mem=8192M availability-zone=default
3 pending tremendous-yarn.maas /MAAS/api/1.0/nodes/node-1a7c390a-8405-11e6-ae0e-0025903bdf32/ trusty arch=amd64 cpu-cores=4 mem=8192M availability-zone=default

sdn@ubuntu-openstack1:~$

It gets stuck in this state and finally after about 20-30 minutes in MaaS I see that the node failed commissioning. It looks like MaaS properly allocates the node and it goes through the install process but it seems like after executing late commands and finishing "curtin command install" it just sort of times out or the juju agent does not come up on the node where the charm was deployed to.

Thanks!

affects: juju → juju-core
Changed in juju-core:
status: New → Triaged
importance: Undecided → Critical
milestone: none → 1.25.7
Changed in juju-core:
milestone: 1.25.7 → 1.25.8
Curtis Hovey (sinzui)
Changed in juju-core:
milestone: 1.25.8 → 1.25.9
Curtis Hovey (sinzui)
Changed in juju-core:
milestone: 1.25.9 → 1.25.10
Curtis Hovey (sinzui)
Changed in juju-core:
milestone: 1.25.10 → none
Changed in juju-core:
milestone: none → 1.25.11
Revision history for this message
John A Meinel (jameinel) wrote :

If MAAS is failing to get the node to a Deployed state, then it isn't getting the machine to the point where it is telling Juju it is ready for us to use the machine.
It would seem that you were able to "juju bootstrap" or you wouldn't have been able to try to deploy anything. Which sounds like we're able to provision machines at least some of the time. Could it be a problem with the specific machine you're trying to provision?

Are you able to use MAAS tools to bring the machine up in isolation without Juju in the mix?

Are you able to evaluate if Juju 2.* would work in this situation. 1.25 is in support-only mode at this point.

Changed in juju-core:
status: Triaged → Incomplete
Changed in juju-core:
milestone: 1.25.11 → none
importance: Critical → Undecided
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for juju-core because there has been no activity for 60 days.]

Changed in juju-core:
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.