-
Notifications
You must be signed in to change notification settings - Fork 12
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
kfp-v2
bundle tests fail with all charms in waiting
#601
Comments
Thank you for reporting us your feedback! The internal ticket has been created: https://warthogs.atlassian.net/browse/KF-6574.
|
Grabbing a juju status with the use of This can be seen in this run (from this code and PR). Something that's also notable in this run is that the run fails when, right after
which ends in the code raising here:
and logs the following error
This issue is the same we saw in #549. EDIT: Discussing offline with @DnPlas, the EDIT 2: It looks like though app.get_status() starts with the same two lines of model.get_status() |
Note that this bug has been noticed intermittently (with a smaller frequency) in kfp-v1 bundle tests too https://github.com/canonical/kfp-operators/actions/runs/11934968609/job/33268744186?pr=604#step:6:23. |
Modified the
|
Another attempt was adding a await
|
This bug could be related to issue #549 (comment) since we noticed similar disconnection (specially when using the |
Upstream: juju/python-libjuju#1204 |
WorkaroundA workaround for the above bug is to replace sh.juju("wait-for","model","kubeflow", query="forEach(applications, app => app.status == 'active')", timeout="30m") and it is implemented in #614. Note that the bug is still present and tracked in upstream issue juju/python-libjuju#1204. |
the status severity code received a minor update, and there's the new wait_for_idle available behind a feature flag in pypi:juju==3.6.1.0 I can't guarantee that either of these fixes the issue, but it may be worth trying out. https://discourse.charmhub.io/t/python-libjuju-3-6-1-0-release-notes/16149 |
Bug Description
The tests fail intermittently (but really often) during test
test_upload_pipeline
with the error
source: https://github.com/canonical/kfp-operators/actions/runs/11821634908/job/32936826850#step:5:125
Investigating with @DnPlas it looks like the tests fail during the
kfp_client
fixture callingwhich prompted to if the
profile
crd is available at the time. Looking at thejuju status
it looks like all charms are in waiting status
which means that either for some reason
build_and_deploy
succeeds although the charms are not active/idle or they go to active and then they go back towaiting
. We also noticed that the kubeflow-profilespod
doesn't exist on the clusterDuring on_pull_request, the tests succeeded.
To Reproduce
rerun the CI from
main
Environment
juju 3.4.6
microk8s 1.29
charmcraft 3.2.1
Relevant Log Output
Additional Context
No response
The text was updated successfully, but these errors were encountered: