Restrict allowed controlplane/dataplane version combinations

mlavacca commented 2 years ago

Problem Statement

With Kong/gateway-operator-archive#441, we want to check and limit the versions of dataplanes and controlplane supported by the operator. That issue is only related to adding checks on the dataplane and the controlplane separately. Here we want to improve those checks by adding the mutual compatibility functionality (e.g., kong:3.0 is only compatible with KIC:2.7, Kong:3.1 is compatible with both KIC2.7 and KIC:2.8, and so on).

Note: the versions used above are just placeholders.

Proposed Solution

Since in Kong/gateway-operator-archive#441 there is the proposal of adding the validation at the generation image level, we can improve those functions by adding these mutual compatibility checks

Acceptance Criteria

[ ] a set of mutual compatibilities is defined
[ ] when the user asks for controlplane and dataplane versions that are NOT mutually compatible, the operator resolves it into an error, and no deployment is created.
[ ] when the user asks for controlplane and mutually compatible dataplane versions, the operator creates the respective deployments.

mlavacca commented 2 years ago

This issue is blocked by Kong/gateway-operator-archive#441

mflendrich commented 1 year ago

The implementation needs to account for the fact that we use various distribution channels for CP/DP images (e.g. Docker Hub, Red Hat registry/quay, possibly more in the future).

shaneutt commented 1 year ago

This one still seems relevant, but it kinda feels like we could probably just only support Kong Gateway v3.3 and up for our summit release, and that in itself would effectively resolve the problems we're trying to cover for here?

cc @mflendrich @mheap

mheap commented 1 year ago

I'm ok with 3.3+

shaneutt commented 1 year ago

cc @sentinelleader, @synthe102, @szesch for thoughts about a 3.3 minimum soon?

sentinelleader commented 1 year ago

We may need to check with marco and wanny to be sure that the early customers that we are planning to onboard are fine with 3.3, im not sure how often the big customers upgrade their infra but i remember some of the customers we are looking to onboard and play with cloud gateway are large organizations :)

mheap commented 6 months ago

Looking at this more closely, does this mean that as we release new Gateway versions we need to release KGO to add support?

I'd prefer that each CP version is compatible with an entire DP major version e.g. 3.x by default until we find an inconsistency and add a constraint

mlavacca commented 6 months ago

Looking at this more closely, does this mean that as we release new Gateway versions we need to release KGO to add support?

It does not, we can set unbounded version ranges, which means that for version >x.y of DP, the CP supported versions are 1.2.3 and 1.3.4. This way when the x.y+1 Gateway version is released, the compatibility remains the same, until we explicitly limit it (if we have to for any reason)

Kong / gateway-operator