-
Task
-
Resolution: Done
-
Normal
-
None
-
None
-
False
-
False
-
In Progress
-
Undefined
-
-
Sprint 205
We need to update recommended procedure for how to handle manually migrating resource which has been deprecated and removed from the destination.
Please ensure we address:
- Upstream docs
- https://github.com/konveyor/mig-operator/blob/master/docs/usage/GVKWarning.md
- Ensure we have a guided walkflow of how we recommend to address
- Downstream docs
- Older Blog, can we update?
- See if we can update the original blog post to point to new recommended procedure, maybe just a note at top linking to downstream docs?
- Lab
- https://github.com/konveyor/labs/blob/master/mtc/bookbag/workshop/content/exercises/debug/gvk.adoc
- Let's ensure we have an example to show the problem and then steps to fix with the new workflow
- General
- Please be sure we explicitly call out in our docs the difference between Deprecation and Removal. Deprecation itself is not an issue for a migration, it's when an API has been Removed that is a problem. Let's be clear on calling this distinction out as we have some customers confused and worrying on just the deprecation even though the removal didn't happen on their destination yet.
At least in our upstream docs let's also link to below for more context for folks, if we could link in downstream/lab would be nice, unsure if we can
https://kubernetes.io/docs/reference/using-api/deprecation-guide/#migrate-to-non-deprecated-apis
Background:
We relied on 'oc convert' and it was deprecated/removed from k8s in ~1.17.
See: https://github.com/kubernetes/kubectl/issues/725
There is a plugin we can use now:
https://kubernetes.io/docs/tasks/tools/included/kubectl-convert-overview/