Why it needs to get done
The kubeflow_dashboard libraryu has the following workaround:
|
def get_name_of_breaking_app(relation_name: str) -> Optional[str]: |
|
"""Returns breaking app name if called during RELATION_NAME-relation-broken and the breaking app name is available. # noqa |
|
|
|
Else, returns None. |
|
|
|
Relation type and app name are inferred from juju environment variables. |
|
""" |
|
if not os.environ.get("JUJU_REMOTE_APP", None): |
|
# No remote app is defined |
|
return None |
|
if not os.environ.get("JUJU_RELATION", None) == relation_name: |
|
# Not this relation |
|
return None |
|
if not os.environ.get("JUJU_HOOK_NAME", None) == f"{relation_name}-relation-broken": |
|
# Not the relation-broken event |
|
return None |
|
|
|
return os.environ.get("JUJU_REMOTE_APP", None) |
This should not be needed as of ops 2.10.0 release. We should test whether 2.10.0 successfully fixes this issue, and if so remove the current workaround.
What needs to get done
- test whether ops 2.10.0 fixes the relation-broken handling issue
- remove the workaround
- update any charms that use this library to remove the workaround from all charms
When is the task considered done
- publish an updated charm library with the hack removed
- update all charms that use the library (or create separate issues for them to be updated)
Why it needs to get done
The kubeflow_dashboard libraryu has the following workaround:
kubeflow-dashboard-operator/lib/charms/kubeflow_dashboard/v0/kubeflow_dashboard_links.py
Lines 320 to 337 in 05ac84b
This should not be needed as of ops 2.10.0 release. We should test whether 2.10.0 successfully fixes this issue, and if so remove the current workaround.
What needs to get done
When is the task considered done