You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, I'm raising this because I found another use case of an operator that needs to consume the SRIOV operator's API.
As this project (and its go dependencies) are pretty big, dependant projects might experience a dependency hell when consuming github.com/k8snetworkplumbingwg/sriov-network-operator/api.
There are at least two options to solve this:
a. Follow a multi-module repository approach like sriov-network-operator/pull/331 tried to achieve.
b. Create a k8snetworkplumbingwg/sriov-network-operator-api project and move API object there.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hi, I'm raising this because I found another use case of an operator that needs to consume the SRIOV operator's API.
As this project (and its go dependencies) are pretty big, dependant projects might experience a dependency hell when consuming
github.com/k8snetworkplumbingwg/sriov-network-operator/api
.There are at least two options to solve this:
a. Follow a multi-module repository approach like sriov-network-operator/pull/331 tried to achieve.
b. Create a k8snetworkplumbingwg/sriov-network-operator-api project and move API object there.
Any thoughts on this?
cc @dprince
Beta Was this translation helpful? Give feedback.
All reactions