juju should be able to use nodes acquired by the same user in MAAS
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical Juju |
Triaged
|
Wishlist
|
Unassigned | ||
MAAS |
Opinion
|
High
|
Unassigned | ||
juju-core |
Won't Fix
|
Medium
|
Unassigned |
Bug Description
MAAS has the concept of allocating, or reserving, nodes in advance. It doesn't install anything on the node when that happens, nor powers it on.
This would be useful in the OpenStack Autopilot where the user first picks which machines he/she wants to use for the deployment, and then lets Autopilot deploy it. Autopilot bootstraps to one of those machines, but there is nothing preventing another MAAS user from picking one of the other nodes before bootstrap finishes and the Autopilot can issue add-machine calls to reserve the rest.
The problem is that juju thinks that an allocated node is not available, even when the same user that allocated it tells juju to use that node specifically.
Here is an example where I first acquire a node in MAAS, then tell juju to bootstrap on it:
$ maas andreas-atlas nodes acquire name=elkhart.
{
"status": 6,
"macaddress
(...)
"hostname": "elkhart.
"owner": "andreas",
"ip_addresses": [],
(...)
}
$ juju bootstrap --debug --to elkhart.scapestack
2015-05-01 07:36:12 INFO juju.cmd supercommand.go:37 running juju [1.23.2-
(...)
2015-05-01 07:36:15 INFO juju.cmd cmd.go:113 Starting new instance for initial state server
2015-05-01 07:36:15 INFO juju.provider.maas environ.go:127 address allocation feature disabled; using "juju-br0" bridge for all containers
2015-05-01 07:36:15 DEBUG juju.provider.
Launching instance
2015-05-01 07:36:21 DEBUG juju.cmd.juju common.go:90 Destroying environment.
2015-05-01 07:36:21 INFO juju.cmd cmd.go:113 Bootstrap failed, destroying environment
2015-05-01 07:36:21 INFO juju.provider.
2015-05-01 07:36:22 ERROR juju.cmd supercommand.go:430 failed to bootstrap environment: cannot start bootstrap instance: cannot run instances: cannot run instances: gomaasapi: got error back from server: 409 CONFLICT (No available node matches constraints: name=elkhart.
Unless there is something I'm not foreseeing, I think that if a node is just allocated in MAAS, it should be seen as available by juju if juju has the same API credentials as the user who allocated the node. Perhaps we could restrict this a bit and only allow juju to take the node if specifically told so, like with --to in the bootstrap case, or in the add-machine case (after bootstrap).
tags: | added: manual-provider |
Changed in juju-core: | |
status: | New → Triaged |
importance: | Undecided → Medium |
tags: | added: deploy |
tags: |
added: maas-provider removed: manual-provider |
Changed in maas: | |
milestone: | none → 1.8.0 |
Changed in maas: | |
status: | New → Opinion |
importance: | Undecided → High |
tags: | added: cloud-installer |
Changed in juju-core: | |
status: | Triaged → Won't Fix |
Changed in juju: | |
importance: | Undecided → Wishlist |
status: | New → Triaged |
tags: | added: community-feedback field-feedback |
> Unless there is something I'm not foreseeing, I think that if a node is just allocated in MAAS, it should be seen as available by juju
> if juju has the same API credentials as the user who allocated the node.
Technically there is nothing preventing Juju from using a previously allocated node. Now, it gets a bit complicated if you consider that the constraints are used during the acquisition phase: once a node is acquired, there is no record of the set of constraints that got it acquired in the first place.