<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 3, 2016 at 10:28 AM, Monty Taylor <span dir="ltr"><<a href="mailto:mordred@inaugust.com" target="_blank">mordred@inaugust.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">On 05/03/2016 11:47 AM, Clint Byrum wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Excerpts from Monty Taylor's message of 2016-05-03 07:59:21 -0700:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On 05/03/2016 08:55 AM, Clint Byrum wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Perhaps we have different perspectives. How is accepting what we<br>
previously emitted and told the user would be valid sneaky or wrong?<br>
Sounds like common sense due diligence to me.<br>
</blockquote>
<br>
I agree - I see no reason we can't validate previously emitted tokens.<br>
But I don't agree strongly, because re-authing on invalid token is a<br>
thing users do hundreds of times a day. (these aren't oauth API Keys or<br>
anything)<br>
<br>
</blockquote>
<br>
Sure, one should definitely not be expecting everything to always work<br>
without errors. On this we agree for sure. However, when we do decide to<br>
intentionally induce errors for reasons we have not done so before, we<br>
should weigh the cost of avoiding that with the cost of having it<br>
happen. Consider this strawman:<br>
<br>
- User gets token, it says "expires_at Now+4 hours"<br>
- User starts a brief set of automation tasks in their system<br>
that does not use python and has not failed with invalid tokens thus<br>
far.<br>
- Keystone nodes are all updated at one time (AMAZING cloud ops team)<br>
- User's automation jobs fail at next OpenStack REST call<br>
- User begins debugging, wasting hours of time figuring out that<br>
their tokens, which they stored and show should still be valid, were<br>
rejected.<br>
</blockquote>
<br></span>
Ah - I guess this is where we're missing each other, which is good and helpful.<br>
<br>
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:<span class=""><br>
<br>
<br>
- User gets token, it says "expires_at Now+4 hours"<br>
- User starts a brief set of automation tasks in their system<br>
that does not use python and has not failed with invalid tokens thus<br>
far.<br>
<br></span>
should be:<span class=""><br>
<br>
- User starts a brief set of automation tasks in their system<br>
that does not use python and has not failed with invalid tokens thus<br>
far.<br>
<br></span>
"Get a token" should never be an activity that anyone ever consciously performs.<span class=""><br>
<br></span></blockquote><div><br>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. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
And now they have to refactor their app, because this may happen again,<br>
and they have to make sure that invalid token errors can bubble up to the<br>
layer that has the username/password, or accept rolling back and<br>
retrying the whole thing.<br>
<br>
I'm not saying anybody has this system, I'm suggesting we're putting<br>
undue burden on users with an unknown consequence. Falling back to UUID<br>
for a while has a known cost of a little bit of code and checking junk<br>
tokens twice.<br></blockquote></span></blockquote><div><br></div><div>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:<br><br></div><div>1) Make Fernet Default and have "fallback" code<br><br></div><div>or <br><br></div><div>2) Leave UUID default and highly recommend fernet (plus gate on fernet primarily, default in devstack)<br><br></div><div>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. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote>
<br></span>
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.<br>
<br>
(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)<br></blockquote><div><br></div><div>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.<br><br></div><div>--Morgan <br></div></div></div></div>