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
Currently, Calico is used as the CNI provider. Although that's a sane default, the option should really be left to the end user. CLI option like...
--cni-provider=calico
--cni-provider=weavenet
--cni-provider=flannel
First pass through, the version is the "latest stable". Future, make that part of the --cni-provider option? (something like --cni-provider=calico3.20)
The text was updated successfully, but these errors were encountered:
Been giving this some thought as well, and I see a couple of options:
Either pass in CNI by name
Pass in CNI by linking to a URL
We could even do both.
--cni-provider= xxx for well-known CNI providers.
--cni-provider-url= xxx for unknown CNI providers.
Given that cluster-api itself doesn't install a CNI provider, I personally think the second approach is a fair option if users need a different CNI provider.
Also, for calico, Azure needs a specific URL. It's coded that way right now in the create azure cluster code. Weave doesn't need this. Not sure how this would work for other CNI providers.
Currently, Calico is used as the CNI provider. Although that's a sane default, the option should really be left to the end user. CLI option like...
--cni-provider=calico
--cni-provider=weavenet
--cni-provider=flannel
First pass through, the version is the "latest stable". Future, make that part of the
--cni-provider
option? (something like--cni-provider=calico3.20
)The text was updated successfully, but these errors were encountered: