On Tue, Jun 17, 2014 at 10:04 AM, roger peppe <[email protected]> wrote:
> On 16 June 2014 09:25, William Reade <[email protected]> wrote: > > On Sun, Jun 15, 2014 at 2:58 PM, John Meinel <[email protected]> > 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
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
