Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
jenshu opened this issue Sep 26, 2022 · 3 comments
Open

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

jenshu opened this issue Sep 26, 2022 · 3 comments
Assignees
Labels
Area: Gloo Fed Issues related to the Gloo Fed project in solo-projects Size: S 1 - 3 days stale Issues that are stale. These will not be prioritized without further engagement on the issue. Type: Enhancement New feature or request
Milestone

Comments

@jenshu
Copy link
Contributor

jenshu commented Sep 26, 2022

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.

  • Consider versioning the CRDs and using conversion webhooks
  • Conversion webhook may not be needed for the first pass, as most of the Gloo Fed CRs don't currently have openapi schemas. Need to test/verify and may be able to close this out without code changes.

Describe the solution you'd like

No response

Describe alternatives you've considered

No response

Additional Context

No response

@jenshu jenshu added the Type: Enhancement New feature or request label Sep 26, 2022
@jenshu jenshu added the Size: S 1 - 3 days label Sep 26, 2022
@jenshu jenshu added this to the Fed canary milestone Oct 11, 2022
@sam-heilbron
Copy link
Contributor

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
Copy link
Contributor

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 #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 Fed canary upgrade/downgrade tests #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.

@jenshu jenshu added Area: Gloo Fed Issues related to the Gloo Fed project in solo-projects and removed Area: Fed labels Mar 21, 2023
Copy link

github-actions bot commented Jun 5, 2024

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.

@github-actions github-actions bot added the stale Issues that are stale. These will not be prioritized without further engagement on the issue. label Jun 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: Gloo Fed Issues related to the Gloo Fed project in solo-projects Size: S 1 - 3 days stale Issues that are stale. These will not be prioritized without further engagement on the issue. Type: Enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants