You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
Set APIRule v2 as stored version
Change APIRule reconciliation to use v2 in Informer (For() function) and remove v1beta1 usage
Unserve APIRule v1beta1
Check if connectivity to httpbin workload is working continuously
Check if reconciliation is working on old resource by restarting manager and checking logs
Apply example APIRule using new manifest
Check if connectivity to httpbin workload is still running
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
The text was updated successfully, but these errors were encountered:
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:
Steps that were already discovered:
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
AC:
Reasons
DoD:
Attachments
The text was updated successfully, but these errors were encountered: