Open Stack

Excerpts from Steve Martinelli's message of 2016-05-02 19:56:15 -0700:
> Comments inline...
> 
> On Mon, May 2, 2016 at 7:39 PM, Matt Fischer <matt at mattfischer.com> wrote:
> 
> > On Mon, May 2, 2016 at 5:26 PM, Clint Byrum <clint at fewbar.com> wrote:
> >
> >> Hello! I enjoyed very much listening in on the default token provider
> >> work session last week in Austin, so thanks everyone for participating
> >> in that. I did not speak up then, because I wasn't really sure of this
> >> idea that has been bouncing around in my head, but now I think it's the
> >> case and we should consider this.
> >>
> >> Right now, Keystones without fernet keys, are issuing UUID tokens. These
> >> tokens will be in the database, and valid, for however long the token
> >> TTL is.
> >>
> >> The moment that one changes the configuration, keystone will start
> >> rejecting these tokens. This will cause disruption, and I don't think
> >> that is fair to the users who will likely be shown new bugs in their
> >> code at a very unexpected moment.
> >>
> >
> > This will reduce the interruption and will also as you said possibly catch
> > bugs. We had bugs in some custom python code that didn't get a new token
> > when the keystone server returned certain code, but we found all those in
> > our dev environment.
> >
> > From an operational POV, I can't imagine that any operators will go to
> > work one day and find out that they have a new token provider because of a
> > new default. Wouldn't the settings in keystone.conf be under some kind of
> > config management? I don't know what distros do with new defaults however,
> > maybe that would be the surprise?
> >
> 
> With respect to upgrades, assuming we default to Fernet tokens in the
> Newton release, it's only an issue if the the deployer has no token format
> specified (since it defaulted to UUID pre-Newton), and relied on the
> default after the upgrade (since it'll switches to Fernet in Newton).
> 

Assume all users are using defaults.

> I'm glad Matt outlines his reasoning above since that is nearly exactly
> what Jesse Keating said at the Fernet token work session we had in Austin.
> The straw man we come up with of a deployer that just upgrades without
> checking then config files is just that, a straw man. Upgrades are well
> planned and thought out before being performed. None of the operators in
> the room saw this as an issue. We opened a bug to prevent keystone from
> starting if fernet setup had not been run, and Fernet is the
> selected/defaulted token provider option:
> https://bugs.launchpad.net/keystone/+bug/1576315
> 


Right, I responded there, but just to be clear, this is not about
_operators_ being inconvenienced, it is about _users_.

> For all new installations, deploying your cloud will now have two extra
> steps, running "keystone-manage fernet_setup" and "keystone-manage
> fernet_rotate". We will update the install guide docs accordingly.
> 
> With all that said, we do intend to default to Fernet tokens for the Newton
> release.
> 

Great! They are supremely efficient and I love that we're moving
forward. However, users really do not care about something that just
makes the operator's life easier if it causes all of their stuff to blow
up in non-deterministic ways (since their new jobs won't have that fail,
it will be a really fun day in the debug chair).

> >
> >
> >>
> >> I wonder if one could merge UUID and Fernet into a provider which
> >> handles this transition gracefully:
> >>
> >> if self._fernet_keys:
> >>   return self._issue_fernet_token()
> >> else:
> >>   return self._issue_uuid_token()
> >>
> >> And in the validation, do the same, but also with an eye toward keeping
> >> the UUID tokens alive:
> >>
> >> if self._fernet_keys:
> >>   try:
> >>     self._validate_fernet_token()
> >>   except InvalidFernetFormatting:
> >>     self._validate_uuid_token()
> >> else:
> >>   self._validate_uuid_token()
> >>
> >
> This just seems sneaky/wrong to me. I'd rather see a failure here than
> switch token formats on the fly.
> 

You say "on the fly" I say "when the operator has configured things
fully".

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.

Anyway, the idea could use a few kicks, and I think perhaps a better
way to state what I'm thinking is this:

When the operator has configured a new token format to emit, they should
also be able to allow any previously emitted formats to be validated to
allow users a smooth transition to the new format. We can then make the
default behavior for one release cycle to emit Fernet, and honor both
Fernet and UUID.

Perhaps ignore the other bit that I put in there about switching formats
just because you have fernet keys. Let's say the new pseudo code only
happens in validation:

try:
  self._validate_fernet_token()
except NotAFernetToken:
  self._validate_uuid_token()

I fight for the users -- Tron