unit ids should be unique

[Kapil Thangavelu]

juju deploy precise/varnish lb
juju destroy-service lb
juju deploy precise/haproxy lb

the unit id lb/0 is now pointing to something completely different. prior versions of juju.. the new haproxy unit would be lb/1.

[William Reade (fwereade)]

Hmm... I'm not so sure. I think it's important to be able to distinguish between "lb/0" and "lb/0", in the same way it's important to distinguish between "lb" and "lb". Would it be sufficient to add and expose really-unique integer ids per lacking entity? We hope to be able to fix that once we have the API dealt with.

Ofc, it wouldn't be hard to change the unit id sequence, but I need a bit more convincing. It feels inconsistent; and I'd rather not devote time to it if it'll be adequately addressed by other work anyway.

[Kapil Thangavelu (hazmat)]

First fwiw, this is backwards compatibility problem issue. Second, its quite common to associate resources/data to a unit using the unit *id* as both a semantic and unique reference to that allocation. For example associating logging and metric data in an aggregator and visualizer to a unit, ie. like some of our existing monitoring and logging charms. With this change, we're saying that such data would need to be deleted after a relation is broken or that it could be mistakenly associated to a different instance of the same unit id, neither of which is desirable. I don't think exposing another primary key field is particularly helpful, because at this level the semantic value of the unit id is important for human interpretation/correlation of the data, plus an additional primary key would break existing charms that rely on this behavior.

[Launchpad Janitor (janitor)]

[Expired for juju-core because there has been no activity for 60 days.]

[Kapil Thangavelu (hazmat)]

I'm resurrecting this, because its extremely common as a charm author to use a remote unit id as identifier to a locally allocated resource. The lack of uniqueness there is a significant problem, a regression, and cause breakage for extant charms.

[Dimiter Naydenov (dimitern)]

It can't land until we have 1.16 clients, that access state directly, we need to care about. So postponed until 1.20.

[John A Meinel (jameinel)]

Curtis marked this one as Regression, but it doesn't quite make sense since we can't actually land this in 1.18, so I'm removing the regression tag.

[John A Meinel (jameinel)]

Ah, I see. This is a regression relative to python-juju, not to an earlier version of juju-core, so it isn't quite "regression" for what I think we were using it as (stuff that blocks the next release)

[Kapil Thangavelu (hazmat)]

its more than just a regression issue, its a loss of identity across
relations which can lead to data loss and corruption. lots of charms use
related unit id for uniquely characterizing data from a remote system.

On Wed, Feb 26, 2014 at 5:46 AM, John A Meinel <email address hidden>wrote:

> Ah, I see. This is a regression relative to python-juju, not to an
> earlier version of juju-core, so it isn't quite "regression" for what I
> think we were using it as (stuff that blocks the next release)
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1174610
>
> Title:
> unit ids should be unique
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju-core/+bug/1174610/+subscriptions
>

[John A Meinel (jameinel)]

I agree that it is an important bug, but we are no worse in 1.18 vs 1.16 so
we don't need to block releasing 1.18 on fixing the bug.

John
=:->
On Feb 26, 2014 1:51 PM, "Kapil Thangavelu" <email address hidden>
wrote:

> its more than just a regression issue, its a loss of identity across
> relations which can lead to data loss and corruption. lots of charms use
> related unit id for uniquely characterizing data from a remote system.
>
>
> On Wed, Feb 26, 2014 at 5:46 AM, John A Meinel <<email address hidden>
> >wrote:
>
> > Ah, I see. This is a regression relative to python-juju, not to an
> > earlier version of juju-core, so it isn't quite "regression" for what I
> > think we were using it as (stuff that blocks the next release)
> >
> > --
> > You received this bug notification because you are subscribed to the bug
> > report.
> > https://bugs.launchpad.net/bugs/1174610
> >
> > Title:
> > unit ids should be unique
> >
> > To manage notifications about this bug go to:
> > https://bugs.launchpad.net/juju-core/+bug/1174610/+subscriptions
> >
>
> --
> You received this bug notification because you are subscribed to juju-
> core.
> https://bugs.launchpad.net/bugs/1174610
>
> Title:
> unit ids should be unique
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju-core/+bug/1174610/+subscriptions
>

[Matthew Williams (mattyw)]

Just landed a fix for this bug http://reviews.vapour.ws/r/1425/