Open Stack

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150724/2560f737/attachment.html>