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