juju deploy bundle does not honor existing machine definitions
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical Juju |
Fix Released
|
High
|
Tim Penhey | ||
OpenStack Charm Test Infra |
Invalid
|
Medium
|
Andrew McLeod | ||
juju-ci-tools |
Triaged
|
Medium
|
Unassigned | ||
juju-core |
Invalid
|
Undecided
|
Unassigned |
Bug Description
TL;DR juju deploy bundle will create additional machines for deployment rather than use the predefined machines. In our case we manually create the machines before a deployment in order to provide some customizations to those machines. Our main case is LXD and creating additional profile configs to allow for openvswitch, kvm, etc.
We expected to be able to add N machines, then customize them slightly before deploying a bundle with placements onto them - specifically we expected that a machine named “1” in a bundle would not be created anew if there was already a machine named “1” in the controller we’re deploying to.
This was the behavior from juju-deployer, see: http://
juju 2.0-beta3 does this instead:
ubuntu@
[Services]
NAME STATUS EXPOSED CHARM
[Units]
ID WORKLOAD-STATUS JUJU-STATUS VERSION MACHINE PORTS PUBLIC-ADDRESS MESSAGE
[Machines]
ID STATE DNS INS-ID SERIES AZ
ubuntu@
created machine 0
ubuntu@
created machine 1
ubuntu@
[Services]
NAME STATUS EXPOSED CHARM
[Units]
ID WORKLOAD-STATUS JUJU-STATUS VERSION MACHINE PORTS PUBLIC-ADDRESS MESSAGE
[Machines]
ID STATE DNS INS-ID SERIES AZ
0 started 10.0.3.68 juju-8d550d1f-
1 started 10.0.3.151 juju-8d550d1f-
ubuntu@
machines:
"1":
series: trusty
services:
mysql:
to:
- "1"
charm: cs:trusty/mysql-29
num_units: 1
series: trusty
ubuntu@
added charm cs:trusty/mysql-29
service mysql deployed (charm: cs:trusty/mysql-29)
created new machine 2 for holding mysql unit
# ^^^ this here is not what I wanted.
added mysql/0 unit to machine 2
deployment of bundle "machine-
ubuntu@
[Services]
NAME STATUS EXPOSED CHARM
mysql unknown false cs:trusty/mysql-29
[Relations]
SERVICE1 SERVICE2 RELATION TYPE
mysql mysql cluster peer
[Units]
ID WORKLOAD-STATUS JUJU-STATUS VERSION MACHINE PORTS PUBLIC-ADDRESS MESSAGE
mysql/0 unknown allocating 2 Waiting for agent initialization to finish
[Machines]
ID STATE DNS INS-ID SERIES AZ
0 started 10.0.3.68 juju-8d550d1f-
1 started 10.0.3.151 juju-8d550d1f-
2 pending pending trusty
tags: | added: conjure |
Changed in charm-test-infra: | |
status: | New → Confirmed |
tags: | added: native-deploy-gap |
Changed in juju-ci-tools: | |
status: | New → Triaged |
importance: | Undecided → Medium |
tags: | added: 4010 canonical-bootstack |
tags: | added: bundles |
tags: | added: cpec |
Changed in charm-test-infra: | |
status: | Confirmed → Triaged |
importance: | Undecided → Medium |
Changed in juju: | |
milestone: | none → 2.3.0 |
assignee: | nobody → Tim Penhey (thumper) |
importance: | Wishlist → High |
tags: | added: 2.3-blocker |
Changed in juju: | |
status: | Triaged → In Progress |
Changed in juju: | |
status: | In Progress → Fix Released |
Changed in juju: | |
milestone: | 2.3.0 → 2.3-beta2 |
Changed in charm-test-infra: | |
status: | Triaged → Invalid |
Bundles are not meant to do this. The machine specification in bundles is all self contained. This is an effort to make bundles useful across users without needing exact pre-defined setup steps before a bundle is useful.
It is not the goal of bundles in core to implement this in the current form.
There is work in the pipeline that will enable us to specify a profile to lxd as a constraint. That might be the path forward on this so that the bundle can contain the constraint and the machines do not have to be pre-setup. The downside is that then the profiles need to be pre-setup so it's still not helping the reshare point, however we might be able to make the bundle be able to ignore the constraint or warn if it can't be met.