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

[POC] APIRule v1beta1 removal #1673

Open
7 tasks
strekm opened this issue Feb 5, 2025 · 0 comments
Open
7 tasks

[POC] APIRule v1beta1 removal #1673

strekm opened this issue Feb 5, 2025 · 0 comments
Assignees

Comments

@strekm
Copy link
Contributor

strekm commented Feb 5, 2025

Description

Goal of this task is to figure out what steps need to be taken to ultimately remove APIRule v1beta1 from CRD. Given that kubernetes storage version is v1beta1 all APIRule CRs, including v2alpha1, are stored in v1beta1. This means all that rules needs to be converted and saved in v2 versions. There can be no data loss, nor workload availability loss. Given that v1* and v2 are not compatible some data related to oauth2 specific handlers need to be saved as annotations. Have in mind following requirements:

  • v1beta1 becomes unserved, not removed from the CRD
  • all v2alpha1 apirules need to be migrated to stored version
  • stored version changes to v2
  • oauth2 handlers details are stored as annotations
  • ORY Oathkeeper will be removed from API Gateway module with v1beta1 removal from CRD

Steps that were already discovered:

  • Remove not migrated v1beta1 APIRule CRs from the cluster having in mind that subresources need to stay and workload need to be available
  • changes storage version to v2
  • migrate apirules to version v2
  • unserve v1beta1

Handling of not migrated v1beta1 is not in scope of this task and will be addressed separately. Consider that workloads exposed with v1beta1 can't experience any downtime, nor any APIRule sub-resources get deleted. It will be responsibility of APIRule controller to handle that properly.

Consider the following scenario in POC and document the outcome when user misses the deadline of migration and still has old resources without removing old APIRule:
0. Deploy example APIRule in v1beta1 with httpbin workload exposed

  1. Set APIRule v2 as stored version
  2. Change APIRule reconciliation to use v2 in Informer (For() function) and remove v1beta1 usage
  3. Unserve APIRule v1beta1
  4. Check if connectivity to httpbin workload is working continuously
  5. Check if reconciliation is working on old resource by restarting manager and checking logs
  6. Apply example APIRule using new manifest
  7. Check if connectivity to httpbin workload is still running
  8. Check if controller picked up reconciliation

AC:

  • document steps that need to be taken in order to remove APIRule v1beta1

Reasons

DoD:

  • Provide unit and integration tests.
  • Provide documentation.
  • Verify if the solution works for both open-source Kyma and SAP BTP, Kyma runtime.
  • If you changed the resource limits, explain why it was needed.
  • Verify that your contributions don't decrease code coverage. If they do, explain why this is the case.
  • Add release notes.

Attachments

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants