state/api.State authTag vs tag

roger peppe rogpeppe at gmail.com
Tue Jun 17 08:04:56 UTC 2014


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?

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

But I may well be missing some aspect of your future plans for the API
here that would make this unreasonable.

John writes:

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

This is an interesting possibility - I hadn't considered that we might not
want to log in immediately. I guess that if we just want to access
non-websocket-based aspects of the API, that logging in is
unnecessary and we can save a round trip by avoiding Login.
But if so, we'd probably want to avoid connecting to the websocket
entirely. One could arrange things so that the first use of any websocket
RPC call makes the actual connection and logs in. But that's is
a significant change and how Open vs Login is managed for that case
case could be dealt with if and when that happens.

  cheers,
    rog.



More information about the Juju-dev mailing list