On 16 June 2014 09:25, William Reade <william.re...@canonical.com> wrote:
> On Sun, Jun 15, 2014 at 2:58 PM, John Meinel <j...@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.
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
