If we were to write a uuid/fernet hybrid provider, it would only be expected to support something like stable/liberty to stable/mitaka, right? This is something that we could contribute to stackforge, too.
On Tue, May 3, 2016 at 9:21 AM, Adam Young <ayo...@redhat.com> wrote: > On 05/03/2016 09:55 AM, Clint Byrum wrote: > >> 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 <m...@mattfischer.com> >>> wrote: >>> >>> On Mon, May 2, 2016 at 5:26 PM, Clint Byrum <cl...@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 was actually thinking of a different migration strategy, exactly the > opposite: for a while, run with the uuid tokens, but store the Fernet > body. After while, switch from validating the uuid token body to the > stored Fernet. Finally, switch to validating the Fernet token from the > request. That way, we always have only one token provider, and the > migration can happen step by step. > > It will not help someone that migrates from Icehouse to Ocata. Then again, > the dual plan you laid out above will not either; at some point, people > will have to dump the token table to make major migrations. > > > > > > >> I fight for the users -- Tron >> >> __________________________________________________________________________ >> 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 >> > > > __________________________________________________________________________ > 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 >
__________________________________________________________________________ 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
