state/api.State authTag vs tag

[roger peppe]

On 17 June 2014 09:27, William Reade <william.reade at canonical.com> wrote:
> 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.

Ah, that makes sense.

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

SGTM

  cheers,
    rog.