antrea-io / antrea

Kubernetes networking based on Open vSwitch
https://antrea.io
Apache License 2.0
1.67k stars 367 forks source link

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

Open jainpulkit22 opened 1 week ago

jainpulkit22 commented 1 week ago

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 commented 1 week ago

cc: @antoninbas @tnqn

antoninbas commented 1 week ago

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:

Approach 2:

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.

jainpulkit22 commented 1 week ago

@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.