[goals][tc] community-wide goals for train development cycle
doug at doughellmann.com
Tue Nov 20 00:28:37 UTC 2018
Last week at the Forum in Berlin we met to discuss potential
community-wide goals for the Train development cycle. We had a good list
of proposals , although some of them do not meet the criteria for the
goals program as currently defined .
We came up with a few suggestions that do fit the criteria, listed here
in the order we discussed them:
* Ensure that each project has contributor on-boarding documentation in
a discoverable place in their documentation tree, and link to that
from the contributor portal at openstack.org/community. (proposed by
This should be relatively light-weight for teams to do, and will
uncover some good opportunities for documentation reuse.
* Deletion of project resources. (proposed by tobberydberg and adriant)
This has been a long-standing request from operators, as discussed in
forum session earlier in the week . The propose next-steps are to
establish a way for the existing os-purge program to accept plugins so
that project teams can declare the relationships between resources
that need to be deleted, to make orchestration easier. See the
etherpad from the session for more details.
* Finish moving legacy python-*client CLIs to python-openstackclient
(proposed by mriedem on behalf of Tim Bell)
This is another initiative that has been going on for a few years, and
completing it would give users more clarity as well as providing a
more consistent user interface. The general idea was to finish
implementing all of the commands within OSC using the existing client
libs, then update the SDK to support those features so we can drop the
client libs from OSC as well, giving us 1 SDK and 1 CLI. That’s a
multi-step process, so I think for the first phase targeting
completing all of the commands within OSC using the various client
libraries would be enough for 1 cycle.
* Ensure all projects pass request-id when calling one
another. (proposed by Pavlo Shchelokovskyy)
Passing request-id allows us to chain requests together and trace them
for debugging and profiling. We started this a while back and some
projects are doing it but not all.
* Rolling out oslo health-check middleware so each project provides that
API. (proposed by mugsie)
This came up at the PTG in Denver earlier this year . There will be
some up-front work to make the health check API able to support real
backend checks for the database, message bus, etc. Then we would need
to add the middleware to all services.
In all of these cases, we have a bit more up-front work to do to be
ready to accept the idea as a goal. There should be time during the
remainder of the Stein cycle to make enough progress on that work to
know if we could accept it as a goal.
Our next steps are for the people proposing these goals to ensure that
up-front work is done and be prepared to write up the goal document for
review. If the proposes aren’t able/willing to act as goal champions, we
need to identify someone else to fill that role.
I propose we set a target of early March for having the formal goal
proposals ready for review. That will give us time to approve them well
before the next Summit/PTG, so that teams can use time during the PTG
for planning their implementation.
 1. https://etherpad.openstack.org/p/api-sig-stein-ptg (line 20)
More information about the openstack-discuss