-
Notifications
You must be signed in to change notification settings - Fork 368
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
Comments
Thanks for the proposal. The vanity URL looks good to me.
Is this a typo? Won't the import path become |
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. |
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 works for me. |
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
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
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
@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 |
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
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
…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
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
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
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 beantrea-io
.The following tasks need to be performed:
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.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 ofgithub.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 anantrea.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:
github.com/vmware-tanzu/antrea
import antrea.io/pkg/agent
antrea-io
organizationgithub.com/antrea-io/antrea
. No further change is required to the code at this point.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.
The text was updated successfully, but these errors were encountered: