[all][tc] Repository renames during OpenDev migration
Hi all, During the migration to OpenDev, we plan to change the way we organize some of our repositories. Before you ask, yes, there will be redirects. The TC has made some decisions about this[0]; this email is a re-iteration of the plan and a call for any last minute feedback. Here's how a repository's new namespace will be decided, as it stands today: - is the repo listed in projects.yaml[2]? If so, "openstack". - is the repo listed in legacy.yaml[3]? If so, "openstack". - is the repo listed in foundation-board-repos.yaml[4]? If so, "openstack". - is the repo listed in sigs-repos.yaml[5]? If so, "openstack". - is the repo listed in technical-committee-repos.yaml[6]? If so, "openstack". - is the repo listed in user-committee-repos.yaml[7]? If so, "openstack". - has the repo owner requested a new name(space) in the transition ethercalc sheet[1]? If so, use that. - anything else? A few of us from the TC will manually review the list to make sure we didn't miss anything that is an official OpenStack repo. Anything left will be moved to another namespace[8] unless/until the owner requests it to be moved elsewhere. [0] https://governance.openstack.org/tc/resolutions/20190322-namespace-unofficia... [1] https://ethercalc.openstack.org/opendev-transition [2] https://opendev.org/openstack/governance/src/branch/master/reference/project... [3] https://opendev.org/openstack/governance/src/branch/master/reference/legacy.... [4] https://opendev.org/openstack/governance/src/branch/master/reference/foundat... [5] https://opendev.org/openstack/governance/src/branch/master/reference/sigs-re... [6] https://opendev.org/openstack/governance/src/branch/master/reference/technic... [7] https://opendev.org/openstack/governance/src/branch/master/reference/user-co... [8] I'm not even going to name it here, lest this thread devolves into a discussion about this name and nothing else. // jim
On 2019-04-10 16:34:09 -0400 (-0400), Jim Rollenhagen wrote: [...]
Before you ask, yes, there will be redirects. [...]
The redirects for git.openstack.org to opendev.org have in fact already been available for testing for a few weeks (and this week we added rules which should properly cover git.airshipit.org, git.starlingx.io and git.zuul-ci.org too). If you're interested in helping us prove them further, you can add a line like this to your /etc/hosts file: 2001:4800:7817:103:be76:4eff:fe04:e3e3 git.airshipit.org git.openstack.org git.starlingx.io git.zuul-ci.org ...or, if you don't have IPv6 access, like: 23.253.125.17 git.airshipit.org git.openstack.org git.starlingx.io git.zuul-ci.org The expectation is that any hyperlinks to old cgit URLs remain working, as should any git operations relying on http:// or https:// URLs (we unfortunately need to drop git:// support for a couple of reasons). As for any namespace changes and renames which happen during the course of the transition, the Gitea service at opendev.org handles redirecting those transparently and we've already tested (and in one instance fixed a corner case for) that functionality. -- Jeremy Stanley
On Wed, 2019-04-10 at 20:44 +0000, Jeremy Stanley wrote:
On 2019-04-10 16:34:09 -0400 (-0400), Jim Rollenhagen wrote: [...]
Before you ask, yes, there will be redirects.
[...]
The redirects for git.openstack.org to opendev.org have in fact already been available for testing for a few weeks (and this week we added rules which should properly cover git.airshipit.org, git.starlingx.io and git.zuul-ci.org too). If you're interested in helping us prove them further, you can add a line like this to your /etc/hosts file:
2001:4800:7817:103:be76:4eff:fe04:e3e3 git.airshipit.org git.openstack.org git.starlingx.io git.zuul-ci.org
...or, if you don't have IPv6 access, like:
23.253.125.17 git.airshipit.org git.openstack.org git.starlingx.io git.zuul-ci.org so after doing this if i clone directly i get
The expectation is that any hyperlinks to old cgit URLs remain working, as should any git operations relying on http:// or https:// URLs (we unfortunately need to drop git:// support for a couple of reasons). for what its worth while you can use netcat or socat to tunnel thorough a sock5 proxy with a little trickery, for peopel behind coperate proxies the http/https repos on github were always simpler to get working. i dont have that problem anymore but i am glad that we changed the devstack default to https as it make getting up and running for new people simpler.
sean@pop-os:~/testing$ git clone https://git.openstack.org/openstack/nova Cloning into 'nova'... warning: redirecting to https://opendev.org/openstack/nova/ remote: Enumerating objects: 535171, done. remote: Counting objects: 100% (535171/535171), done. remote: Compressing objects: 100% (98416/98416), done. remote: Total 535171 (delta 427543), reused 530320 (delta 423684) Receiving objects: 100% (535171/535171), 150.93 MiB | 4.37 MiB/s, done. Resolving deltas: 100% (427543/427543), done. and if i clone via a local squid proxy i get sean@pop-os:~/testing$ http_proxy=192.168.1.155:32345 git clone http://git.openstack.org/openstack/nova Cloning into 'nova'... remote: Counting objects: 535171, done. remote: Compressing objects: 100% (259964/259964), done. remote: Total 535171 (delta 425706), reused 365748 (delta 262136) Receiving objects: 100% (535171/535171), 150.74 MiB | 4.80 MiB/s, done. Resolving deltas: 100% (425706/425706), done. so via the proxy i dont even see the redirct warning but it seams to work fine for me over ipv4. https also works. that saidsetting GIT_BASE was not exactly hard either.
As for any namespace changes and renames which happen during the course of the transition, the Gitea service at opendev.org handles redirecting those transparently and we've already tested (and in one instance fixed a corner case for) that functionality.
On 2019-04-10 23:27:54 +0100 (+0100), Sean Mooney wrote: [...]
so after doing this if i clone directly i get
sean@pop-os:~/testing$ git clone https://git.openstack.org/openstack/nova Cloning into 'nova'... warning: redirecting to https://opendev.org/openstack/nova/ remote: Enumerating objects: 535171, done. [...]
Perfect, that's git following the redirect just like we intend.
and if i clone via a local squid proxy i get
sean@pop-os:~/testing$ http_proxy=192.168.1.155:32345 git clone http://git.openstack.org/openstack/nova Cloning into 'nova'... remote: Counting objects: 535171, done. [...] so via the proxy i dont even see the redirct warning [...]
This is probably normal. Does squid pay attention to your /etc/hosts entries, or is it just going directly to DNS lookups? Also possible that it cached earlier name lookups. Thanks for helping test it for us! -- Jeremy Stanley
On Thu, 2019-04-11 at 16:43 +0000, Jeremy Stanley wrote:
On 2019-04-10 23:27:54 +0100 (+0100), Sean Mooney wrote: [...]
so after doing this if i clone directly i get
sean@pop-os:~/testing$ git clone https://git.openstack.org/openstack/nova Cloning into 'nova'... warning: redirecting to https://opendev.org/openstack/nova/ remote: Enumerating objects: 535171, done.
[...]
Perfect, that's git following the redirect just like we intend.
and if i clone via a local squid proxy i get
sean@pop-os:~/testing$ http_proxy=192.168.1.155:32345 git clone http://git.openstack.org/openstack/nova Cloning into 'nova'... remote: Counting objects: 535171, done.
[...]
so via the proxy i dont even see the redirct warning
[...]
This is probably normal. Does squid pay attention to your /etc/hosts entries, or is it just going directly to DNS lookups? Also possible that it cached earlier name lookups. ah ya that makes sense.
my squid proxy is running in a docker container in k8s cluster deployed on a singel node openstack deployed in docker via kolla-ansible so it is definetly not reading my local /etc/hosts form my laptop im not sure where in that inception stack of things i would need to change it to force it to use that ip since docker does weird things with /etc/hosts so we proably can be ignored the squid data point.
Thanks for helping test it for us!
On 2019-04-10 16:34:09 -0400 (-0400), Jim Rollenhagen wrote: [...]
Anything left will be moved to another namespace[8] unless/until the owner requests it to be moved elsewhere. [...] [8] I'm not even going to name it here, lest this thread devolves into a discussion about this name and nothing else.
Also, in case it's not immediately clear, in combination with the details from the GitHub section of the earlier announcement at http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003603.htm... the upshot is that on April 19 any repositories in the "openstack" organization on GitHub which aren't part of the official set described in this current thread will cease updating and be archived soon thereafter. Their owners will need to coordinate with the volunteer team who takes over management of the "openstack" GitHub organization to have them un-archived and transferred to a different organization if they want GitHub redirects to work. (I have it on authority this is scriptable through their API and so can be batch processed in bulk, but needs the initiator of the transfer in the "openstack" organization to be temporarily added as an admin of the receiving organization as well.) -- Jeremy Stanley
On Wed, 2019-04-10 at 16:34 -0400, Jim Rollenhagen wrote: ...
Here's how a repository's new namespace will be decided, as it stands today:
- is the repo listed in projects.yaml[2]? If so, "openstack". - is the repo listed in legacy.yaml[3]? If so, "openstack". - is the repo listed in foundation-board-repos.yaml[4]? If so, "openstack". - is the repo listed in sigs-repos.yaml[5]? If so, "openstack". - is the repo listed in technical-committee-repos.yaml[6]? If so, "openstack". - is the repo listed in user-committee-repos.yaml[7]? If so, "openstack".
Is there a script already in place to generate the list of repos that will land in "openstack" under the previous rules? I think it would be helpful to have that list published somewhere, possibly in combination with the list of repos that don't match, so that interested people can easily check the status of a repo they are interested in. Jens
On Fri, Apr 12, 2019 at 4:30 AM Jens Harbott <frickler@offenerstapel.de> wrote:
On Wed, 2019-04-10 at 16:34 -0400, Jim Rollenhagen wrote: ...
Here's how a repository's new namespace will be decided, as it stands today:
- is the repo listed in projects.yaml[2]? If so, "openstack". - is the repo listed in legacy.yaml[3]? If so, "openstack". - is the repo listed in foundation-board-repos.yaml[4]? If so, "openstack". - is the repo listed in sigs-repos.yaml[5]? If so, "openstack". - is the repo listed in technical-committee-repos.yaml[6]? If so, "openstack". - is the repo listed in user-committee-repos.yaml[7]? If so, "openstack".
Is there a script already in place to generate the list of repos that will land in "openstack" under the previous rules? I think it would be helpful to have that list published somewhere, possibly in combination with the list of repos that don't match, so that interested people can easily check the status of a repo they are interested in.
That's something fungi is taking on. We'll definitely make sure it gets published. :) // jim
participants (5)
-
Jens Harbott
-
Jeremy Stanley
-
Jim Rollenhagen
-
Matt Riedemann
-
Sean Mooney