Cross-project catch-all
We merged a couple of cross-project specifications after adequate discussion and time to review. We now are enabling Python 3 for application integration tests and have changed the requirements management design, please click through to specs.openstack.org and read the details on each.
There’s a lot of discussion about a possible Stackforge retirement in order to alleviate the project github organization renaming work that happens when a project moves from the Stackforge org to the OpenStack org. We are discussing and debating the use cases for Stackforge as a provided CI workflow. So far we have observed four categories of Stackforge projects:
- OpenStack projects using stackforge to incubate until ready
- Projects that just wanted a place to live and don’t have enough energy to propose it to TC
- Projects that are in the OpenStack world that expressly did not want to be under the TC’s oversight (Akanda, StackTach)
- Dead projects
We are hoping to come up with a solution where we can still provide service to all the projects that need it, but reduce the burden on developers and system administrators involved in renaming projects. We would appreciate hearing input on those use cases and if there are any additional use cases for Stackforge, please comment on the review.
We need more cross-project chairs especially in this month, see https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting#Chair_rotation to sign up and talk to Thierry Carrez for how-to run one, he’s happy to provide expectations and training through email.
Healthy debate about starter kits
The last two weeks we have discussed the exact projects to get the starter-kit tag. In a series of reviews we are still debating and discussing the inclusion or exclusion of the OpenStack Networking project neutron as well as OpenStack Block Storage, project cinder.
For some background and history on networking, the nova team has in the past tried to deprecate nova-network, but hasn’t accomplished that deprecation in a few years. When creating an API, the neutron team didn’t keep a compatible set of calls with the nova API (such as how cinder implemented a v1 Volume API that was identical to the original Compute API calls). There is an upgrade path from nova-network to neutron but it is not seamless. In some configurations, since there aren’t exact analogs for the backends, it is possible now for a deployment to stay on nova-network rather than deploying neutron. However the new Networking Guide has a scenario with provider networks and Linux Bridge that is a nice starting point for many deployments. One suggestion is to add that scenario to the Install Guides to help document the starting point. So, we continue to work on the various reviews to apply those tags.
Projects in application process
Compass as a project was discussed in this week’s TC meeting. One question arises since it is a generic deployment framework and not limited to OpenStack, does it need to become an OpenStack project. There’s also an API resource name possibly causing confusion concern, and then we’ve also asked the team to be more open in meetings and communications.
Another project still in the review queue for the TC is the RPM and packaging team or teams. We are awaiting refreshed specification, more progress in discussion and meetings, a PTL (or two?) and scope definition so that we can review again. Questions such as “is this two teams or one for packaging?” still exist.
M naming quest continues
The first three names in the poll have been eliminated due to either trademark difficulty or cultural respect concerns. Stay tuned to the openstack-dev mailing list to find out the M name. We will be specific about geography in release names in the future and continue to work on the open naming processes.
