> 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: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
