On Tue, May 3, 2016 at 1:46 PM, Clint Byrum <cl...@fewbar.com> wrote:
> Excerpts from Morgan Fainberg's message of 2016-05-03 11:13:38 -0700: > > On Tue, May 3, 2016 at 10:28 AM, Monty Taylor <mord...@inaugust.com> > wrote: > > > > > On 05/03/2016 11:47 AM, Clint Byrum wrote: > > > > > >> Excerpts from Monty Taylor's message of 2016-05-03 07:59:21 -0700: > > >> > > >>> On 05/03/2016 08:55 AM, Clint Byrum wrote: > > >>> > > >>>> > > >>>> Perhaps we have different perspectives. How is accepting what we > > >>>> previously emitted and told the user would be valid sneaky or wrong? > > >>>> Sounds like common sense due diligence to me. > > >>>> > > >>> > > >>> I agree - I see no reason we can't validate previously emitted > tokens. > > >>> But I don't agree strongly, because re-authing on invalid token is a > > >>> thing users do hundreds of times a day. (these aren't oauth API Keys > or > > >>> anything) > > >>> > > >>> > > >> Sure, one should definitely not be expecting everything to always work > > >> without errors. On this we agree for sure. However, when we do decide > to > > >> intentionally induce errors for reasons we have not done so before, we > > >> should weigh the cost of avoiding that with the cost of having it > > >> happen. Consider this strawman: > > >> > > >> - User gets token, it says "expires_at Now+4 hours" > > >> - User starts a brief set of automation tasks in their system > > >> that does not use python and has not failed with invalid tokens > thus > > >> far. > > >> - Keystone nodes are all updated at one time (AMAZING cloud ops team) > > >> - User's automation jobs fail at next OpenStack REST call > > >> - User begins debugging, wasting hours of time figuring out that > > >> their tokens, which they stored and show should still be valid, > were > > >> rejected. > > >> > > > > > > Ah - I guess this is where we're missing each other, which is good and > > > helpful. > > > > > > I would argue that any user that is _storing_ tokens is doing way too > much > > > work. If they are doing short tasks, they should just treat them as > > > ephemeral. If they are doing longer tasks, they need to deal with > timeouts. > > > SO, this: > > > > > > > > > - User gets token, it says "expires_at Now+4 hours" > > > - User starts a brief set of automation tasks in their system > > > that does not use python and has not failed with invalid tokens thus > > > far. > > > > > > should be: > > > > > > - User starts a brief set of automation tasks in their system > > > that does not use python and has not failed with invalid tokens thus > > > far. > > > > > > "Get a token" should never be an activity that anyone ever consciously > > > performs. > > > > > > > > This is my view. Never, ever, ever assume your token is good until > > expiration. Assume the token might be broken at any request and know how > to > > re-auth. > > > > > And now they have to refactor their app, because this may happen again, > > >> and they have to make sure that invalid token errors can bubble up to > the > > >> layer that has the username/password, or accept rolling back and > > >> retrying the whole thing. > > >> > > >> I'm not saying anybody has this system, I'm suggesting we're putting > > >> undue burden on users with an unknown consequence. Falling back to > UUID > > >> for a while has a known cost of a little bit of code and checking junk > > >> tokens twice. > > >> > > > > > Please do not advocate "falling back" to UUID. I am actually against > making > > fernet the default (very, very strongly), if we have to have this > > "fallback" code. It is the wrong kind of approach, we already have > serious > > issues with complex code paths that produce subtly different results. If > > the options are: > > > > 1) Make Fernet Default and have "fallback" code > > > > or > > > > 2) Leave UUID default and highly recommend fernet (plus gate on fernet > > primarily, default in devstack) > > > > I will jump on my soapbox and be very loudly in favor of the 2nd option. > If > > we communicate this is a change that will happen (hey, maybe throw an > > error/make the config option "none" so it has to be explicit) in Newton, > > and then move to a Fernet default in O - I'd be ok with that. > > > > > > > > Totally. I have no problem with the suggestion that keystone handle > this. > > > But I also think that users should quite honestly stop thinking about > > > tokens at all. Tokens are an implementation detail that if any user > thinks > > > about while writing their app they're setting themselves up to be > screwed - > > > so we should make sure we're not talking about them in a primary way > such > > > as to suggest that people focus a lot of energy on them. > > > > > > (I also frequently see users who are using python libraries even get > > > everything horribly wrong and screw themselves because they think they > need > > > to think about tokens) > > > > > > > Better communication that tokens are ephemeral and should not assume to > > work always (even until their expiry) should be the messaging we use. > It's > > simple, plan to reauth as needed and handle failures. > > This is not what the documentation says, so yeah, we need to actually > tell users that expires_at is an upper bounds, because right now it > says: > > The date and time when the token expires. > > The date and time stamp format is ISO 8601: > > CCYY-MM-DDThh:mm:ss±hh:mm > > For example, 2015-08-27T09:49:58-05:00. > > The ±hh:mm value, if included, is the time zone as an offset from UTC. > In the previous example, the offset value is -05:00. > > A null value indicates that the token never expires. > > Ok this here is a major issue we need to fix. a token with a null expires will *not* validate. > http://developer.openstack.org/api-ref-identity-v3.html > > Perhaps "The latest date and time when the token expires. Tokens may be > revoked or expired before this time and any use of tokens should be > prepared to reauthenticate to keystone and obtain a new token at any > time upon encountering a 401 error code from any service." > > ++ Lets fix this ASAP. > I am not suggesting, btw, that users would explicitly think about getting > tokens. I just think a user would read the docs as they are now, and > reasonably think that they could expect tokens to be around a stable > amount of time, and would be annoyed that they weren't. Obviously people > would like to not think about that, and that's fine, but let's actually > tell users how the API works if we're going to do that. > > BTW, I'd submit a patch, but I can't find the api-ref/source for the > identity API. :-P > > The docs are too spread out. Sadly the API Ref has been neglected and.. well.. yes what you said.
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
