[openstack-dev] [oslo] PTG summary

Ben Nemec openstack at nemebean.com
Tue Feb 28 00:33:38 UTC 2017

On 02/27/2017 03:30 PM, Doug Hellmann wrote:
> Excerpts from ChangBo Guo's message of 2017-02-25 00:07:21 +0800:
>> Oslo folks,
>> This is summary of  oslo PTG schedule during one and half days. You can
>> check the details in etherpad link:
>> https://etherpad.openstack.org/p/oslo-ptg-pike
>> 1. oslo.messaging: consistent names for general driver configuration options
>>    Some of supported drviers have various option configuration names with
>> for common usage, This has led to a plethora of different configuration
>> options that complicates the   development of Day 1 deployment and
>> configuration tools. We propose that 'scrub' the configuration namespace
>> and come up with common generic names that can be shared among the various
>> drivers. Note: this is *not* calling for moving these configuration items
>> 'up' to the DEFAULT group.  Each driver should be able to have its own
>> value for any given configuration setting.  This is necessary for the dual
>> backend deployment scenario.
>> 2. Messaging Experiences towards hybrid backends
>>    Share experience and progress towards introducing dual messaging backend
>> operation :
>> https://docs.google.com/presentation/d/1Y-3gH8rxrU5KagvDQiqpByfvmgM8no-PLn1O0IT5PCs/edit?usp=sharing
>> 3.How to make oslo work done in an efficient way
>>    1)Track bugs & reviews accoding to their priorities
>>    2)Record general core reviewers' focus to help get help from them.
>> https://etherpad.openstack.org/p/oslo-pike-tracking
>>    3) Don't migrate to StoryBoard until that's a community goal .
>> 4.Add a new policy rule to check specific metadata key
>>   Decide to change nova codes instead of oslo.policy
>> https://etherpad.openstack.org/p/policy_support_for_specific_metadata_keys
>> 5. Discuss oslo_messaging.rpc message encryption and security
>>     Trove implements this function in its code base, wan to code be
>> included in oslo.messaging.
>>     kgiusti - followup with amrith on possible API (message digest)
>> 6. Feature updates & collect ideas
>>    1) Josh propose a new library to handle remote exceptions in an united
>> way: http://pypi.python.org/pypi/failure
>>        Need improve it in code and documentation , test in gate , then adop
>> it .
>>        gcb will talk with Nova PTL if nova want to adopt it.
>>   2) new functions from neutron(ihrachys): ability to cancel in
>> progress/blocked RPC requests in oslo.messaging
>>       ihrachys will file a bug, describe use cases to track this.
>> we also did bug smash to reduce bug numbers in rest of time.
> A few topics came up outside of the Oslo room, or later in the week.
> 1. The new Deployment working group is interested in being able to
> generate a data file listing all of the configuration options for
> a service, to be used to drive a UI for filling in those options.
> It isn't clear yet whether this will be a completely new addition
> to the config generator in oslo.config, or if the existing generator
> can be extended to support a new format (we talked about YAML).

Emilien and I are planning to write up a spec with details about what 
we'd like to do and why.

> 2. We are looking at removing the warnerrors flag from pbr. It is
> currently broken, but there is an unreleased patch to fix it.
> Releasing that in its current state has a high chance of breaking
> doc builds across the community, so I put together a patch to rename
> it. Then Stephen pointed out that Sphinx 1.5 includes its own flag,
> which can also be set in setup.cfg. We agreed it made more sense
> to drop the flag from pbr and use that one, because it would be
> backwards-compatible (in the sense that pbr currently doesn't honor
> the flag it does claim to understand).  See
> https://review.openstack.org/#/c/438510/ for Stephen's patch.

I tried this on tripleo-docs and it seems to be working.  Looks like a 
good way forward to me.

> 3. I intend to resume the work on making pbr include reno-generated
> release notes text files in sdist packages. That will probably have
> to wait until after the second milestone, unless someone else is
> interested in picking it up.
> Doug
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

More information about the OpenStack-dev mailing list