Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move antrea Github repo from the vmware-tanzu to the antrea-io organization #2154

Closed
3 tasks done
antoninbas opened this issue May 6, 2021 · 6 comments
Closed
3 tasks done
Assignees
Labels
cncf/sandbox Issues related to the CNCF Sandbox onboarding kind/task Categorizes issue or PR as related to a routine task that needs to be performed

Comments

@antoninbas
Copy link
Contributor

antoninbas commented May 6, 2021

As part of project onboarding to the CNCF Sandbox (cncf/sandbox#243), we need to move the project to "its own separate neutral github organization". The new organization name was decided by a poll in the #antrea channel in the K8s Slack workspace: it will be antrea-io.

The following tasks need to be performed:

  • transfer the repo to the new organization. The transfer is scheduled Wednesday May 12th at noon PST.
  • rename the Go module from github.com/vmware-tanzu/antrea; this is a disruptive change as it is likely that it will create conflicts with existing Pull Requests. I would like the PR to be ready before we do the transfer, so it can be merged shortly after.
  • update all links and references to vmware-tanzu in the Antrea documentation / website / code comments / ...

Note that Github takes care of configuring HTTP forwarding from the old location to the new one. So I expect that if someone is importing Antrea for some reason in their Go project, they should be able to keep importing it using the old URL.

Edit: Go will complain if the module name doesn't match the require directive in the go.mod. So consumers of the Antrea Go module may need to use a replace directive or update to the new path. If they pin a specific version of Antrea (pre repository change), they should not be impacted.

As we need to change our import paths, I wanted to check how people felt about switching to a vanity URL for our import path, like Kubernetes and other projects are doing: our import path would become antrea.io instead of github.com/antrea-io/antrea. It would be much shorter and will also ensure that repository transfers are much easier in the future, as we would no longer need to update imports (another Github organization transfer in the future is very unlikely). It is also easy to set up in the antrea.io website (hosted by Netlify).

More information on vanity import paths:

The major drawback in my opinion is that users and IT organizations are more likely to trust a github.com URL than an antrea.io URL. It also means that availability of the antrea.io website and validity of our SSL certificate become more important. Even though it is is unlikely that many people need to import Antrea directly.

If we choose to use a vanity URL, the steps would be the following:

  1. Set up the vanity import path by configuring the antrea.io website correctly; at first it will point to github.com/vmware-tanzu/antrea
  2. Update the Antrea code base to use the new import path, e.g. import antrea.io/pkg/agent
  3. Transfer the Github repository to the new antrea-io organization
  4. Right after the previous step, update the vanity import path to point to github.com/antrea-io/antrea. No further change is required to the code at this point.
  5. Take care of updating remaining links in the documentation, etc.

At this stage, I am leaning against using a vanity URL, but I wanted to check how others felt about it.
Edit: after discussion at the Community Meeting, we decided that the pros of using a vanity URL outweighed the cons, and there was consensus for this approach.

@antoninbas
Copy link
Contributor Author

cc @jianjuns @tnqn

@antoninbas antoninbas added the kind/task Categorizes issue or PR as related to a routine task that needs to be performed label May 6, 2021
@antoninbas antoninbas self-assigned this May 6, 2021
@tnqn
Copy link
Member

tnqn commented May 10, 2021

Thanks for the proposal. The vanity URL looks good to me.

our import path would become antrea.io instead of github.com/antrea-io/antrea.

Is this a typo? Won't the import path become antrea.io/antrea instead of antrea.io?

@antoninbas
Copy link
Contributor Author

Is this a typo? Won't the import path become antrea.io/antrea instead of antrea.io?

I may be wrong but I think we can choose either one. It depends on whether we want to have other Go modules under antrea.io.

@tnqn
Copy link
Member

tnqn commented May 11, 2021

I see normally the projects that use vanity URL still have a repo name in the path, e.g. Kubernetes and Istio. I think it would be more extensible to use antrea.io/antrea in case we want to put some common libraries, tools under antrea.io in the future?

@jianjuns
Copy link
Contributor

antrea.io/antrea works for me.

antoninbas added a commit that referenced this issue May 11, 2021
The import path for the Antrea Go module will now be "antrea.io/antrea".
We leverage Netlify's redirect support (this is inspired by the Knative
project) to serve the necessary HTML content. It will be super easy to
add new Go modules in the future.

For now "antrea.io/antrea" points to "github.com/vmware-tanzu/antrea".
After we transfer Antrea to the new Github organization (antrea-io), we
will update the HTML file appropriately.

See #2154
antoninbas added a commit that referenced this issue May 11, 2021
The import path for the Antrea Go module will now be "antrea.io/antrea".
We leverage Netlify's redirect support (this is inspired by the Knative
project) to serve the necessary HTML content. It will be super easy to
add new Go modules in the future.

For now "antrea.io/antrea" points to "github.com/vmware-tanzu/antrea".
After we transfer Antrea to the new Github organization (antrea-io), we
will update the HTML file appropriately.

