pkg/api should be made sub go module so it can be consumed by other project

[lubronzhan]

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

[wyike]

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

[wyike]

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.

[wyike]

cc @zhengxiexie @dantingl FYI an follow up request on supporting apis, clients in nsx-operator

[wyike]

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!

[lubronzhan]

Good suggestion. Let me close this then, could you create one for removing dependency of controller-runtime.

Could we do the same vpc_dev/pkg/client and vpc_dev/pkg/apis/nsx.vmware.com, thanks!

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

[wyike]

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)
update: no need after testing. The nsx.vmware.com also has dependency on controller-runtime...

It's ok not to submodule client I think.

curious if not to submodule client, how can other project use it, except to import the whole nsx-operator.

[zhengxiexie]

#374
fixed here.