Re: [openstack-dev] [fuel] FF Exception request for Fernet tokens support.
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 mscherba...@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 amaka...@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-requ...@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-requ...@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 vkuk...@mirantis.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [fuel] FF Exception request for Fernet tokens support.
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 mscherba...@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 amaka...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [fuel] FF Exception request for Fernet tokens support.
Actually Fernet token IS the best bet on stability and quality. On Mon, Jul 27, 2015 at 3:23 PM, Sergii Golovatiuk sgolovat...@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 amaka...@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 vkuk...@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 mscherba...@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 amaka...@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-requ...@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-requ...@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 vkuk...@mirantis.com
Re: [openstack-dev] [fuel] FF Exception request for Fernet tokens support.
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 vkuk...@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 mscherba...@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 amaka...@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-requ...@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-requ...@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 vkuk...@mirantis.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [fuel] FF Exception request for Fernet tokens support.
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 amaka...@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 vkuk...@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 mscherba...@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 amaka...@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-requ...@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-requ...@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 vkuk...@mirantis.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:
Re: [openstack-dev] [fuel] FF Exception request for Fernet tokens support.
On 07/27/2015 04:52 AM, Alexander Makarov wrote: I've filed a ticket to test Fernet token on the scale lab: https://mirantis.jira.com/browse/MOSS-235 This is good, but keep in mind that the broader community does not have access to the Mirantis JIRA :) Probably better to just mention you have submitted a request to our scale lab than provide a link that only a subset of the community may access. Best, -jay __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [fuel] FF Exception request for Fernet tokens support.
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 amaka...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [fuel] FF Exception request for Fernet tokens support
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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [fuel] FF Exception request for Fernet tokens support
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 bdobre...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [fuel] FF Exception request for Fernet tokens support
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 adide...@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 bdobre...@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-requ...@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-requ...@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:
Re: [openstack-dev] [fuel] FF Exception request for Fernet tokens support
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 mscherba...@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 adide...@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 bdobre...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:
