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-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
