Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

All patches have been proposed, with the exception of ironic, which implemented its own config generator which does not support defaults. The patch list is available here: https://review.openstack.org/#/q/status:open+branch:master+(topic:bug/1551836) On Tue, Mar 1, 2016 at 8:59 AM Michael

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

The keystone patch has landed. I've gone ahead and filed the appropriate launchpad bug to address this issue: https://bugs.launchpad.net/oslo.config/+bug/1551836 Note: Using latent configuration imposes a forward-going maintenance burden on all projects impacted, if released in mitaka. As such I

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

Alright, I have a first sample patch up for what was discussed in this thread here: (Keystone) https://review.openstack.org/#/c/285308/ The noted TODO on that is the cors middleware should (eventually) provide its own set_defaults method, so that CORS_OPTS isn't exposed publicly. However,

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

On Thu, Feb 18, 2016 at 10:18 AM Morgan Fainberg wrote: > > I am against "option 1". This could be a case where we classify it as a > release blocking bug for Mitaka final (is that reasonable to have m3 with > the current scenario and final to be fixed?), which opens

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

On Thu, Feb 18, 2016 at 9:58 AM Sean Dague wrote: > Here is the future we're going to have. > The future is only going to happen if help materializes. So far, we still need updated patches on all 22 projects, and these will need to land in time for the mitaka release. I can

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

On Thu, Feb 18, 2016 at 11:42 AM Adam Young wrote: > If the deployer does and all-in-one, and all services are on port 443, > CORS is not an issue. > I feel that this is based on the assumption that a cloud will only ever have one GUI, which I already know is not the case.

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

On 02/17/2016 09:26 AM, Michael Krotscheck wrote: We (that is, the cores, contributors, and consumers that I've been collaborating with over the past year on this) came to the consensus that leaving the cors middleware as generic & configurable as possible was preferable, and that an

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

On 02/18/2016 02:00 PM, Morgan Fainberg wrote: Adam, CORS shouldn't need catalog integration ever. CORS is a layer above anything in the service catalog and doesn't provide extra security except signalling to the javascript vm it can access resources outside of it's current domain; something

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

Excerpts from Sean Dague's message of 2016-02-18 12:55:02 -0500: > On 02/18/2016 12:22 PM, Michael Krotscheck wrote: > > On Thu, Feb 18, 2016 at 9:07 AM Doug Hellmann > > wrote: > > > > > > If the deployer is only ever supposed to set

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

Adam, CORS shouldn't need catalog integration ever. CORS is a layer above anything in the service catalog and doesn't provide extra security except signalling to the javascript vm it can access resources outside of it's current domain; something that can be worked around in many ways including

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

On 18 February 2016 at 17:58, Sean Dague wrote: > On 02/18/2016 12:17 PM, Michael Krotscheck wrote: >> Clarifying: >> >> On Thu, Feb 18, 2016 at 2:32 AM Sean Dague > > wrote: >> >> Ok, to make sure we all ended up on the same page at the

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

On 02/18/2016 12:17 PM, Michael Krotscheck wrote: Clarifying: On Thu, Feb 18, 2016 at 2:32 AM Sean Dague > wrote: Ok, to make sure we all ended up on the same page at the end of this discussion, this is what I think I heard. 1) oslo.config

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

On Thu, Feb 18, 2016 at 9:58 AM, Sean Dague wrote: > On 02/18/2016 12:17 PM, Michael Krotscheck wrote: > > Clarifying: > > > > On Thu, Feb 18, 2016 at 2:32 AM Sean Dague > > wrote: > > > > Ok, to make sure we all ended up on the same

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

On 02/18/2016 12:17 PM, Michael Krotscheck wrote: > Clarifying: > > On Thu, Feb 18, 2016 at 2:32 AM Sean Dague > wrote: > > Ok, to make sure we all ended up on the same page at the end of this > discussion, this is what I think I heard. > >

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

On 02/18/2016 12:22 PM, Michael Krotscheck wrote: > On Thu, Feb 18, 2016 at 9:07 AM Doug Hellmann > wrote: > > > If the deployer is only ever supposed to set the value to the default, > why do we let them change it at all? Why isn't

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

On Thu, Feb 18, 2016 at 9:07 AM Doug Hellmann wrote: > > If the deployer is only ever supposed to set the value to the default, > why do we let them change it at all? Why isn't this just something the > app sets? There was a specific request from the ironic team to not

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

Clarifying: On Thu, Feb 18, 2016 at 2:32 AM Sean Dague wrote: > Ok, to make sure we all ended up on the same page at the end of this > discussion, this is what I think I heard. > > 1) oslo.config is about to release with a feature that will make adding > config to paste.ini not

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

On Wed, Feb 17, 2016 at 2:29 PM Doug Hellmann wrote: > > That change only affects sample files and documentation. It has been > possible for applications to override config defaults for ages. Were we > blocked on making effective use of that because of the doc issue for a

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

Excerpts from Sean Dague's message of 2016-02-18 05:29:44 -0500: > Ok, to make sure we all ended up on the same page at the end of this > discussion, this is what I think I heard. > > 1) oslo.config is about to release with a feature that will make adding > config to paste.ini not needed (i.e. >

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

Ok, to make sure we all ended up on the same page at the end of this discussion, this is what I think I heard. 1) oslo.config is about to release with a feature that will make adding config to paste.ini not needed (i.e. https://review.openstack.org/#/c/265415/ is no longer needed). 2) ideally

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

Excerpts from Morgan Fainberg's message of 2016-02-17 14:27:13 -0800: > On Wed, Feb 17, 2016 at 2:24 PM, Doug Hellmann > wrote: > > > Excerpts from Morgan Fainberg's message of 2016-02-17 10:44:50 -0800: > > > I am very much against adding extra data to paste-ini

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

On Wed, Feb 17, 2016 at 2:24 PM, Doug Hellmann wrote: > Excerpts from Morgan Fainberg's message of 2016-02-17 10:44:50 -0800: > > I am very much against adding extra data to paste-ini especially config > > data that is consumed by the applications. I generally understand

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

Excerpts from Morgan Fainberg's message of 2016-02-17 10:44:50 -0800: > I am very much against adding extra data to paste-ini especially config > data that is consumed by the applications. I generally understand why it > was implemented in the way it has. The oslo_config change that Doug linked >

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

I am very much against adding extra data to paste-ini especially config data that is consumed by the applications. I generally understand why it was implemented in the way it has. The oslo_config change that Doug linked will make this need mostly go away however. I would like to move us towards

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

On Wed, Feb 17, 2016 at 9:41 AM Doug Hellmann wrote: > > The next release of oslo.config will have this. > https://review.openstack.org/#/c/278604/ http://stjent.pinnaclecart.com/images/products/preview/55008.jpg Michael

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

Excerpts from Michael Krotscheck's message of 2016-02-17 17:26:57 +: > We (that is, the cores, contributors, and consumers that I've been > collaborating with over the past year on this) came to the consensus that > leaving the cors middleware as generic & configurable as possible was >

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

We (that is, the cores, contributors, and consumers that I've been collaborating with over the past year on this) came to the consensus that leaving the cors middleware as generic & configurable as possible was preferable, and that an openstack-specific version that automatically initializes

[openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

A set of CORS patches came out recently that add a ton of content to paste.ini for every project (much of it the same between projects) - https://review.openstack.org/#/c/265415/1 paste.ini is in a really weird space because it's config, ops can change it, so large amounts of complicated things