Re: Juju 2.3 beta2 is here!

[Dmitrii Shcherbakov]

There is an edge case to that: when you remove a machine and add a new one
an ID cannot be reused.

I believe it's just auto-increment in the database: one does not reuse
auto-incremented IDs for efficiency (otherwise you have to implement "find
first available unused ID" functionality).

So, if there is a machine "1" in the model which gets deleted and a --to 1
placement directive in a new bundle with --use-existing-machines flag
passed, this new machine will get a new ID (depending on how many placement
directives like that already exist and implementation it may not be
 + 1).

I think this edge case can stay as is because you've already hacked an
initial model further at this point - just modify your add-on bundle to
reflect the model state.

But a clean deployment is an important case to consider in my view.

Best Regards,
Dmitrii Shcherbakov

Field Software Engineer
IRC (freenode): Dmitrii-Sh

On Fri, Nov 10, 2017 at 4:13 PM, roger peppe 
wrote:

> On 10 November 2017 at 10:40, Dmitrii Shcherbakov
>  wrote:
> > 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.
>
> I'd've thought that --use-existing-machines might solve that case, but...
> I guess it depends if --use-existing-machines also guarantees that any new
> machines created will have machine ids that match the ones in the bundle.
>
> If not, I guess it probably should.
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Juju 2.3 beta2 is here!

[roger peppe]

On 10 November 2017 at 10:40, Dmitrii Shcherbakov
 wrote:
> 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.

I'd've thought that --use-existing-machines might solve that case, but...
I guess it depends if --use-existing-machines also guarantees that any new
machines created will have machine ids that match the ones in the bundle.

If not, I guess it probably should.

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Juju 2.3 beta2 is here!

[Dmitrii Shcherbakov]

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.

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).

So:

bundle.yaml machine definitions:

http://paste.ubuntu.com/25930362/
...
  '0':
series: xenial
constraints: tags=gateway
zone: z01
  '1':
series: xenial
constraints: tags=gateway
zone: z02
  '2':
series: xenial
constraints: tags=gateway
zone: z03
  '3': 
series: xenial
constraints: tags=compute
zone: z01
  '4': 
series: xenial
constraints: tags=compute
zone: z02
  '5': 
series: xenial
constraints: tags=compute
zone: z03
  '6': *compute-z1
  '7': *compute-z2
  '8': *compute-z3
  '9': *compute-z1
  '10': *compute-z2
  '11': *compute-z3
  '12': *compute-z1
...

They were eventually enumerated as follows:

http://paste.ubuntu.com/25930364/

0 started  198.51.105.129  7nc46sxenial  z01
Deployed
0/lxd/0   started  198.51.105.152  juju-ada6ad-0-lxd-0   xenial  z01
Container started
...
1 started  198.51.105.130  hxgx7cxenial  z02
Deployed
1/lxd/0   started  198.51.105.150  juju-ada6ad-1-lxd-0   xenial  z02
Container started
...
2 started  198.51.105.131  wdskcyxenial  z03
Deployed
...
4 started  198.51.105.134  f3e4gmxenial  z02
Deployed
5 started  10.30.21.22 k8spqwxenial  default
Deployed
6 started  10.30.21.47 feethexenial  default
Deployed
7 started  10.30.21.77 gesdy6xenial  default
Deployed
8 started  10.30.21.45 46rp4sxenial  default
Deployed
9 started  10.30.21.55 ce6e38xenial  default
Deployed
10started  10.30.21.46 yqew8fxenial  default
Deployed
11started  10.30.21.50 bdfn4yxenial  default
Deployed
12started  198.51.105.132  prbbg4xenial  z03
Deployed
12/lxd/0  started  198.51.105.142  juju-ada6ad-12-lxd-0  xenial  z03
Container started
...
13started  10.30.21.88 xrmf76xenial  default
Deployed
14started  10.30.21.81 sbqwexxenial  default
Deployed
15started  10.30.21.17 hkgcf6xenial  default
Deployed
16started  10.30.21.62 sdtfmmxenial  default
Deployed
17started  10.30.21.48 ghnxwwxenial  default
Deployed
18started  10.30.21.30 xe8da4xenial  default
Deployed
19started  10.30.21.65 nhd773xenial  default
Deployed
20started  198.51.105.135  433afexenial  z01
Deployed
...

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.

So, instead of 0, 1, 2 in the bundle we have 0, 1, 12 and have to use  --to
lxd:0,lxd:1,lxd:12 for placement.

I understand that there is AZ spread code in Juju https://git.io/vF2nu
https://git.io/vF2nD so I can see why the original bundle numbering does
not match.

The end result is that it requires an additional step in the big bundle
separation use-case:

1. deploy a core.yaml bundle part;
2. get resulting machine numbers and apply to bundle-add-ons.yaml (no juju
export-bundle?)
2. deploy bundle-add-ons.yaml.

Manual processing in step 2 is something to consider because we have no
reliable means of addressing machines in dependent bundles then.

Would reusing existing unit names be possible (the feature is about
existing machine definitions so it's good to clarify)?

bundle-add-ons.yaml:
...
to:
  - old-app/0
  - old-app/1
  - old-app/2

This is different from = mapping which isn't
considered as you mentioned. It's rather a reference to symbolic machine
name ideas.


Best Regards,
Dmitrii Shcherbakov

Field Software Engineer
IRC (freenode): Dmitrii-Sh

On Fri, Nov 10, 2017 at 2:20 AM, Tim Penhey 
wrote:

> On 10/11/17 12:12, Dmitrii Shcherbakov wrote:
> > It's situations like the following that I am trying to avoid:
> >
> >   rabbitmq-server:
> > charm: cs:xenial/rabbitmq-server
> > bindings:
> >   "": *oam-space
> >   amqp: *internal-space
> >   cluster: *internal-space
> > 

Re: Juju 2.3 beta2 is here!

[roger peppe]

On 9 November 2017 at 22:49, Tim Penhey  wrote:
> No we aren't going to reuse --to.
>
> The --to directive is just for placement directives. Trying to use that
> to overload machine mappings for bundles adds complexity for no real value.

As I see it, machine mapping *is* placement, as applied to a bundle rather
than the first unit of a deployed application.

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev