feat: add mlflow_client requirer logic - #328
MattiaSarti wants to merge 19 commits into
Conversation
…d not in requirer model
…uests and not in requirer model" This reverts commit f0343dc.
…ntity-permissions in config exposed to users
|
@dragomirp, feel free to disregard this pull request, at least for now that I'm still making changes (I've converted it to a draft for clarity), and since I am in touch with @Gu1nness for supervision |
Gu1nness
left a comment
Gu1nness
left a comment
There was a problem hiding this comment.
Only one nit, but excellent work otherwise !
| # TODO: restore once https://github.com/canonical/mlflow-operator/pull/494 lands on main, | ||
| # that is on channel "latest/edge", as python-libjuju breaks with this channel format: | ||
| ops_test.juju( | ||
| "deploy", MLFLOW, "--trust", "--channel", "latest/edge/pr-494", "--revision", "1529" | ||
| ), | ||
| # ops_test.model.deploy(MLFLOW, channel="latest/edge", trust=True), |
There was a problem hiding this comment.
note: as noted down, to implement this TODO, the provider's pull request is to be merged first, but to have that merged, data-integrator has to be on latest/edge first, so that that pull request has something to deploy for its integration tests for this new mlflow_client behavior, since it can't be merged before adding proper integration tests, so the current data-integrator's pull request will have to be merged as is, and a separate pull request will have to be created to address this TODO, at a later time
2 participants
resolves canonical/mlflow-operator#493
note: this pull request goes hand in hand and was tested in conjunction with canonical/mlflow-operator#494