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

Update module from antrea.io/antrea to antrea.io/antrea/v2 #6774

Open
jainpulkit22 opened this issue Oct 28, 2024 · 3 comments
Open

Update module from antrea.io/antrea to antrea.io/antrea/v2 #6774

jainpulkit22 opened this issue Oct 28, 2024 · 3 comments
Labels
kind/bug Categorizes issue or PR as related to a bug. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release.

Comments

@jainpulkit22
Copy link
Contributor

Describe the bug
The antrea module in go.mod should be updated from antrea.io/antrea/v2 since now we are on v2.x

Additional context
If we try to require this in some other repository then it will generate error because go.mod will not parse until the module is antrea.io/antrea/v2.

@jainpulkit22 jainpulkit22 added the kind/bug Categorizes issue or PR as related to a bug. label Oct 28, 2024
@jainpulkit22
Copy link
Contributor Author

cc: @antoninbas @tnqn

@antoninbas
Copy link
Contributor

That's a real issue, but I think there is a deeper issue that should be addressed at the same time: antrea.io/antrea is not really meant to be imported as a module (like k8s.io/kubernetes is not meant to be imported for example). Only a small part of antrea.io/antrea is meant to be imported: APIs and generated clientsets. By forcing consumer projects of the Antrea APIs to import all of antrea.io/antrea, we can create issues in dependency management for these other projects.

In my view, there are 2 solutions that are worth considering:

  1. move Antrea APIs and generated clients to a separate repository / module (e.g., antrea-io/apis), for which we would not have any semantic versioning. Calico has taken that approach.
  2. leverage workspace support introduced in Go 1.18. K8s currently uses a Go workspace: https://github.com/kubernetes/kubernetes/blob/master/go.work

A few characteristics of each approach:

Approach 1:

  • when making an update to an API, antrea-io/apis needs to be updated first, separately from antrea-io/antrea. For minor changes / fixes or for chores (code generation version updates), this may be a bit of a nuisance. For major changes such as the introduction of a new API, we anyway recommend opening separate PRs even today (one for the API change, one for the implementation)
  • we don't actually need to update the package name (and all imports) from antrea-io/antrea to antrea-io/antrea/v2

Approach 2:

  • everything stays in the same repo, so we keep the contribution model the same
  • we still need to update the package name (and all imports) from antrea-io/antrea to antrea-io/antrea/v2
  • APIs need to be imported as antrea-io/antrea/v2/apis, assuming we use apis as the module for APIs inside the workspace

In both cases, some code reorganization is necessary. I don't have a strong preference at the moment. Approach 1 is pretty straightforward, while I am not as familiar with Approach 2 and what it entails. Probably something worth discussing at the next community meeting.

@antoninbas antoninbas added this to the Antrea v2.3 release milestone Oct 28, 2024
@antoninbas antoninbas added the priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. label Oct 28, 2024
@jainpulkit22
Copy link
Contributor Author

@antoninbas Approach 1 seems good because only apis are used by consumers, but in general approach2 seems to be more uniform and maintainable in long run, because we need not maintain separate versions and this makes the code(test code as well) more maintainable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release.
Projects
None yet
Development

No branches or pull requests

2 participants