[tc] Project repository namespaces
Hi all, With OpenDev needing to change git URLs for all projects, we have an opportunity to change how we namespace projects that are currently under the "openstack" namespace.[0] I've heard a few options thrown out: 1) Keep everything the same. This is the easiest option for everybody, but keeps our current confusion of what is officially OpenStack, and what is not. 2) Move unofficial projects to "stackforge" or some other namespace, which is only a small amount of work to list the repositories, but probably a large amount of bikeshedding^Wdiscussion to come up with a name. 3) Do (2), but also namespace the OpenStack projects in a more fine-grained manner, by project team. For example: nova/nova, ironic/bifrost, etc. This is a larger chunk of work, but looks a bit nicer. Also makes it easier to move a project out of OpenStack later, as we don't have to move namespaces. This has an open question of whether we use one large namespace for unofficial projects, or give them each their own. It also has a downside of making more effort to move a repository between project teams, though I think that's fairly rare. 4) ?? I personally like (2) or (3), but would like to hear from the rest of the community. I'll propose a governance resolution after the discussion here, and we can follow from there with whatever else needs to be done. // jim [0] http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003603.htm...
I vote for option 2, without too much complexity Cheers, Lingxian Kong On Tue, Mar 19, 2019 at 9:53 AM Jim Rollenhagen <jim@jimrollenhagen.com> wrote:
Hi all,
With OpenDev needing to change git URLs for all projects, we have an opportunity to change how we namespace projects that are currently under the "openstack" namespace.[0]
I've heard a few options thrown out:
1) Keep everything the same. This is the easiest option for everybody, but keeps our current confusion of what is officially OpenStack, and what is not.
2) Move unofficial projects to "stackforge" or some other namespace, which is only a small amount of work to list the repositories, but probably a large amount of bikeshedding^Wdiscussion to come up with a name.
3) Do (2), but also namespace the OpenStack projects in a more fine-grained manner, by project team. For example: nova/nova, ironic/bifrost, etc. This is a larger chunk of work, but looks a bit nicer. Also makes it easier to move a project out of OpenStack later, as we don't have to move namespaces. This has an open question of whether we use one large namespace for unofficial projects, or give them each their own. It also has a downside of making more effort to move a repository between project teams, though I think that's fairly rare.
4) ??
I personally like (2) or (3), but would like to hear from the rest of the community. I'll propose a governance resolution after the discussion here, and we can follow from there with whatever else needs to be done.
// jim
[0] http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003603.htm...
I like 3 but will settle for 2 to minimize work. From: Lingxian Kong <anlin.kong@gmail.com> Sent: Monday, March 18, 2019 4:01 PM To: Jim Rollenhagen Cc: openstack-discuss Subject: Re: [tc] Project repository namespaces [EXTERNAL EMAIL] I vote for option 2, without too much complexity Cheers, Lingxian Kong On Tue, Mar 19, 2019 at 9:53 AM Jim Rollenhagen <jim@jimrollenhagen.com<mailto:jim@jimrollenhagen.com>> wrote: Hi all, With OpenDev needing to change git URLs for all projects, we have an opportunity to change how we namespace projects that are currently under the "openstack" namespace.[0] I've heard a few options thrown out: 1) Keep everything the same. This is the easiest option for everybody, but keeps our current confusion of what is officially OpenStack, and what is not. 2) Move unofficial projects to "stackforge" or some other namespace, which is only a small amount of work to list the repositories, but probably a large amount of bikeshedding^Wdiscussion to come up with a name. 3) Do (2), but also namespace the OpenStack projects in a more fine-grained manner, by project team. For example: nova/nova, ironic/bifrost, etc. This is a larger chunk of work, but looks a bit nicer. Also makes it easier to move a project out of OpenStack later, as we don't have to move namespaces. This has an open question of whether we use one large namespace for unofficial projects, or give them each their own. It also has a downside of making more effort to move a repository between project teams, though I think that's fairly rare. 4) ?? I personally like (2) or (3), but would like to hear from the rest of the community. I'll propose a governance resolution after the discussion here, and we can follow from there with whatever else needs to be done. // jim [0] http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003603.htm...
Jim Rollenhagen <jim@jimrollenhagen.com> writes:
Hi all,
With OpenDev needing to change git URLs for all projects, we have an opportunity to change how we namespace projects that are currently under the "openstack" namespace.[0]
I've heard a few options thrown out:
1) Keep everything the same. This is the easiest option for everybody, but keeps our current confusion of what is officially OpenStack, and what is not.
2) Move unofficial projects to "stackforge" or some other namespace, which is only a small amount of work to list the repositories, but probably a large amount of bikeshedding^Wdiscussion to come up with a name.
3) Do (2), but also namespace the OpenStack projects in a more fine-grained manner, by project team. For example: nova/nova, ironic/bifrost, etc. This is a larger chunk of work, but looks a bit nicer. Also makes it easier to move a project out of OpenStack later, as we don't have to move namespaces. This has an open question of whether we use one large namespace for unofficial projects, or give them each their own. It also has a downside of making more effort to move a repository between project teams, though I think that's fairly rare.
It also makes it easier to bring a new project *in*, which is also not that frequent an occurrence these days but does still happen.
4) ??
I personally like (2) or (3), but would like to hear from the rest of the community. I'll propose a governance resolution after the discussion here, and we can follow from there with whatever else needs to be done.
I don't like 1 but don't have a strong opinion between 2 and 3.
// jim
[0] http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003603.htm...
-- Doug
On 19-03-18 16:49:47, Jim Rollenhagen wrote:
Hi all,
With OpenDev needing to change git URLs for all projects, we have an opportunity to change how we namespace projects that are currently under the "openstack" namespace.[0]
I've heard a few options thrown out:
1) Keep everything the same. This is the easiest option for everybody, but keeps our current confusion of what is officially OpenStack, and what is not.
2) Move unofficial projects to "stackforge" or some other namespace, which is only a small amount of work to list the repositories, but probably a large amount of bikeshedding^Wdiscussion to come up with a name.
3) Do (2), but also namespace the OpenStack projects in a more fine-grained manner, by project team. For example: nova/nova, ironic/bifrost, etc. This is a larger chunk of work, but looks a bit nicer. Also makes it easier to move a project out of OpenStack later, as we don't have to move namespaces. This has an open question of whether we use one large namespace for unofficial projects, or give them each their own. It also has a downside of making more effort to move a repository between project teams, though I think that's fairly rare.
4) ??
I personally like (2) or (3), but would like to hear from the rest of the community. I'll propose a governance resolution after the discussion here, and we can follow from there with whatever else needs to be done.
// jim
[0] http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003603.htm...
I like option 3, with it you get things like openstack-ansible/os_nova instead of openstack-ansible-os_nova. It works for things like ironic/ironic-lib and the like as well. I'd settle for option 2 if needed. -- Matthew Thode
On 19-03-18 16:18:24, Matthew Thode wrote:
On 19-03-18 16:49:47, Jim Rollenhagen wrote:
Hi all,
With OpenDev needing to change git URLs for all projects, we have an opportunity to change how we namespace projects that are currently under the "openstack" namespace.[0]
I've heard a few options thrown out:
1) Keep everything the same. This is the easiest option for everybody, but keeps our current confusion of what is officially OpenStack, and what is not.
2) Move unofficial projects to "stackforge" or some other namespace, which is only a small amount of work to list the repositories, but probably a large amount of bikeshedding^Wdiscussion to come up with a name.
3) Do (2), but also namespace the OpenStack projects in a more fine-grained manner, by project team. For example: nova/nova, ironic/bifrost, etc. This is a larger chunk of work, but looks a bit nicer. Also makes it easier to move a project out of OpenStack later, as we don't have to move namespaces. This has an open question of whether we use one large namespace for unofficial projects, or give them each their own. It also has a downside of making more effort to move a repository between project teams, though I think that's fairly rare.
4) ??
I personally like (2) or (3), but would like to hear from the rest of the community. I'll propose a governance resolution after the discussion here, and we can follow from there with whatever else needs to be done.
// jim
[0] http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003603.htm...
I like option 3, with it you get things like openstack-ansible/os_nova instead of openstack-ansible-os_nova. It works for things like ironic/ironic-lib and the like as well. I'd settle for option 2 if needed.
Thinking more on it I think we could do option 3 but have the repo moves be ad-hoc, or perhaps at some redefined point in the cycle (at branch time or something). That should make it easier to do the move. -- Matthew Thode
On 2019-03-18 18:19:53 -0500 (-0500), Matthew Thode wrote:
On 19-03-18 16:18:24, Matthew Thode wrote:
On 19-03-18 16:49:47, Jim Rollenhagen wrote: [...]
2) Move unofficial projects to "stackforge" or some other namespace, which is only a small amount of work to list the repositories, but probably a large amount of bikeshedding^Wdiscussion to come up with a name.
3) Do (2), but also namespace the OpenStack projects in a more fine-grained manner, by project team. For example: nova/nova, ironic/bifrost, etc. This is a larger chunk of work, but looks a bit nicer. Also makes it easier to move a project out of OpenStack later, as we don't have to move namespaces. This has an open question of whether we use one large namespace for unofficial projects, or give them each their own. It also has a downside of making more effort to move a repository between project teams, though I think that's fairly rare. [...] I like option 3, with it you get things like openstack-ansible/os_nova instead of openstack-ansible-os_nova. It works for things like ironic/ironic-lib and the like as well. I'd settle for option 2 if needed.
Thinking more on it I think we could do option 3 but have the repo moves be ad-hoc, or perhaps at some redefined point in the cycle (at branch time or something). That should make it easier to do the move.
It's probably not been reiterated outside the implementation detail discussions for the OpenDev Gerrit/Git transition, but unlike prior project renames we'll actually be instituting rewrites and redirects on the Git URLs so the impact should be much reduced. While doing the renames once during the main transition does require more up-front planning, it would actually be "easier" on the community at large than kicking the namespace explosion can down the road. -- Jeremy Stanley
On Mon, Mar 18, 2019 at 04:49:47PM -0400, Jim Rollenhagen wrote:
2) Move unofficial projects to "stackforge" or some other namespace, which is only a small amount of work to list the repositories, but probably a large amount of bikeshedding^Wdiscussion to come up with a name.
3) Do (2), but also namespace the OpenStack projects in a more fine-grained manner, by project team. For example: nova/nova, ironic/bifrost, etc. This is a larger chunk of work, but looks a bit nicer. Also makes it easier to move a project out of OpenStack later, as we don't have to move namespaces. This has an open question of whether we use one large namespace for unofficial projects, or give them each their own. It also has a downside of making more effort to move a repository between project teams, though I think that's fairly rare.
From the perspective of one who works in the Neutron Stadium, it would be really convenient to have those projects under a 'neutron' space so that it was obviously clear to everyone what is in or out of the Stadium - even for projects that don't necessarily look neutron-related based on the name, like os-ken or ovsdbapp.
Nate
I agree with the majority so far that option 3 looks ideal but 2 looks more realistic as far as what we can get done easily. Who would be on the hook to do the actual work here? I'm happy to sign someone else up for work I guess, but I'd like to know who it is so I can buy them a beverage to alleviate my guilt. ;) --Adam On Tue, Mar 19, 2019, 06:27 Nate Johnston <nate.johnston@redhat.com> wrote:
On Mon, Mar 18, 2019 at 04:49:47PM -0400, Jim Rollenhagen wrote:
2) Move unofficial projects to "stackforge" or some other namespace, which is only a small amount of work to list the repositories, but probably a large amount of bikeshedding^Wdiscussion to come up with a name.
3) Do (2), but also namespace the OpenStack projects in a more fine-grained manner, by project team. For example: nova/nova, ironic/bifrost, etc. This is a larger chunk of work, but looks a bit nicer. Also makes it easier to move a project out of OpenStack later, as we don't have to move namespaces. This has an open question of whether we use one large namespace for unofficial projects, or give them each their own. It also has a downside of making more effort to move a repository between project teams, though I think that's fairly rare.
From the perspective of one who works in the Neutron Stadium, it would be really convenient to have those projects under a 'neutron' space so that it was obviously clear to everyone what is in or out of the Stadium - even for projects that don't necessarily look neutron-related based on the name, like os-ken or ovsdbapp.
Nate
On 2019-03-19 08:02:16 +0900 (+0900), Adam Harwell wrote:
I agree with the majority so far that option 3 looks ideal but 2 looks more realistic as far as what we can get done easily. Who would be on the hook to do the actual work here? I'm happy to sign someone else up for work I guess, but I'd like to know who it is so I can buy them a beverage to alleviate my guilt. ;) [...]
At this stage the only work which lacks volunteers is deciding and documenting what namespaces to use for which projects. A batch of namespace changes will be scripted by OpenDev sysadmins as part of preparation for the Git/Gerrit transition maintenance. -- Jeremy Stanley
On 2019-03-19 08:02:16 +0900 (+0900), Adam Harwell wrote:
I agree with the majority so far that option 3 looks ideal but 2 looks more realistic as far as what we can get done easily. Who would be on the hook to do the actual work here? I'm happy to sign someone else up for work I guess, but I'd like to know who it is so I can buy them a beverage to alleviate my guilt. ;)
[...]
At this stage the only work which lacks volunteers is deciding and documenting what namespaces to use for which projects. A batch of namespace changes will be scripted by OpenDev sysadmins as part of preparation for the Git/Gerrit transition maintenance.
On Tue, 2019-03-19 at 00:58 +0000, Jeremy Stanley wrote: the only concern i have with this discution is for formor stackforage projects. in partacalr i maintain networking-ovs-dpdk which is not part of the neutron statidum or an offical openstack project. it started life on my github got imported to stackforge then moved to openstack namespace when stackforge was retrired. im happy for it to move back to strackforge but there is already of redirect form https://github.com/stackforge/networking-ovs-dpdk to https://github.com/openstack/networking-ovs-dpdk in place so we would have to undo those redirects when the new ones are created. networking-ovs-dpdk can be a neutron stadium project as we cant test it in the gate as it needs nested virt but i could technically propose it under as a devstack project if we wanted to make it official at somepoint as it is primarily a devestack plugin at this point and i plan to remove the remaining python code soon. Anyway thats beside the point. What i wanted to highlight is if we move project back to stackforge that were previously in stackforge we just need to be carful not to end up with a redirect loop. Actully if https://github.com/openstack/networking-ovs-dpdk was redirect to https://opendev/stackforge/networking-ovs-dpdk that might break the cycle but im sure we can figure that out. i just wanted to point out the posible edgecase before someone automates this :) whatever is decided im happy to update the readme ectra to reflect the new layout. regards sean.
Jim Rollenhagen wrote:
[...] 2) Move unofficial projects to "stackforge" or some other namespace, which is only a small amount of work to list the repositories, but probably a large amount of bikeshedding^Wdiscussion to come up with a name.
3) Do (2), but also namespace the OpenStack projects in a more fine-grained manner, by project team. For example: nova/nova, ironic/bifrost, etc. This is a larger chunk of work, but looks a bit nicer. Also makes it easier to move a project out of OpenStack later, as we don't have to move namespaces. This has an open question of whether we use one large namespace for unofficial projects, or give them each their own. It also has a downside of making more effort to move a repository between project teams, though I think that's fairly rare.
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. 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 Of those 3 options, (2) is a community-oriented view (openstack or not openstack), (3) is a developer-oriented view (organized by project teams, which really only matter to developers), and (4) is a user-oriented view (organized by what users are looking for). My preference would be (4), otherwise (2). -- Thierry Carrez (ttx)
On Mar 19, 2019, at 5:45 AM, Thierry Carrez <thierry@openstack.org> wrote:
Jim Rollenhagen wrote:
[...] 2) Move unofficial projects to "stackforge" or some other namespace, which is only a small amount of work to list the repositories, but probably a large amount of bikeshedding^Wdiscussion to come up with a name. 3) Do (2), but also namespace the OpenStack projects in a more fine-grained manner, by project team. For example: nova/nova, ironic/bifrost, etc. This is a larger chunk of work, but looks a bit nicer. Also makes it easier to move a project out of OpenStack later, as we don't have to move namespaces. This has an open question of whether we use one large namespace for unofficial projects, or give them each their own. It also has a downside of making more effort to move a repository between project teams, though I think that's fairly rare.
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.
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
Of those 3 options, (2) is a community-oriented view (openstack or not openstack), (3) is a developer-oriented view (organized by project teams, which really only matter to developers), and (4) is a user-oriented view (organized by what users are looking for).
My preference would be (4), otherwise (2).
-- Thierry Carrez (ttx)
You make excellent points. I agree. Doug
On 19/03/2019 12:13, Doug Hellmann wrote:
On Mar 19, 2019, at 5:45 AM, Thierry Carrez <thierry@openstack.org> wrote:
Jim Rollenhagen wrote:
[...] 2) Move unofficial projects to "stackforge" or some other namespace, which is only a small amount of work to list the repositories, but probably a large amount of bikeshedding^Wdiscussion to come up with a name. 3) Do (2), but also namespace the OpenStack projects in a more fine-grained manner, by project team. For example: nova/nova, ironic/bifrost, etc. This is a larger chunk of work, but looks a bit nicer. Also makes it easier to move a project out of OpenStack later, as we don't have to move namespaces. This has an open question of whether we use one large namespace for unofficial projects, or give them each their own. It also has a downside of making more effort to move a repository between project teams, though I think that's fairly rare.
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.
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
Of those 3 options, (2) is a community-oriented view (openstack or not openstack), (3) is a developer-oriented view (organized by project teams, which really only matter to developers), and (4) is a user-oriented view (organized by what users are looking for).
My preference would be (4), otherwise (2).
-- Thierry Carrez (ttx)
You make excellent points. I agree.
Doug
Yeap - this makes a lot of sense. - Graham
On 2019-03-19 10:45:42 +0100 (+0100), Thierry Carrez wrote: [...]
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 [...]
While this will work fine for replicating from Gerrit to the opendev.org Gitea, it does necessarily imply centralized control over and maintenance of credentials for replicating to outside services like GitHub or Bitbucket. Under the org-per-team model those org credential secrets can be safely carried in and managed by the individual teams' core reviewers. With cross-team orgs, you need an identified body to care for the repository containing the replication job secrets and curating the various categories. *If* there is a group of volunteers to take on that work, then it seems like a reasonable plan to me. One other thing to keep in mind regarding replication to services outside OpenDev is that the namespaces/organizations don't have to be a 1:1 match. The suggested solution of using Zuul jobs to replicate branches and tags can flexibly accommodate whatever per-service mappings you care to design. -- Jeremy Stanley
Jeremy Stanley wrote:
On 2019-03-19 10:45:42 +0100 (+0100), Thierry Carrez wrote: [...]
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 [...]
While this will work fine for replicating from Gerrit to the opendev.org Gitea, it does necessarily imply centralized control over and maintenance of credentials for replicating to outside services like GitHub or Bitbucket. Under the org-per-team model those org credential secrets can be safely carried in and managed by the individual teams' core reviewers. With cross-team orgs, you need an identified body to care for the repository containing the replication job secrets and curating the various categories. *If* there is a group of volunteers to take on that work, then it seems like a reasonable plan to me.
Actually, I'd argue that we *need to* follow a common policy to define how "OpenStack" appears on GitHub/Bitbucket. I think having per-project-team replication policies could result in a very weird landscape. So I see having a single identified body to care for all those organizations as a feature rather than a bug :) I'm happy to volunteer to do that, as a TC member or as a OSF staff member, depending how much the rest of the TC wants to have a say in social code marketing properties like GitHub. -- Thierry Carrez (ttx)
While this will work fine for replicating from Gerrit to the opendev.org Gitea, it does necessarily imply centralized control over and maintenance of credentials for replicating to outside services like GitHub or Bitbucket. Under the org-per-team model those org credential secrets can be safely carried in and managed by the individual teams' core reviewers. With cross-team orgs, you need an identified body to care for the repository containing the replication job secrets and curating the various categories. *If* there is a group of volunteers to take on that work, then it seems like a reasonable plan to me.
Actually, I'd argue that we *need to* follow a common policy to define how "OpenStack" appears on GitHub/Bitbucket. I think having per-project-team replication policies could result in a very weird landscape.
+1
So I see having a single identified body to care for all those organizations as a feature rather than a bug :) I'm happy to volunteer to do that, as a TC member or as a OSF staff member, depending how much the rest of the TC wants to have a say in social code marketing properties like GitHub.
-- Thierry Carrez (ttx)
On Tue, Mar 19, 2019 at 5:50 AM Thierry Carrez <thierry@openstack.org> wrote:
[...] 2) Move unofficial projects to "stackforge" or some other namespace, which is only a small amount of work to list the repositories, but probably a large amount of bikeshedding^Wdiscussion to come up with a name.
3) Do (2), but also namespace the OpenStack projects in a more fine-grained manner, by project team. For example: nova/nova, ironic/bifrost, etc. This is a larger chunk of work, but looks a bit nicer. Also makes it easier to move a project out of OpenStack later, as we don't have to move namespaces. This has an open question of whether we use one large namespace for unofficial projects, or give them each their own. It also has a downside of making more effort to move a repository between project teams,
Jim Rollenhagen wrote: though
I think that's fairly rare.
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.
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
Of those 3 options, (2) is a community-oriented view (openstack or not openstack), (3) is a developer-oriented view (organized by project teams, which really only matter to developers), and (4) is a user-oriented view (organized by what users are looking for).
This makes sense in general, but we're talking about git repositories and only git repositories. Who looks for git repositories most often, users or developers? :) (Sorry for the spam, ttx, reply button got me again) // jim
My preference would be (4), otherwise (2).
-- Thierry Carrez (ttx)
Jim Rollenhagen wrote:
[...] Of those 3 options, (2) is a community-oriented view (openstack or not openstack), (3) is a developer-oriented view (organized by project teams, which really only matter to developers), and (4) is a user-oriented view (organized by what users are looking for).
This makes sense in general, but we're talking about git repositories and only git repositories.
Who looks for git repositories most often, users or developers? :)
Developers, of course. But developers can easily find their way to the repository that they want to see. While users or first-time developers might get confused by a hierarchy defined after how work is organized rather than the result of that work. But I get your point... we should definitely not make the hierarchy "weird" for developers and contributors. If (4) really is too alien, maybe (2) is the right trade-off. -- Thierry Carrez (ttx)
On 2019-03-19 14:52:41 +0100 (+0100), Thierry Carrez wrote:
Jim Rollenhagen wrote:
[...] Of those 3 options, (2) is a community-oriented view (openstack or not openstack), (3) is a developer-oriented view (organized by project teams, which really only matter to developers), and (4) is a user-oriented view (organized by what users are looking for).
This makes sense in general, but we're talking about git repositories and only git repositories.
Who looks for git repositories most often, users or developers? :)
Developers, of course. But developers can easily find their way to the repository that they want to see. While users or first-time developers might get confused by a hierarchy defined after how work is organized rather than the result of that work.
But I get your point... we should definitely not make the hierarchy "weird" for developers and contributors. If (4) really is too alien, maybe (2) is the right trade-off.
To reiterate, the namespaces and repository names in Gerrit/Gitea do not have to 1:1 match their counterparts on external services. We can totally have team-oriented namespaces in OpenDev but functional namespacing in places like GH and BB. But perhaps that too would be confusing? -- Jeremy Stanley
On 2019-03-19 14:52:41 +0100 (+0100), Thierry Carrez wrote:
Jim Rollenhagen wrote:
[...] Of those 3 options, (2) is a community-oriented view (openstack or not openstack), (3) is a developer-oriented view (organized by project teams, which really only matter to developers), and (4) is a user-oriented view (organized by what users are looking for).
This makes sense in general, but we're talking about git repositories and only git repositories.
Who looks for git repositories most often, users or developers? :)
Developers, of course. But developers can easily find their way to the repository that they want to see. While users or first-time developers might get confused by a hierarchy defined after how work is organized rather than the result of that work.
But I get your point... we should definitely not make the hierarchy "weird" for developers and contributors. If (4) really is too alien, maybe (2) is the right trade-off.
To reiterate, the namespaces and repository names in Gerrit/Gitea do not have to 1:1 match their counterparts on external services. We can totally have team-oriented namespaces in OpenDev but functional namespacing in places like GH and BB. But perhaps that too would be confusing? am i would be somewhat concerned that if we wanted to evolve the functionl groupins over time. e.g. move a service into our out of core or operations vs lifecyclemenate
On Tue, 2019-03-19 at 13:59 +0000, Jeremy Stanley wrote: that i might require renaming/moving repos as we evovle our "marchitecture" to reflect the evolving opnestack vision captured in https://openstack.org/openstack-map. as such my personal preferences as a dev would be to follow the governce repo team structures whic was option 3 and only include offial project in for example the nova/* namespace although we could consivibly use the team name e.g. compute/nova instead to give a blance between user and dev expections. e.g. org use user faceing team name "compute" and the porject use the devfocused project name "nova" i do understand the desire to have a mappiing back to https://openstack.org/openstack-map but im not sure the source repose are the correct way to do that.
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
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. Sean
On 19/03/2019 10.45, Thierry Carrez wrote:
[...] 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
What about some doc repos like openstack-manuals and security-guide? Those are not mentioned in the map, Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Andreas Jaeger wrote:
On 19/03/2019 10.45, Thierry Carrez wrote:
[...] 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
What about some doc repos like openstack-manuals and security-guide? Those are not mentioned in the map,
That's a good point, we would likely need something like openstack-docs/ for those. -- Thierry Carrez (ttx)
On 3/19/19 4:45 AM, Thierry Carrez wrote:
Jim Rollenhagen wrote:
[...] 2) Move unofficial projects to "stackforge" or some other namespace, which is only a small amount of work to list the repositories, but probably a large amount of bikeshedding^Wdiscussion to come up with a name.
3) Do (2), but also namespace the OpenStack projects in a more fine-grained manner, by project team. For example: nova/nova, ironic/bifrost, etc. This is a larger chunk of work, but looks a bit nicer. Also makes it easier to move a project out of OpenStack later, as we don't have to move namespaces. This has an open question of whether we use one large namespace for unofficial projects, or give them each their own. It also has a downside of making more effort to move a repository between project teams, though I think that's fairly rare.
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.
So between (2) and (3) I'd really prefer if we did (2).
Somewhat selfish +1 to this because it avoids me having to negotiate whose namespace is going to own the various co-owned Oslo libs. :-)
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
Of those 3 options, (2) is a community-oriented view (openstack or not openstack), (3) is a developer-oriented view (organized by project teams, which really only matter to developers), and (4) is a user-oriented view (organized by what users are looking for).
My preference would be (4), otherwise (2).
4 sounds mildly more painful as a developer (I can no longer unthinkingly clone openstack/PROJECT_NAME), but if it helps discoverability for users I'll survive. This mostly sidesteps the namespacing issue I mentioned above, although I think we'd still have a few conflicts like cliff, which is currently co-owned by the CLI and Oslo teams. That one pretty clearly belongs in the openstack-user namespace though, so I don't foresee much difficulty.
On 19/03/19 5:45 AM, Thierry Carrez wrote:
Jim Rollenhagen wrote:
[...] 2) Move unofficial projects to "stackforge" or some other namespace, which is only a small amount of work to list the repositories, but probably a large amount of bikeshedding^Wdiscussion to come up with a name.
3) Do (2), but also namespace the OpenStack projects in a more fine-grained manner, by project team. For example: nova/nova, ironic/bifrost, etc. This is a larger chunk of work, but looks a bit nicer. Also makes it easier to move a project out of OpenStack later, as we don't have to move namespaces. This has an open question of whether we use one large namespace for unofficial projects, or give them each their own. It also has a downside of making more effort to move a repository between project teams, though I think that's fairly rare.
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.
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
The line between these two is extremely blurry. (e.g. Monasca includes some of the same functionality as Aodh, but they're in different boxes.) I don't think it would be helpful to have them in separate namespaces.
- openstack-lifecyclemanagement/ to hold deployment recipes
I don't envy anyone having to type this.
- openstack-user/ for SDK and CLI
+1 for splitting this out, even if we don't split out the others, because in addition to sharing an audience with the others, client-side stuff also has another completely separate audience.
- openstack-adjacentenablers/ for adjacent tech bridges
I *really* don't envy anyone having to type this. Might something like openstack-bridges be better?
Plus: - openstack-libs/ to hold libraries and second-order dependencies
+1, it would be nice to get that stuff out of the openstack namespace, if only in recognition that some of it has other legitimate uses as well.
- 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
This exists already, of course. Is there anything that you think should be in it but is not?
[1] https://openstack.org/openstack-map
Of those 3 options, (2) is a community-oriented view (openstack or not openstack), (3) is a developer-oriented view (organized by project teams, which really only matter to developers), and (4) is a user-oriented view (organized by what users are looking for).
My preference would be (4), otherwise (2).
Zane Bitter wrote:
On 19/03/19 5:45 AM, Thierry Carrez wrote:
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
The line between these two is extremely blurry. (e.g. Monasca includes some of the same functionality as Aodh, but they're in different boxes.) I don't think it would be helpful to have them in separate namespaces.
I agree that the distinction on the map is more product-marketing than technical, so it might be better not to have that bleed over repository names.
[...]
- 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
This exists already, of course. Is there anything that you think should be in it but is not?
A lot of stuff! We create a lot of repositories in the process of producing "OpenStack software". - Governance repositories like openstack/governance or election - Team repositories like openstack/auto-scaling-sig or transparency-policy - Meta repositories like openstack/releases or requirements - Tools repositories like openstack/goal-tools or uc-recognition In addition to that, several openstack-infra repositories are very OpenStack-specific and would likely not migrate to an opendev/ namespace: - QA-oriented infra repos like openstack-infra/devstack-gate - OpenStack-specific repos like openstack-infra/openstack-zuul-jobs Finally, specs repositories could also be considered a development process by-product thing. -- Thierry Carrez (ttx)
On Mon, Mar 25, 2019 at 6:51 AM Thierry Carrez <thierry@openstack.org> wrote:
Zane Bitter wrote:
On 19/03/19 5:45 AM, Thierry Carrez wrote:
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
The line between these two is extremely blurry. (e.g. Monasca includes some of the same functionality as Aodh, but they're in different boxes.) I don't think it would be helpful to have them in separate namespaces.
I agree that the distinction on the map is more product-marketing than technical, so it might be better not to have that bleed over repository names.
[...]
- 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
This exists already, of course. Is there anything that you think should be in it but is not?
A lot of stuff! We create a lot of repositories in the process of producing "OpenStack software".
- Governance repositories like openstack/governance or election - Team repositories like openstack/auto-scaling-sig or transparency-policy - Meta repositories like openstack/releases or requirements - Tools repositories like openstack/goal-tools or uc-recognition
In addition to that, several openstack-infra repositories are very OpenStack-specific and would likely not migrate to an opendev/ namespace:
- QA-oriented infra repos like openstack-infra/devstack-gate - OpenStack-specific repos like openstack-infra/openstack-zuul-jobs
Finally, specs repositories could also be considered a development process by-product thing.
I'm quite in favor of enabling projects with large number of deliverables to get their own space. As I've worked with Puppet OpenStack and OpenStack Ansible, splitting our work into many different roles really makes it hard and duplicates a lot of information i.e. all our repos are openstack/openstack-ansible-os_nova like, it would be nice for them to be: openstack-ansible/ansible-role-os_nova .. we would then we able to follow the 'offiical' Ansible naming convention for role repo name for example.
-- Thierry Carrez (ttx)
-- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser@vexxhost.com W. http://vexxhost.com
On 03/28/2019 08:41 PM, Mohammed Naser wrote:
On Mon, Mar 25, 2019 at 6:51 AM Thierry Carrez <thierry@openstack.org> wrote:
Zane Bitter wrote:
On 19/03/19 5:45 AM, Thierry Carrez wrote:
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
The line between these two is extremely blurry. (e.g. Monasca includes some of the same functionality as Aodh, but they're in different boxes.) I don't think it would be helpful to have them in separate namespaces.
I agree that the distinction on the map is more product-marketing than technical, so it might be better not to have that bleed over repository names.
[...]
- 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
This exists already, of course. Is there anything that you think should be in it but is not?
A lot of stuff! We create a lot of repositories in the process of producing "OpenStack software".
- Governance repositories like openstack/governance or election - Team repositories like openstack/auto-scaling-sig or transparency-policy - Meta repositories like openstack/releases or requirements - Tools repositories like openstack/goal-tools or uc-recognition
In addition to that, several openstack-infra repositories are very OpenStack-specific and would likely not migrate to an opendev/ namespace:
- QA-oriented infra repos like openstack-infra/devstack-gate - OpenStack-specific repos like openstack-infra/openstack-zuul-jobs
Finally, specs repositories could also be considered a development process by-product thing.
I'm quite in favor of enabling projects with large number of deliverables to get their own space.
As I've worked with Puppet OpenStack and OpenStack Ansible, splitting our work into many different roles really makes it hard and duplicates a lot of information
i.e. all our repos are openstack/openstack-ansible-os_nova like, it would be nice for them to be: openstack-ansible/ansible-role-os_nova .. we would then we able to follow the 'offiical' Ansible naming convention for role repo name for example.
What about putting all deployment things into an openstack-deployment/ organization? You could still have the name of the repo be "ansible-role-os_nova" (or ansible-role-compute?), and we'd be able to put all the deployment stuff in a single location. Best, -jay
On Mon, Mar 18, 2019 at 4:49 PM Jim Rollenhagen <jim@jimrollenhagen.com> wrote:
Hi all,
With OpenDev needing to change git URLs for all projects, we have an opportunity to change how we namespace projects that are currently under the "openstack" namespace.[0]
I've heard a few options thrown out:
1) Keep everything the same. This is the easiest option for everybody, but keeps our current confusion of what is officially OpenStack, and what is not.
2) Move unofficial projects to "stackforge" or some other namespace, which is only a small amount of work to list the repositories, but probably a large amount of bikeshedding^Wdiscussion to come up with a name.
3) Do (2), but also namespace the OpenStack projects in a more fine-grained manner, by project team. For example: nova/nova, ironic/bifrost, etc. This is a larger chunk of work, but looks a bit nicer. Also makes it easier to move a project out of OpenStack later, as we don't have to move namespaces. This has an open question of whether we use one large namespace for unofficial projects, or give them each their own. It also has a downside of making more effort to move a repository between project teams, though I think that's fairly rare.
4) ??
I personally like (2) or (3), but would like to hear from the rest of the community. I'll propose a governance resolution after the discussion here, and we can follow from there with whatever else needs to be done.
Great discussion here. Thanks all! It seems like folks support #2 and Thierry's #4 the most. I think #2 is the best effort:value option, and have proposed a resolution to that effect: https://review.openstack.org/645601 OpenDev is planning for an April 19 migration, so we should get this done relatively quickly. // jim
participants (17)
-
Adam Harwell
-
Andreas Jaeger
-
Arkady.Kanevsky＠dell.com
-
Ben Nemec
-
Doug Hellmann
-
Graham Hayes
-
Jay Pipes
-
Jeremy Stanley
-
Jim Rollenhagen
-
Lingxian Kong
-
Matthew Thode
-
Mohammed Naser
-
Nate Johnston
-
Sean McGinnis
-
Sean Mooney
-
Thierry Carrez
-
Zane Bitter