Closed PietroPasotti closed 1 year ago
I am not particularly sure why this was not already added to the Model.deploy
. This is not a frequently demanded features as far as I know. Said that, I would be happy to include it. We will evaluate how much effort it requires. Bear in mind that this feature is out of the roadmap and probably will have low priority.
Thanks for the suggestion.
Dear @juanmanuel-tirado,
Is it possible to include the feature in the roadmap? It affects our GH tests. We are pinning bundle revisions/series to guarantee quality in charmhub. Also, we have subordinate charms where a series match is crucial.
At the moment juju.Model.deploy
completely ignores revision/series,
and we must create dirty hacks to test complex scenarios and trust our GitHub CI.
Tnx in advance!
Hi there,
There is an ongoing effort on the Juju side to provide a new deploy
endpoint that will release python-libjuju from a lot of the logic implemented for deployments. Unfortunately, this is not ready and including revisions will require some additional work. Let me re-evaluate this issue and check how much effort would it take. We can probably add this to the next development cycle.
Thanks for reaching out!
I can
juju deploy foo --channel bar --revision 42
, butjuju.Model.deploy
does not seem to have a way to controlrevision
.Can we add this feature?
Some more context: I heard a rumor that we want to move away from pinning charms by revisions, relying instead solely on channels. However, since the juju cli offers that functionality, IMHO we should include it in this wrapper for completeness. We can always add a warning, a deprecation notice when the time comes, and eventually phase it out again. But forcing people to
Popen
isn't nice either.