Open Stack

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 <adidenko at mirantis.com>
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 <bdobrelia at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
Mike Scherbakov
#mihgen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150724/5c441816/attachment.html>