settingsLogin | Registersettings

[openstack-dev] [fuel] FF Exception request for Fernet tokens support.

0 votes

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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Jul 23, 2015 in openstack-dev by Alexander_V_Makarov (900 points)   1 2

11 Responses

0 votes

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@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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jul 24, 2015 by Mike_Scherbakov (9,460 points)   1 4 6
0 votes

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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jul 24, 2015 by Bogdan_Dobrelya (4,920 points)   1 2 7
0 votes

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@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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jul 24, 2015 by Aleksandr_Didenko (3,900 points)   1 5
0 votes

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@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@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@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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jul 24, 2015 by Mike_Scherbakov (9,460 points)   1 4 6
0 votes

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
mscherbakov@mirantis.com 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 adidenko@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@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@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@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@lists.openstack.org?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: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jul 24, 2015 by Davanum_Srinivas (35,920 points)   2 4 9
0 votes

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@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@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@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@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
www.mirantis.ru
vkuklin@mirantis.com


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jul 27, 2015 by Vladimir_Kuklin (7,320 points)   1 3 4
0 votes

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@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@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@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@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@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
www.mirantis.ru
vkuklin@mirantis.com


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jul 27, 2015 by Alexander_V_Makarov (900 points)   1 2
0 votes

I agree. Configuration with memcache made by Fuel now has issues which badly
affect overall OpenStack experience.

On Monday 27 July 2015 14:34:59 Vladimir Kuklin 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@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@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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Best regards,
Boris Bobrov


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jul 27, 2015 by Boris_Bobrov (1,720 points)   1 3
0 votes

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@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@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@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@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@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@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
www.mirantis.ru
vkuklin@mirantis.com


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jul 27, 2015 by Sergii_Golovatiuk (6,080 points)   1 2 3
0 votes

Actually Fernet token IS the best bet on stability and quality.

On Mon, Jul 27, 2015 at 3:23 PM, Sergii Golovatiuk <sgolovatiuk@mirantis.com
wrote:

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@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@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@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@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@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@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
www.mirantis.ru
vkuklin@mirantis.com


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@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@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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jul 27, 2015 by Alexander_V_Makarov (900 points)   1 2
...