Open Stack

Guys, I object of merging Fernet tokens. I set -2 for any Fernet related
activities. Firstly, there are some ongoing discussions how we should
distribute, revoke, rotate SSL keys for Fernet. Secondly, there some
discussion in community about potential security concerns where user may
renew token instantly. Additionally, we've already introduced apache wsgi
which may have own implication on keystone itself. It's a bit late for 7.0.
Let's focus on stability and quality.



--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser

On Mon, Jul 27, 2015 at 1:52 PM, Alexander Makarov <amakarov at mirantis.com>
wrote:

> I've filed a ticket to test Fernet token on the scale lab:
> https://mirantis.jira.com/browse/MOSS-235
>
> If this feature is not granted FFE we still can configure it manually by
> changing keystone config.
> So I think internal how-to document backed-up with scale and bvt testing
> will allow our deployers to deliver Fernet to our customers.
> 1 more thing: in the Community this feature is considered experimantal, so
> maybe setting it as a default is a bit premature?
>
> On Mon, Jul 27, 2015 at 2:34 PM, Vladimir Kuklin <vkuklin at mirantis.com>
> wrote:
>
>> Folks
>>
>> We saw several High issues with how keystone manages regular memcached
>> tokens. I know, this is not the perfect time as you already decided to push
>> it from 7.0, but I would reconsider declaring it as FFE as it affects HA
>> and UX poorly. If we can enable tokens simply by altering configuration,
>> let's do it. I see commit for this feature is pretty trivial.
>>
>> On Fri, Jul 24, 2015 at 9:27 AM, Mike Scherbakov <
>> mscherbakov 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,
>>>
>>> On Thu, Jul 23, 2015 at 11:53 AM Alexander Makarov <
>>> amakarov at mirantis.com> wrote:
>>>
>>>> Colleagues,
>>>>
>>>> I would like to request an exception from the Feature Freeze for Fernet
>>>> tokens support added to the fuel-library in the following CR:
>>>> https://review.openstack.org/#/c/201029/
>>>>
>>>> Keystone part of the feature is implemented in the upstream and the
>>>> change impacts setup configuration only.
>>>>
>>>> Please, respond if you have any questions or concerns related to this
>>>> request.
>>>>
>>>> Thanks in advance.
>>>>
>>>> --
>>>> Kind Regards,
>>>> Alexander Makarov,
>>>> Senior Software Developer,
>>>>
>>>> Mirantis, Inc.
>>>> 35b/3, Vorontsovskaya St., 109147, Moscow, Russia
>>>>
>>>> Tel.: +7 (495) 640-49-04
>>>> Tel.: +7 (926) 204-50-60
>>>>
>>>> Skype: MAKAPOB.AJIEKCAHDP
>>>>
>>>> __________________________________________________________________________
>>>> 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
>>>
>>>
>>> __________________________________________________________________________
>>> 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
>>>
>>>
>>
>>
>> --
>> Yours Faithfully,
>> Vladimir Kuklin,
>> Fuel Library Tech Lead,
>> Mirantis, Inc.
>> +7 (495) 640-49-04
>> +7 (926) 702-39-68
>> Skype kuklinvv
>> 35bk3, Vorontsovskaya Str.
>> Moscow, Russia,
>> www.mirantis.com <http://www.mirantis.ru/>
>> www.mirantis.ru
>> vkuklin at mirantis.com
>>
>> __________________________________________________________________________
>> 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
>>
>>
>
>
> --
> Kind Regards,
> Alexander Makarov,
> Senior Software Developer,
>
> Mirantis, Inc.
> 35b/3, Vorontsovskaya St., 109147, Moscow, Russia
>
> Tel.: +7 (495) 640-49-04
> Tel.: +7 (926) 204-50-60
>
> Skype: MAKAPOB.AJIEKCAHDP
>
> __________________________________________________________________________
> 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/20150727/7554c36c/attachment.html>