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