Open Stack

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 [1], although some of them do not meet the criteria for the
goals program as currently defined [2].

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

  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 [3]. 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 [4]. 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/BER-t-series-goals
[2] https://governance.openstack.org/tc/goals/index.html
[3] https://etherpad.openstack.org/p/BER-deletion-of-project-resources
[4] 1. https://etherpad.openstack.org/p/api-sig-stein-ptg (line 20)

-- 
Doug