Open Stack

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 <krotscheck at 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 <krotscheck at gmail.com>
> wrote:
>
>> On Thu, Feb 18, 2016 at 10:18 AM Morgan Fainberg <
>> morgan.fainberg at 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
>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160301/5bfeb306/attachment.html>