Make SMI apiVersion configurable for SMI based service mesh providers

[shashankram]

Currently Flagger is supporting v1alpha1 of SMI traffic split policy. Different SMI based mesh providers might use different versions of SMI, making it not feasible to use Flagger in its current form by pinning to one specific SMI version.

Looking at #376, it seems like Flagger can support v1alpha2 of SMI but it just isn't the default because of dependency on Linkerd to update to SMI v1alpha2.

Since its natural for different implementations of SMI mesh providers to use different SMI versions, is it possible to make the SMI version configurable as long as Flagger has the code to work with that version? This will obviate the need to depend on mesh provider's SMI versioning.

[stefanprodan]

Do you know of any SMI implementation using v1alpha2 or v1alpha3?

[xavipanda]

@stefanprodan

Support for SMI v1alpha3 is needed for NGINX Service Mesh that uses v1alpha3 and it may work with flagger if this gets sorted out.
When using "provider: smi" it just fails coz the v1alpha2 syntax.. a small bump on v1alpha3 could sort this out and add support for the NSM.

[stefanprodan]

a small bump on v1alpha3

If that were true I would’ve done it ages ago :)) Maybe you are not aware but v1alpha3 is not backwards compatible and it will break Linkerd. Both v1alpha2 and v1alpha3 come with breaking changes, so Flagger needs to support them all in parallel.

[xavipanda]

thats the problem... NSM have implemented v1a3 and it crashes on flagger.

• Personal thoughts:
  NSM (nginx service mesh) is a great alternative, deployment adoption compared to others is much simpler.. but at the time to attempt provider SMI of flagger, it failed and i think that adapting the syntax for the use-case of flagger for SMI rollout canaries should be relatively simple to achieve.

@stefanprodan appreciate that you bringing this back to life :)