state/api.State authTag vs tag

[William Reade]

On Tue, Jun 17, 2014 at 10:04 AM, roger peppe <rogpeppe at gmail.com> wrote:

> On 16 June 2014 09:25, William Reade <william.reade at canonical.com> wrote:
> > On Sun, Jun 15, 2014 at 2:58 PM, John Meinel <john at arbash-meinel.com>
> wrote:
> >>
> >> I feel like we should consolidate these fields. And if we need "authTag"
> >> to match Login then we should be setting "tag" there instead. (That
> will be
> >> better for any case where we Login late, given that we probably still
> would
> >> want to be able to use anything like DebugLog URLs.)
> >
> > They currently match but are not guaranteed to; in particular, when we
> > consolidate the agents such that a machine agent is running the uniters
> > deployed on that machine, they will definitely not match.
>
> I don't understand this. Surely if a machine agent is running the uniters
> deployed on that machine, it will still log in as itself (the machine
> agent)
> and leave it up to the API server to allow that agent the authority
> to speak for those unit agents?
>

Yeah, but the (only, I think) usage of the authTag field is to specialise
relation calls by interested unit. We'll certainly be authed as the machine
agent, but the current form of api/uniter.State requires the unit tag, so
we will need some fix; whether that fix is a change to the relation
methods, or something else, is not especially interesting to me right now.

I agree that that the "authTag" and "tag" fields are mutually redundant.
> I think we should just delete "tag",  and make both Open and Login save
> authTag and the password (authTag is a somewhat more self-explanatory
> name than tag IMHO).
>

So long as we're agreed that we only need one field, I think the choice of
name can be left to the implementer and tweaked in review if necessary.

Cheers
William
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140617/9e1cd6c2/attachment.html>