Trusting that the machine *number* is stable is not appropriate because of
how numbers are applied. As soon as any machine needs to be replaced the
numbers will be wrong. Doing it by tag or some other user appropriate
mechanism is far more correct. That sort of tagging can last as the
environment evolves over time. Juju never re-uses a machine number, so
while you can trust that they will be unique within a model, etc.
In Bundles the machine id you use is a logical identity, and Juju is always
allowed to remap it to a new number (since that number could easily already
have been burned in an initial deployment in a model.)

Your described "--map-machines existing , 0=0..." 'existing' is exactly
0=0,1=1,2=2, etc You certainly shouldn't have to supply both.

I doubt what you *want* is "machine 0 should run unit A". I think taking a
step back and thinking about what you're actual requirement is (I want 3
units running A, 2 running B, etc). It is nice sometimes when you can have
them grouped, but as soon as you have to do any maintenance or replace
something you'll lose your pretty numbers unless you destroy it and
reprovision everything.

Better to find a way to give you the grouping you want and the actual
promises that you want. What is it about '<email address hidden>' that makes it
appropriate to put unit-a on it? (more memory, more disk, just the IP
addresses match whatever IP that is already assigned to the firewall?)

In other providers like MAAS, they already have machine tags so that tends
to be the mechanism. Tags have the nice property that you can always add
the tag to a new machine, signifying that it now, too, has the right
properties that you have assigned to that tag. Machine IDs don't have that
property. (scale up, scale out, replacing a dead machine, etc, all work
better with something like tags than with ids).



On Mon, May 28, 2018 at 10:30 AM, Calvin Hartwell <
<email address hidden>> wrote:

> I would be happy to have some way of tagging manually added machines, but
>      we shouldn't trust that a machine number is stable in any fashion.
>
> Not even on the initial bootstrap?
>
> Lets say I have 10 machines, and I want machines 0-2 to run unit A, I
> want machines 3-4 to run unit B, I want machines 5-8 to run unit C,
> machine 9 to run Unit D.
>
> So I would have something like juju deploy somemodel.yaml --map-machines
> existing,0=0,1=1,2=2,3=3,4=4,5=5,6=6,7=7,8=8,9=9
>
> Right now I am able to 100% verify these machines have the correct
> machine number. The problem is that this is slow, due to the lack of
> parallelism:
>
> # slow
> juju add-machine ssh:<email address hidden> -> host number 0
> juju add-machine ssh:<email address hidden> -> host number 1
> juju add-machine ssh:<email address hidden> -> host number 2
>
> I would be happy to tag it with something else like:
>
> juju add-machine ssh:<email address hidden> --some-metadata 'unit-a' &
> juju add-machine ssh:<email address hidden> --some-metadata 'unit-b' &
> juju add-machine ssh:<email address hidden> --some-metadata 'unit-d' &
>
> or:
>
> juju add-machine ssh:<email address hidden> --desired-unit 'unit-a' &
>
> The other way to do this is to work based on host name, I.E add all the
> machines using in random order and then have a script which parses juju
> status output to look for hostname patterns which then calculates which
> unit should be deployed on each host using the map-machines command.
> This is pretty nasty and I think juju should give me a better way to do
> this for customers.
>
> --
> You received this bug notification because you are subscribed to juju.
> Matching subscriptions: juju bugs
> https://bugs.launchpad.net/bugs/1772653
>
> Title:
>   juju add-machine through SSH should have the ability to add a number
>   tag (feature request)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1772653/+subscriptions
>