Mike, Thanks! +1 to "Let's polish this work before the next release, merge changes to upstream puppet-openstack, and then just use librarian in the next release."
-- dims On Fri, Jul 24, 2015 at 1:39 PM, Mike Scherbakov <[email protected]> wrote: > Thanks guys. Feature Freeze exception request is declined then. Let's polish > this work before the next release, merge changes to upstream > puppet-openstack, and then just use librarian in the next release. > > I'd like to comment Bogdan's email - > unless we fully switch to librarian, I don't agree with: >> 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. > > We can do whatever we need to do based on immediate needs for Fuel, but with > the converging plan. We can't break something in Fuel, for example, just > because we need to fix it puppet upstream first. > > On a separate note, any idea why this email appeared in a new thread in my > inbox, not in the original one? My suspect is that Bogdan's client does > something weird with email headers... > > On Fri, Jul 24, 2015 at 10:30 AM Aleksandr Didenko <[email protected]> > wrote: >> >> 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 <[email protected]> >> 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: >>> [email protected]?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- > Mike Scherbakov > #mihgen > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: https://twitter.com/dims __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
