Prometheus latest/edge requires juju >= 3.0.3

[NohaIhab]

Prometheus recently got a patch causing it to assume juju >= 3.0.3. That results in our integration tests breaking in multiple repos, some of those being notebook-operators and metacontroller. See this comment where we bumped into the issue.

[NohaIhab]

This can be handled temporarily by pinning Prometheus to a revision, and unpinning it once we migrate to Juju 3.1.

[phoevos]

Currently, only charms deploying Prometheus from latest/edge are affected. However, the Observability team will soon bump the rest of the latest tracks, which will affect even more of our repos. We have decided to pin the Prometheus revision when deploying from latest to avoid fetching recent patches of the charm which assume juju >= 3.0.3. This is a temporary patch until we migrate to Juju 3.1.

Revision 137 was the last one seen working properly in our CI integration tests, so it will be used for all of our charms that rely on some latest track of the Prometheus charm.

A list of the affected charms is provided below:	Charms	Prometheus Version
metacontroller minio notebooks training-operators	latest/edge
argo istio kfp knative mlflow	latest/stable
dex	latest/beta

[i-chvets]

Just a quick comment. We have exactly same issue before 1.7 release. Prometheus/Grafana updates break us from time to time. Possible approach is to pin everything that we depend on to revisions when we cut a track branch. This is a proper way to "freeze" branch in time to avoid extra work in the future. There is no point having edge in track branches.

[DnPlas]

The most recent version of the CI for all Charmed Kubeflow owned repositories use juju 3.x for both client and controller. This should not be an issue anymore.

[syncronize-issues-to-jira[bot]]

Thank you for reporting us your feedback!

The internal ticket has been created: https://warthogs.atlassian.net/browse/KF-5207.

This message was autogenerated