-
Notifications
You must be signed in to change notification settings - Fork 13
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
refactor kfp-api's on_remove to use KRH built-in delete #385
Conversation
3e3cfee
to
9d08c37
Compare
LGTM I see kfp-api integration failing because of mysql error fixed with this #386 just the bundle test is failing on |
1572e69
to
207ddfe
Compare
We will rebase and retarget this on main after #362 is merged |
Refactors kfp-api charm's `on_remove()` event handler to use KubernetesResourceHandler.delete() rather than its own removal procedure. This was done to: * use the same removal procedure as other charms * remove the need for the `on_remove()` handler to have a KRH object with full context (in future we will add another Kubernetes object here that requires relation data to render, but the relation data is not guaranteed to be available during remove)
f6a6db8
to
2abf848
Compare
PR has been rebased on |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Refactors kfp-api charm's
on_remove()
event handler to use KubernetesResourceHandler.delete() rather than its own removal procedure. This was done to:on_remove()
handler to have a KRH object with fullcontext
. In future we will add another Kubernetes object here that requires relation data to render, and this relation data may not be available during the removal event