juju deploy bundle with service-based co-located placement may fail on iterative redeployment

Bug #1807289 reported by Drew Freiberger on 2018-12-06
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
juju
Medium
Unassigned

Bug Description

Let's say you have a bundle:

base:
  charm: cs:ubuntu
  to:
  - 0
  - 1
foo:
  charm: cs:ubuntu
  to:
  - lxd:0
  - lxd:1
bar:
  charm: cs:ubuntu
  to:
  - foo/0
  - foo/1

You'd result in a model that had "base" on metals 1 and 2, and foo and bar smooshed into 0/lxd/0 and 1/lxd/0 together.

Now imagine you juju remove-application foo and then re-deploy, you actually end up with foo creating 0/lxd/1 and 1/lxd/1. That's somewhat expected and as advertised, but not the intention of the bundle author.

now remove both applications foo and bar, leaving base.
re-deployment of this bundle with --map-machines=existing gives you "base" on 0 and 1, "bar" smooshed onto 0 and 1 with "base", and "foo" is on 0/lxd/2 (as foo/3) and 1/lxd/2 (as foo/4) all on it's lonesome.

So, is the failure of the second to put memcached into containers with foo/3 and foo/4 because the placement directive is pointing at foo/0 and foo/1 as specific unit numbers and not the "honorary" units 0 and 1 in the "list of available foo units"?

Drew Freiberger (afreiberger) wrote :

juju version 2.4.7-bionic-amd64

no longer affects: juju-core
Drew Freiberger (afreiberger) wrote :

and/or, is there a way to --map-machines "foo/0" to "foo/3"?

Richard Harding (rharding) wrote :

It's a tricky spot there. We'll have to see what we can figure out to help make that logic fit into a more expected path.

Changed in juju:
status: New → Triaged
importance: Undecided → Medium
Tim Penhey (thumper) on 2019-01-20
tags: added: bundles
Dmitrii Shcherbakov (dmitriis) wrote :

+1

--map-machines=existing does not respect placements to existing applications in general.

Using `--to lxd:app1/0` will result in a new machine being allocated.

Example:

- add unit app/1 to new machine 8

tags: added: cpe-onsite
Tim Penhey (thumper) wrote :

All I'm going to say on this bug at the moment is that this is the hairy part of guessing the user's intent.

@Drew, when you remove the application foo and redeploy, all juju is determining for foo is that you want it in lxd containers. It doesn't infer anything from bar's placement directives of wanting to be next to foo.

When you are using unit placement directives, I can imagine that juju is getting confused with logical vs. actual unit numbers.

I can't think of a definitive approach just now that won't cause more problems than it attempts to save.

@Dmitrii, you comment is somewhat without other context and it is hard to work out the flow that has got you into the position you are explaining.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers