[tc] Project repository namespaces

Sean McGinnis sean.mcginnis at gmx.com
Tue Mar 19 13:57:29 UTC 2019

> IMHO the key difference between (2) and (3) is that it will be much harder
> to see which projects are part of OpenStack with (3).
> Historically we've seen a lot of confusion with a single "openstack/"
> namespace, with things claiming to be OpenStack projects while not being
> produced by the OpenStack community under the 4 opens.
> The move to opendev gives us an opportunity to move things that are not
> OpenStack out of the "openstack/" namespace, into their own namespaces. But
> if at the same time we also move OpenStack components into their own
> project-level namespaces, then the confusion as to what is a part of
> openstack and what is not will stay.

Do you have a definition for "what is OpenStack?" :)

> So between (2) and (3) I'd really prefer if we did (2).
> > 4) ??
> I'd propose this:
> 4) Create several namespaces to match the OpenStack map[1] buckets:
> - openstack/ to hold first-level components in the central box
> - openstack-operations/ to hold operational tooling from the rights box
> - openstack-lifecyclemanagement/ to hold deployment recipes
> - openstack-user/ for SDK and CLI
> - openstack-adjacentenablers/ for adjacent tech bridges
> Plus:
> - openstack-libs/ to hold libraries and second-order dependencies
> - openstack-dev/ for all repositories that we end up creating in order to
> get things done but have otherwise no relationship with the end product
> [1] https://openstack.org/openstack-map

This makes a lot of sense to me to match the map.

I do kind of like having each team with their own namespace though. There are
several components this community makes that could have use outside of
OpenStack, but with the way it is today, others see it as just an OpenStack
thing and dismiss the idea without much thought. Separating out into team
namespaces would at least give some level of conceptual independence to these
deliverables that could ease that.

But that said, I think this option 4 is very logical and would organize things
well to fit into how things have been laid out in the map, so there's a lot of
value to that.


More information about the openstack-discuss mailing list