search

solo-io / gloo

The Feature-rich, Kubernetes-native, Next-Generation API Gateway Built on Envoy
https://docs.solo.io/
Apache License 2.0
4.06k stars 433 forks source link

Fed canary upgrades: make sure CRDs are backwards compatible #7234

Open jenshu opened 1 year ago

jenshu commented 1 year ago

Version

No response

Is your feature request related to a problem? Please describe.

Make sure all Gloo Fed CRDs are backwards-compatible, i.e. an old Gloo Fed version can keep running after applying new CRDs on the cluster.

Describe the solution you'd like

No response

Describe alternatives you've considered

No response

Additional Context

No response

sam-heilbron commented 1 year ago

Step 1: Investigate where Fed APIs are defined, how CRDs are generated, and how resource marshaling is implemented. Need to consider both in-house controllers, and custom built ones (depending on solo-apis)

sam-heilbron commented 1 year ago

Backwards compatibility can be ensured the same way we require it for Gloo Edge APIs. This can be done by following the patters outlined in https://github.com/solo-io/gloo/issues/5663.

There are a couple of weaknesses in this answer:

  1. We don't yet have automated testing to prevent these types of breaks, it is currently on developers to understand the risk of API changes. Proposed solution: We should add explicit tests which will fail if a breaking change is introduced as part of https://github.com/solo-io/gloo/issues/7321

  2. The Gloo Fed APIs are maintained in our enterprise repo, and therefore a breaking change in an Edge resource, may not be caught by the above tests, until an open source version has been released. Proposed solution: We don't need to do it right away, but we could move the fed APIs into our open source repo to follow the pattern of other enterprise APIs. This would make it easier to define tests to validate backwards/forwards compatibility in one place.

github-actions[bot] commented 3 months ago

This issue has been marked as stale because of no activity in the last 180 days. It will be closed in the next 180 days unless it is tagged "no stalebot" or other activity occurs.