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 recommend that all PTL's mark this as a release-blocking bug, in order to buy us more time to get these patches landed. I am working as best I can, however I cannot guarantee that I'll be able to land all these patches in time. Additionally, I will not be able to address issues caused by projects that have not adopted oslo.config's generate-config. I hope those teams will be able to find their own paths forward. Who is willing to help? Michael On Fri, Feb 26, 2016 at 6:09 AM Michael Krotscheck <krotsch...@gmail.com> wrote: > 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, dhellmann doesn't believe we have time for that in Mitaka, since > oslo_middleware is already frozen for the release. I'll mark it as a todo > item for myself, as the next cycle will contain a good amount of additional > work on this portion of openstack. > > Given the time constraints, I'll wait until Tuesday for everyone to weigh > in on the implementation. After that I will start converting the other > projects over as best I can and as I have time. Who is willing to help? > > Michael > > On Thu, Feb 25, 2016 at 9:05 AM Michael Krotscheck <krotsch...@gmail.com> > wrote: > >> On Thu, Feb 18, 2016 at 10:18 AM Morgan Fainberg < >> morgan.fainb...@gmail.com> 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 the timeline a >>> bit rather than hard against feature-freeze. >>> >> >> This sounds like a really good way to get us more time, so I'm in favor >> of this. However, even with the additional time I will not be able to land >> all these patches on my own. >> >> Who is willing to help? >> >> Michael >> >>>
__________________________________________________________________________ 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
