Open jenshu opened 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)
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:
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
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.
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.
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