See #2154
antoninbas added a commit that referenced this issue May 11, 2021
The import path for the Antrea Go module will now be "antrea.io/antrea".
We leverage Netlify's redirect support (this is inspired by the Knative
project) to serve the necessary HTML content. It will be super easy to
add new Go modules in the future.

For now "antrea.io/antrea" points to "github.com/vmware-tanzu/antrea".
After we transfer Antrea to the new Github organization (antrea-io), we
will update the HTML file appropriately.

See #2154
@antoninbas
Copy link
Contributor Author

Note that Github takes care of configuring HTTP forwarding from the old location to the new one. So I expect that if someone is importing Antrea for some reason in their Go project, they should be able to keep importing it using the old URL.

@tnqn ran an experiment and realized this was not accurate. Go will complain if the module name doesn't match the require directive in the go.mod

antoninbas added a commit to antoninbas/antrea that referenced this issue May 12, 2021
This is a pretty straightforward change with one exception: we cannot
use the default Protobuf package names for Antrea APIs because of name
resolution in protoc and because of how go-to-protobuf references
messages defined in other .proto files. go-to-protobuf will not add a
leading dot to the message path, and in that case protoc does resolution
starting from the inbermost scope. Default package names start with
"antrea.io.antrea." which means that for any message reference that
matches "antrea.io.antrea.<path>", protoc will look for
"antrea.io.antrea.io.antrea.<path>" which obviously will fail. To avoid
a "sed" hack to add a leading dot (which would require us to run protoc
directly), we rename the package names to "antrea_io.antrea.*". Even
though this causes some extra code to be re-generated, there shouldn't
be any impact at all on backwards-compatibility: the Protobuf messages
themselves do not change.

Consumers of the Antrea Go module should update the import path they use
for Antrea. If these consumers are "pinning" a version of Antrea which
is on a release branch that was created before the repository transfer
(for now, all release branches...), their code should keep working.

See antrea-io#2154
antoninbas added a commit to antoninbas/antrea that referenced this issue May 12, 2021
This is a pretty straightforward change with one exception: we cannot
use the default Protobuf package names for Antrea APIs because of name
resolution in protoc and because of how go-to-protobuf references
messages defined in other .proto files. go-to-protobuf will not add a
leading dot to the message path, and in that case protoc does resolution
starting from the inbermost scope. Default package names start with
"antrea.io.antrea." which means that for any message reference that
matches "antrea.io.antrea.<path>", protoc will look for
"antrea.io.antrea.io.antrea.<path>" which obviously will fail. To avoid
a "sed" hack to add a leading dot (which would require us to run protoc
directly), we rename the package names to "antrea_io.antrea.*". Even
though this causes some extra code to be re-generated, there shouldn't
be any impact at all on backwards-compatibility: the Protobuf messages
themselves do not change.

Consumers of the Antrea Go module should update the import path they use
for Antrea. If these consumers are "pinning" a version of Antrea which
is on a release branch that was created before the repository transfer
(for now, all release branches...), their code should keep working.

See antrea-io#2154
antoninbas added a commit that referenced this issue May 12, 2021
…rea (#2166)

This is a pretty straightforward change with one exception: we cannot
use the default Protobuf package names for Antrea APIs because of name
resolution in protoc and because of how go-to-protobuf references
messages defined in other .proto files. go-to-protobuf will not add a
leading dot to the message path, and in that case protoc does resolution
starting from the inbermost scope. Default package names start with
"antrea.io.antrea." which means that for any message reference that
matches "antrea.io.antrea.<path>", protoc will look for
"antrea.io.antrea.io.antrea.<path>" which obviously will fail. To avoid
a "sed" hack to add a leading dot (which would require us to run protoc
directly), we rename the package names to "antrea_io.antrea.*". Even
though this causes some extra code to be re-generated, there shouldn't
be any impact at all on backwards-compatibility: the Protobuf messages
themselves do not change.

Consumers of the Antrea Go module should update the import path they use
for Antrea. If these consumers are "pinning" a version of Antrea which
is on a release branch that was created before the repository transfer
(for now, all release branches...), their code should keep working.

See #2154
@antoninbas antoninbas added the cncf/sandbox Issues related to the CNCF Sandbox onboarding label May 12, 2021
antoninbas added a commit to antoninbas/antrea that referenced this issue May 12, 2021
With antrea-io/antrea
Most of these are Github links.
We also update the Jenkins job configuration as jobs cannot run at the
moment because of the repository transfer.

See antrea-io#2154
antoninbas added a commit that referenced this issue May 13, 2021
With antrea-io/antrea
Most of these are Github links.
We also update the Jenkins job configuration as jobs cannot run at the
moment because of the repository transfer.

See #2154
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cncf/sandbox Issues related to the CNCF Sandbox onboarding kind/task Categorizes issue or PR as related to a routine task that needs to be performed
Projects
None yet
Development

No branches or pull requests

3 participants