-
Notifications
You must be signed in to change notification settings - Fork 20
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
pkg/api should be made sub go module so it can be consumed by other project #372
Comments
Same requests on https://github.com/vmware-tanzu/nsx-operator/tree/vpc_dev/pkg/client. Both pkg/api and pkg/client should be able to be imported independently with nsx-operator by other projects |
In the api, we'd better removing the controller-runtime dependency like kubernetes-sigs/cluster-api#9045, otherwise it will be introduced to other project and very easy to cause conflict. |
cc @zhengxiexie @dantingl FYI an follow up request on supporting apis, clients in nsx-operator |
I noticed nsx-operator/pkg/apis is already a go submodule on vpc_dev branch. Regarding https://github.com/vmware-tanzu/nsx-operator/tree/vpc_dev/pkg/apis, highly suggest to remove controller-runtime dependency in future like kubernetes-sigs/cluster-api#9045. Could we do the same https://github.com/vmware-tanzu/nsx-operator/tree/vpc_dev/pkg/client and https://github.com/vmware-tanzu/nsx-operator/tree/vpc_dev/pkg/apis/nsx.vmware.com, thanks! |
Good suggestion. Let me close this then, could you create one for removing dependency of controller-runtime.
It's ok not to submodule client I think. Even though it might introduce different controller-runtime version, maybe better bump the controller runtime in vpc_dev. Do you need to add go.mod for nsx.vmware.com separately? It's already under pkg/apis |
I thought if pkg/apis controller-runtime dependency cannot be removed in a short time, we can just import pkg/apis/nsx.vmware.com. (I am also do some test to see if this is required)
curious if not to submodule client, how can other project use it, except to import the whole nsx-operator. |
Both pkg/api and pkg/client should be able to be imported independently with nsx-operator by other projects. Refer vmware-tanzu#372
#374 |
Both pkg/api and pkg/client should be able to be imported independently with nsx-operator by other projects. Refer vmware-tanzu#372
Right now if other project wants to consume pkg/api it needs to pull the whole project through go module, it's unnecessary and might cause conflict. We ran into this issue when importing the api into cloud-provider-vsphere cc @wyike
Example PR vmware-tanzu/tanzu-framework#2216 done by @akutz to make some package as sub go module in tanzu-framework
The text was updated successfully, but these errors were encountered: