Hi, we were not able to get a working deployment with fernet token support patches, mostly due to issues with keys generation and deployment mechanism. I've also spend some time debugging problems with this and I think it's too risky to land it in 7.0. So I vote for postponing it till 8.0.
Regards, Alex On Fri, Jul 24, 2015 at 10:17 AM, Bogdan Dobrelya <bdobre...@mirantis.com> wrote: > > Fuel Library team, I expect your immediate reply here. > > > > I'd like upgrades team to take a look at this one, as well as at the one > > which moves Keystone under Apache, in order to check that there are no > > issues here. > > > > -1 from me for this time in the cycle. I'm concerned about: > > > > 1. I don't see any reference to blueprint or bug which explains (with > > measurements) why we need this change in reference architecture, and > what > > are the thoughts about it in puppet-openstack, and OpenStack > Keystone. We > > need to get datapoints, and point to them. Just knowing that Keystone > team > > implemented support for it doesn't yet mean that we need to rush in > > enabling this. > > 2. It is quite noticeable change, not a simple enhancement. I reviewed > > the patch, there are questions raised. > > 3. It doesn't pass CI, and I don't have information on risks > associated, > > and additional effort required to get this done (how long would it > take to > > get it done) > > 4. This feature increases complexity of reference architecture. Now > I'd > > like every complexity increase to be optional. I have feedback from > the > > field, that our prescriptive architecture just doesn't fit users' > needs, > > and it is so painful to decouple then what is needed vs what is not. > Let's > > start extending stuff with an easy switch, being propagated from Fuel > > Settings. Is it possible to do? How complex would it be? > > > > If we get answers for all of this, and decide that we still want the > > feature, then it would be great to have it. I just don't feel that it's > > right timing anymore - we entered FF. > > > > Thanks, > > I vote -1 for the same reasons. Besides that, this feature seems already > partially supported in puppet openstack upstream [0], hence should be > developed and finished upstream first. Even if it wasn't at all - we > should follow our contribution rules and do not develop features like > Fernet tokens or v3 API in our forks. > > So, the next steps as I see them are: > > 1) Freeze feature in fuel > 2) Submit a spec to openstack puppet to make the feature completed > (address revocation, expiration, rotation of the fernet tokens). This > also seems related to the already existing blueprint for fuel [1] and > the mail thread [2] > 3) Implement the feature upstream > 4) Backport this to fuel fork in 8.0, or consume it upstream > directly in the case the related blueprint [3] will be already > implemented by that time. > > [0] https://review.openstack.org/185441 > [1] https://blueprints.launchpad.net/fuel/+spec/fernet-tokens-support > [2] > http://lists.openstack.org/pipermail/openstack-dev/2015-July/069744.html > [3] https://blueprints.launchpad.net/fuel/+spec/fuel-puppet-librarian > > -- > Best regards, > Bogdan Dobrelya, > Irc #bogdando > > __________________________________________________________________________ > 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