actual machine numbers don't match machine numbers from bundle

[Jason Hobbs]

I deployed a bundle via "juju deploy ./bundle.yaml" (http://paste.ubuntu.com/26444907/) which used placement directives to put services on specific machines, with machines numbered 0-22.

After the deploy, I removed an application and tried to redeploy it via "juju deploy ./bundle.yaml --map-machines existing", thinking the bundle would add the application's units back to the machines they were on the first time.

It didn't, because the machine IDs in my model didn't match the machine IDs from my bundle. They aren't related at all. This makes --map-machines existing not very useful for this use case, and means I have to go and manually figure out mapping between machines in the bundle and machines in the model. It means I can't just update the bundle and run ./deploy again, like I could with juju-deployer.

http://paste.ubuntu.com/26444925/

This is with juju 2.3.3+2.3-811c0a3.

[John A Meinel (jameinel)]

We've never allowed machine IDs to be reused, or AFAIK specified by a
client. So as soon as you, say, destroy a machine and create a new one, the
IDs would no longer match.

I'm guessing the issue is that juju-deplpyer was more careful to create the
machines in exactly the order specified (though I'm rather surprised if
"juju deploy" doesn't).

As an example, imagine you had a model and decided to play around with the
Ubuntu charm, then destroy that machine (burning ID 0) then deploying the
bundle would have all IDs shifted by 1.

Or something happens and one machine fails in the middle and you have to
kill it and try again.

It seems like a more stable option would be to have "juju deploy" somehow
generate the map of logical bundle IDs to concrete model IDs so you can
feed it back in.

John
=:->

On Jan 23, 2018 20:00, "Jason Hobbs" <email address hidden> wrote:

> Public bug reported:
>
> I deployed a bundle via "juju deploy ./bundle.yaml"
> (http://paste.ubuntu.com/26444907/) which used placement directives to
> put services on specific machines, with machines numbered 0-22.
>
> After the deploy, I removed an application and tried to redeploy it via
> "juju deploy ./bundle.yaml --map-machines existing", thinking the bundle
> would add the application's units back to the machines they were on the
> first time.
>
> It didn't, because the machine IDs in my model didn't match the machine
> IDs from my bundle. They aren't related at all. This makes --map-
> machines existing not very useful for this use case, and means I have to
> go and manually figure out mapping between machines in the bundle and
> machines in the model. It means I can't just update the bundle and run
> ./deploy again, like I could with juju-deployer.
>
> http://paste.ubuntu.com/26444925/
>
> This is with juju 2.3.3+2.3-811c0a3.
>
> ** Affects: juju
> Importance: Undecided
> Status: New
>
>
> ** Tags: cdo-qa cdo-qa-blocker foundations-engine
>
> --
> You received this bug notification because you are subscribed to juju.
> Matching subscriptions: juju bugs
> https://bugs.launchpad.net/bugs/1744964
>
> Title:
> actual machine numbers don't match machine numbers from bundle
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1744964/+subscriptions
>

[Tim Penhey (thumper)]

If you have a bundle that is deployed, and you remove an application and run the bundle again, the bundle processing goes through a process where it infers the machine IDs based on what is deployed and what the placement directives are.

You shouldn't have to use the --map-machines existing when doing the simple use case you were mentioning.

However, if the machine was removed because there were no remaining units on it then that machine ID is used up. Redeploying the bundle will create a new machine, with a later ID, for that particular ID referenced in the bundle.

[Tim Penhey (thumper)]

Using --dry-run would show what it would do as best it can, and assuming nothing changes in the underlying model, the machine IDs that are mentioned in the output should map what happens when they are deployed.

[Launchpad Janitor (janitor)]

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

[Alvaro Uria (aluria)]

I'm reopening this issue. "juju deploy bundle.yaml" output is (on Juju 2.3.5):
"""
- add new machine 0
- add new machine 1
- add new machine 2 (bundle machine 10)
- add new machine 3 (bundle machine 11)
- add new machine 4 (bundle machine 12)
- add new machine 5 (bundle machine 13)
- add new machine 6 (bundle machine 14)
- add new machine 7 (bundle machine 15)
- add new machine 8 (bundle machine 16)
- add new machine 9 (bundle machine 17)
- add new machine 10 (bundle machine 18)
- add new machine 11 (bundle machine 19)
- add new machine 12 (bundle machine 2)
- add new machine 13 (bundle machine 20)
- add new machine 14 (bundle machine 21)
- add new machine 15 (bundle machine 22)
- add new machine 16 (bundle machine 3)
- add new machine 17 (bundle machine 4)
- add new machine 18 (bundle machine 5)
- add new machine 19 (bundle machine 6)
- add new machine 20 (bundle machine 7)
- add new machine 21 (bundle machine 8)
- add new machine 22 (bundle machine 9)
"""

That would mean that next runs of "juju deploy bundle.yaml" would need "--map-machines 10=2,11=3,12=4,13=5,14=6,15=7,16=8,17=9,18=10,19=11,2=12,20=13,21=14,22=15,3=16,4=17,5=18,6=19,7=20,8=21,9=22".

Would it be possible to sort the initial run of "juju deploy" by bundle's machine ID (as a number, not a string)? That would help for the common re-runs of the bundles.

For the cases a machine was removed, I think "juju deploy --dry-run" should help, as you already mentioned.

Thank you.

[Nobuto Murata (nobuto)]

@Alvaro,

Sounds like what you need is
https://bugs.launchpad.net/bugs/1762309

[Alvaro Uria (aluria)]

Bug #1765436 and bug #1765719 look related to how deploy.go treats bundle definitions (specially, the former, related to applications naming).