On Mon, Apr 18, 2016 at 12:52 PM, Morgan Fainberg <morgan.fainb...@gmail.com > wrote:
> > > On Mon, Apr 18, 2016 at 7:29 AM, Brant Knudson <b...@acm.org> wrote: > >> >> >> On Fri, Apr 15, 2016 at 9:04 PM, Adam Young <ayo...@redhat.com> wrote: >> >>> We all want Fernet to be a reality. We ain't there yet (Except for >>> mfish who has no patience) but we are getting closer. The goal is to get >>> Fernet as the default token provider as soon as possible. The review to do >>> this has uncovered a few details that need to be fixed before we can do >>> this. >>> >>> Trusts for V2 tokens were not working correctly. Relatively easy fix. >>> https://review.openstack.org/#/c/278693/ Patch is still failing on >>> Python 3. The tests are kindof racy due to the revocation event 1 second >>> granularity. Some of the tests here have A sleep (1) in them still, but >>> all should be using the time control aspect of the unit test fixtures. >>> >>> Some of the tests also use the same user to validate a token as that >>> have, for example, a role unassigned. These expose a problem that the >>> revocation events are catching too many tokens, some of which should not be >>> treated as revoked. >>> >>> Also, some of the logic for revocation checking has to change. Before, >>> if a user had two roles, and had one removed, the token would be revoked. >>> Now, however, the token will validate successful, but the response will >>> only have the single assigned role in it. >>> >>> >>> Python 3 tests are failing because the Fernet formatter is insisting >>> that all project-ids be valid UUIDs, but some of the old tests have "FOO" >>> and "BAR" as ids. These either need to be converted to UUIDS, or the >>> formatter needs to be more forgiving. >>> >>> Caching of token validations was messing with revocation checking. >>> Tokens that were valid once were being reported as always valid. Thus, the >>> current review removes all caching on token validations, a change we >>> cannot maintain. Once all the test are successfully passing, we will >>> re-introduce the cache, and be far more aggressive about cache invalidation. >>> >>> Tempest tests are currently failing due to Devstack not properly >>> identifying Fernet as the default token provider, and creating the Fernet >>> key repository. I'm tempted to just force devstack to always create the >>> directory, as a user would need it if they ever switched the token provider >>> post launch anyway. >>> >>> >> There's a review to change devstack to default to fernet: >> https://review.openstack.org/#/c/195780/ . This was mostly to show that >> tempest still passes with fernet configured. It uncovered a couple of test >> issues (similar in nature to the revocation checking issues mentioned in >> the original note) that have since been fixed. >> >> We'd prefer to not have devstack overriding config options and instead >> use keystone's defaults. The problem is if fernet is the default in >> keystone then it won't work out of the box since the key database won't >> exist. One option that I think we should investigate is to have keystone >> create the key database on startup if it doesn't exist. >> >> > I am unsure if this is the right path, unless we consider possibly moving > the key-DB for fernet into the SQL backend (possible?) notably so we can > control a cluster of keystones. > -1 this idea. Now we've got to figure out how to lock the DB and where will those keys/passwords go? The current model is apparently painful for devstack, but it works fine for anyone who has an automated deployment system, or something else simple like rsync/scp can be used. Fernet keys are simpler to update/replicate than PKI certs and we didn't store those in the DB to my knowledge. Let's please not optimize this solution for devstack. > > If we aren't making the data shared by default, I would rather have > devstack override the keystone default as UUID still seems like the sanest > default due to other config overhead (with filesystem-based fernet keys). > > --Morgan >
__________________________________________________________________________ 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
