<div dir="ltr">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.<div><br></div><div>I'd like to comment Bogdan's email - </div><div>unless we fully switch to librarian, I don't agree with:</div><div><span style="font-size:13.1999998092651px;line-height:19.7999992370605px">> Besides that, this feature seems already</span><br style="font-size:13.1999998092651px;line-height:19.7999992370605px"><span style="font-size:13.1999998092651px;line-height:19.7999992370605px">> partially supported in puppet openstack upstream [0], hence should be</span><br style="font-size:13.1999998092651px;line-height:19.7999992370605px"><span style="font-size:13.1999998092651px;line-height:19.7999992370605px">> developed and finished upstream first. Even if it wasn't at all - we</span><br style="font-size:13.1999998092651px;line-height:19.7999992370605px"><span style="font-size:13.1999998092651px;line-height:19.7999992370605px">> should follow our contribution rules and do not develop features like</span><br style="font-size:13.1999998092651px;line-height:19.7999992370605px"><span class="lG" style="font-size:13.1999998092651px;line-height:19.7999992370605px">> Fernet</span><span style="font-size:13.1999998092651px;line-height:19.7999992370605px"> tokens or v3 API in our forks.</span><br></div><div><span style="font-size:13.1999998092651px;line-height:19.7999992370605px"><br></span></div><div><span style="font-size:13.1999998092651px;line-height:19.7999992370605px">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. </span></div><div><span style="font-size:13.1999998092651px;line-height:19.7999992370605px"><br></span></div><div><span style="font-size:13.1999998092651px;line-height:19.7999992370605px">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...</span></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jul 24, 2015 at 10:30 AM Aleksandr Didenko <<a href="mailto:adidenko@mirantis.com">adidenko@mirantis.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>Hi,<br><br></div>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.<br><br></div>Regards,<br></div>Alex<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 24, 2015 at 10:17 AM, Bogdan Dobrelya <span dir="ltr"><<a href="mailto:bdobrelia@mirantis.com" target="_blank">bdobrelia@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> Fuel Library team, I expect your immediate reply here.<br>
><br>
> I'd like upgrades team to take a look at this one, as well as at the one<br>
> which moves Keystone under Apache, in order to check that there are no<br>
> issues here.<br>
><br>
> -1 from me for this time in the cycle. I'm concerned about:<br>
><br>
> 1. I don't see any reference to blueprint or bug which explains (with<br>
> measurements) why we need this change in reference architecture, and what<br>
> are the thoughts about it in puppet-openstack, and OpenStack Keystone. We<br>
> need to get datapoints, and point to them. Just knowing that Keystone team<br>
> implemented support for it doesn't yet mean that we need to rush in<br>
> enabling this.<br>
> 2. It is quite noticeable change, not a simple enhancement. I reviewed<br>
> the patch, there are questions raised.<br>
> 3. It doesn't pass CI, and I don't have information on risks associated,<br>
> and additional effort required to get this done (how long would it take to<br>
> get it done)<br>
> 4. This feature increases complexity of reference architecture. Now I'd<br>
> like every complexity increase to be optional. I have feedback from the<br>
> field, that our prescriptive architecture just doesn't fit users' needs,<br>
> and it is so painful to decouple then what is needed vs what is not. Let's<br>
> start extending stuff with an easy switch, being propagated from Fuel<br>
> Settings. Is it possible to do? How complex would it be?<br>
><br>
> If we get answers for all of this, and decide that we still want the<br>
> feature, then it would be great to have it. I just don't feel that it's<br>
> right timing anymore - we entered FF.<br>
><br>
> Thanks,<br>
<br>
I vote -1 for the same reasons. Besides that, this feature seems already<br>
partially supported in puppet openstack upstream [0], hence should be<br>
developed and finished upstream first. Even if it wasn't at all - we<br>
should follow our contribution rules and do not develop features like<br>
Fernet tokens or v3 API in our forks.<br>
<br>
So, the next steps as I see them are:<br>
<br>
1) Freeze feature in fuel<br>
2) Submit a spec to openstack puppet to make the feature completed<br>
(address revocation, expiration, rotation of the fernet tokens). This<br>
also seems related to the already existing blueprint for fuel [1] and<br>
the mail thread [2]<br>
3) Implement the feature upstream<br>
4) Backport this to fuel fork in 8.0, or consume it upstream<br>
directly in the case the related blueprint [3] will be already<br>
implemented by that time.<br>
<br>
[0] <a href="https://review.openstack.org/185441" rel="noreferrer" target="_blank">https://review.openstack.org/185441</a><br>
[1] <a href="https://blueprints.launchpad.net/fuel/+spec/fernet-tokens-support" rel="noreferrer" target="_blank">https://blueprints.launchpad.net/fuel/+spec/fernet-tokens-support</a><br>
[2] <a href="http://lists.openstack.org/pipermail/openstack-dev/2015-July/069744.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2015-July/069744.html</a><br>
[3] <a href="https://blueprints.launchpad.net/fuel/+spec/fuel-puppet-librarian" rel="noreferrer" target="_blank">https://blueprints.launchpad.net/fuel/+spec/fuel-puppet-librarian</a><br>
<span><font color="#888888"><br>
--<br>
Best regards,<br>
Bogdan Dobrelya,<br>
Irc #bogdando<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</font></span></blockquote></div><br></div>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><div dir="ltr">-- <br></div><div dir="ltr">Mike Scherbakov<br>#mihgen</div>