<div dir="ltr"><div>This might not be an ideal example after all. However, I encountered something else in this case - final model machine IDs are not the same as I would expect while looking at the bundle. This is Juju 2.2.6, MAAS 2.2.2. I am not sure there can be any guarantees about that due to parallelization of provisioner and az spread code - I expected that during an initial deployment on a *clean model* (no prior machine number allocation), bundle and model machine numbers would match but apparently they don't.</div><div><br></div><div>If model machine numbers matched the bundle ones after a clean model deployment, my example would be about slicing a huge bundle into multiple ones and deploying in steps (rabbitmq is a bad example of something to deploy like that).</div><div><br></div><div>So:</div><div><br></div><div>bundle.yaml machine definitions:</div><div><br></div><div><a href="http://paste.ubuntu.com/25930362/">http://paste.ubuntu.com/25930362/</a></div><div>...</div><div> '0':</div><div> series: xenial</div><div> constraints: tags=gateway</div><div> zone: z01</div><div> '1':</div><div> series: xenial</div><div> constraints: tags=gateway</div><div> zone: z02</div><div> '2':</div><div> series: xenial</div><div> constraints: tags=gateway</div><div> zone: z03</div><div> '3': &compute-z1</div><div> series: xenial</div><div> constraints: tags=compute</div><div> zone: z01</div><div> '4': &compute-z2</div><div> series: xenial</div><div> constraints: tags=compute</div><div> zone: z02</div><div> '5': &compute-z3</div><div> series: xenial</div><div> constraints: tags=compute</div><div> zone: z03</div><div> '6': *compute-z1</div><div> '7': *compute-z2</div><div> '8': *compute-z3</div><div> '9': *compute-z1</div><div> '10': *compute-z2</div><div> '11': *compute-z3</div><div> '12': *compute-z1</div><div>...</div><div><br></div><div>They were eventually enumerated as follows:</div><div><br></div><div><a href="http://paste.ubuntu.com/25930364/">http://paste.ubuntu.com/25930364/</a></div><div><br></div><div>0 started 198.51.105.129 7nc46s xenial z01 Deployed</div><div>0/lxd/0 started 198.51.105.152 juju-ada6ad-0-lxd-0 xenial z01 Container started</div><div>...</div><div>1 started 198.51.105.130 hxgx7c xenial z02 Deployed</div><div>1/lxd/0 started 198.51.105.150 juju-ada6ad-1-lxd-0 xenial z02 Container started</div><div>...</div><div>2 started 198.51.105.131 wdskcy xenial z03 Deployed</div><div>...</div><div>4 started 198.51.105.134 f3e4gm xenial z02 Deployed</div><div>5 started 10.30.21.22 k8spqw xenial default Deployed</div><div>6 started 10.30.21.47 feethe xenial default Deployed</div><div>7 started 10.30.21.77 gesdy6 xenial default Deployed</div><div>8 started 10.30.21.45 46rp4s xenial default Deployed</div><div>9 started 10.30.21.55 ce6e38 xenial default Deployed</div><div>10 started 10.30.21.46 yqew8f xenial default Deployed</div><div>11 started 10.30.21.50 bdfn4y xenial default Deployed</div><div>12 started 198.51.105.132 prbbg4 xenial z03 Deployed</div><div>12/lxd/0 started 198.51.105.142 juju-ada6ad-12-lxd-0 xenial z03 Container started</div><div>...</div><div>13 started 10.30.21.88 xrmf76 xenial default Deployed</div><div>14 started 10.30.21.81 sbqwex xenial default Deployed</div><div>15 started 10.30.21.17 hkgcf6 xenial default Deployed</div><div>16 started 10.30.21.62 sdtfmm xenial default Deployed</div><div>17 started 10.30.21.48 ghnxww xenial default Deployed</div><div>18 started 10.30.21.30 xe8da4 xenial default Deployed</div><div>19 started 10.30.21.65 nhd773 xenial default Deployed</div><div>20 started 198.51.105.135 433afe xenial z01 Deployed</div><div>...</div><div><br></div><div>Note how machines in the "default" AZ in MAAS took precedence in integer ID allocation after machines 4 and 12 and, more importantly, how node 2 in the bundle became node 12 in the model.</div><div><br></div><div>So, instead of 0, 1, 2 in the bundle we have 0, 1, 12 and have to use <span style="font-size:12.8px"> </span><span style="font-size:12.8px">--to lxd:0,lxd:1,lxd:12 for placement.</span></div><div><br></div><div>I understand that there is AZ spread code in Juju <a href="https://git.io/vF2nu">https://git.io/vF2nu</a> <a href="https://git.io/vF2nD">https://git.io/vF2nD</a> so I can see why the original bundle numbering does not match.</div><div><br></div><div>The end result is that it requires an additional step in the big bundle separation use-case:</div><div><br></div><div>1. deploy a core.yaml bundle part;</div><div>2. get resulting machine numbers and apply to bundle-add-ons.yaml (no juju export-bundle?)</div><div>2. deploy bundle-add-ons.yaml.</div><div><br></div><div>Manual processing in step 2 is something to consider because we have no reliable means of addressing machines in dependent bundles then.</div><div><br></div><div>Would reusing existing unit names be possible (the feature is about existing machine definitions so it's good to clarify)?</div><div><br></div><div>bundle-add-ons.yaml:</div><div>...</div><div>to:</div><div> - old-app/0</div><div> - old-app/1</div><div> - old-app/2</div><div><br></div><div>This is different from <machine-id>=<unit-id> mapping which isn't considered as you mentioned. It's rather a reference to symbolic machine name ideas.</div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr">Best Regards,<div>Dmitrii Shcherbakov</div><div><br></div><div><div style="color:rgb(136,136,136);font-size:12.8px"><span style="color:rgb(68,68,68);font-size:12.8px">Field Software Engineer</span><br style="color:rgb(68,68,68);font-size:12.8px"><span style="font-size:12.8px">IRC (freenode): Dmitrii-Sh</span><br></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Fri, Nov 10, 2017 at 2:20 AM, Tim Penhey <span dir="ltr"><<a href="mailto:tim.penhey@canonical.com" target="_blank">tim.penhey@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 10/11/17 12:12, Dmitrii Shcherbakov wrote:<br>
> It's situations like the following that I am trying to avoid:<br>
><br>
> rabbitmq-server:<br>
> charm: cs:xenial/rabbitmq-server<br>
> bindings:<br>
> "": *oam-space<br>
> amqp: *internal-space<br>
> cluster: *internal-space<br>
> options:<br>
> source: *openstack-origin<br>
> min-cluster-size: 3<br>
> cluster-partition-handling: pause_minority<br>
> num_units: 3<br>
> to:<br>
> - lxd:0<br>
> - lxd:1<br>
> - lxd:2<br>
><br>
> serialized by hand to: juju deploy rabbitmq-server --config<br>
> ../rabbitmq.yaml -n 3 --to lxd:0,lxd:1,lxd:12 --bind "space-oam<br>
> amqp=space-oam cluster=space-oam"<br>
><br>
> cat ../rabbitmq.yaml <br>
> rabbitmq-server:<br>
> source: cloud:xenial-ocata<br>
> min-cluster-size: 3<br>
> cluster-partition-handling: pause_minority<br>
><br>
> Which includes brain-parsing the definition, serializing it to<br>
> <appname>.yaml + -n <n> --to <placement> --bind <spaces><br>
<br>
</div></div>I don't understand what it is you are trying to avoid here?<br>
<br>
What is it you are trying to do?<br>
<span class="HOEnZb"><font color="#888888"><br>
Tim<br>
</font></span></blockquote></div><br></div>