Juju 2.3 beta2 is here!

Dmitrii Shcherbakov dmitrii.shcherbakov at canonical.com
Fri Nov 10 13:30:22 UTC 2017


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
<lastid> + 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 <roger.peppe at canonical.com>
wrote:

> On 10 November 2017 at 10:40, Dmitrii Shcherbakov
> <dmitrii.shcherbakov at canonical.com> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20171110/0daeacb8/attachment.html>


More information about the Juju-dev mailing list