Thanks Brant, I will missing that distinction.
On Mon, Apr 18, 2016 at 9:43 AM, Brant Knudson <b...@acm.org> wrote: > > > On Mon, Apr 18, 2016 at 10:20 AM, Matt Fischer <m...@mattfischer.com> > wrote: > >> On Mon, Apr 18, 2016 at 8: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. >>> >>> - Brant >>> >>> >> >> I'm not a devstack user, but as I mentioned before, I assume devstack >> called keystone-manage db_sync? Why couldn't it also call keystone-manage >> fernet_setup? >> >> > When you tell devstack that it's using fernet then it does keystone-manage > fernet_setup. When you tell devstack to use the default, it doesn't > fernet_setup because for now it thinks the default is UUID and doesn't > require keys. One way to have devstack work when fernet is the default is > to have devstack always do keystone-manage fernet_setup. > > Really what we want to do is have devstack work like other deployment > methods. We can reasonably expect featureful deployers like puppet to > keystone-manage fernet_setup in the course of setting up keystone. There's > more basic deployers like RPMs or debs that in the past have said they like > the defaults to "just work" (like UUID tokens) and not require extra > commands. > > - Brant > > > __________________________________________________________________________ > 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