[all][foundation][ecosystem] External projects under the foundation hat

Artem Goncharov artem.goncharov at gmail.com
Tue Jun 21 15:03:00 UTC 2022


Hi all,

During the summit we had some nice conversations and I wanted to actually use the chance and try to formalise the discussion to gather broad opinions and ideally solutions.

Sidenotes:>>>>>
- I enjoy opendev
- I really enjoy gerrit and find it an ultimate code review system
- I can understand people not able to cope with additional complexity and prefer pull request pattern to the change pattern
- I use PR change pattern for relatively simple projects (and lot of other huge projects do it this way)
- I am not blaming and not going to blame anybody here
End sidenotes>>>>>>

- Some month ago gophercloud folks came to us and wanted to give source code under the foundation. Feedback from us was more or less: you either host on opendev and use gerrit or not at all. Members of gopher cloud rejected proceeding this way with detailed reasoning. I can fully understand reasonings and I also observe similar issues with auto-closed GitHub PRs (for SDK or OSC) and the fact that those changes in most of the cases never really reach gerrit. Especially in the SDK area it would have been very useful to get various SDKs under single team to spread the know how and synchronise their feature sets. Maybe even use shared credentials to public OpenStack clouds to verify and publish their coverage.

- Some software solutions (especially those based on Golang) were designed with GitHub in mind and are actually not really working outside. For example in order to publish provider for HashiCorp Terraform into their registry your product must be hosted on GitHub (particularly you must upload build artifacts as release on GH). There is sadly no other possibility.

- My company has created HashiCorp secretstore plugin for OpenStack and we are willing to donate this under the foundation to have proper ownership of the software (not to have our company name in the hosting path since it is pretty confusing). From features point of view there is still place to evolve and it would be cool to get other interested parties to participate. We would be able to OpenDev without conceptual issues and are going to request projects for that, but that still has one issue: publishing of binary artifacts - not immediately available in opendev (afaik). On GitHub we publish it as GH Release.

As such the point I am trying to address is that we as a very big project should be bit more open to the world of tools around OpenStack (I mean explicitly **not** the OpenStack itself) and allow easy integration for those who want to extend OpenStack ecosystem. Depending on the particular application this may set certain limitations on the solution (i.e. must be on GitHub, must use Jira, whatever) which might be not compatible out of box with the OpenDev scheme. Do we as a open community want to set strict boundaries or can we ease some of those for the ecosystem around of OpenStack?

- Would it be possible for the project hosted outside opendev be governed by OIF and somehow visually belong to OpenStack? (As a user I would definitely choose to use GitHub.com/openstack/project_x rather then GitHub.com/some_crappy_nic/project_x)
- Can such project enjoy Zuul integration not being part of opendev git hosting? Technically it is surely possible (Ansible modules were tested this way), but requires in my eyes precise definition.

P.S. For the case when zuul/github integration (management) is the only limiting factor I will be gladly supporting the integration and maintenance, since we have created an Ansible collection for managing of GitHub organisations/projects/teams/members (in the project-config spirit) which we use to manage our deployment (and I know others are using it as well).


Tell me what you think and let us, please, focus on how to cope with different expectations rather which one is right and which is wrong.

Thanks a lot,
Artem


More information about the openstack-discuss mailing list