[JUJU-1628] Deploy by revision

[cderici]

Description

This adds the feature that allows deploying by revision, by passing through the revision info into the ResolveCharms API call.

Fixes #690

QA Steps

An example is added, so it should work:

 $ python examples/deploywithrevision.py

• Along with that example, I need to write some integration tests for this before landing (see discussion below).

tox -e integration -- tests/integration/test_model.py::test_deploy_by_revision

tox -e integration -- tests/integration/test_model.py::test_deploy_by_revision_validate_flags

All CI tests need to pass.

Notes & Discussion

• Before landing, we need to make sure that the input validation is being handled gracefully. For regular charms, --revision requires --channel, however for bundles, --channel and --revision are mutually exclusive. The ResolveCharms call should be getting us the right errors for those, we just need to make sure those errors are passed through correctly. (there should be integration tests for these validations)

[juanmanuel-tirado]

Manual QA is not passing.

Using Juju:

juju deploy juju-qa-test test1 --revision=19 --channel=latest/edge
Located charm "juju-qa-test" in charm-hub, revision 19
Deploying "test1" from charm-hub charm "juju-qa-test", revision 19 in channel latest/edge on [email protected]/stable
juju status test1
Model  Controller  Cloud/Region         Version  SLA          Timestamp
test   lxd312      localhost/localhost  3.1.2    unsupported  11:18:59+02:00

App    Version  Status   Scale  Charm         Channel      Rev  Exposed  Message
test1           waiting    0/1  juju-qa-test  latest/edge   19  no       waiting for machine

Unit     Workload  Agent       Machine  Public address  Ports  Message
test1/1  waiting   allocating  27                              waiting for machine

Machine  State    Address  Inst id  Base          AZ  Message
27       pending           pending  [email protected]      

We get revision 19. When using python-libjuju:

from juju.model import Model
m = Model(); await m.connect()
await m.deploy("juju-qa-test", "test21python", revision=19, channel="latest/edge")

We don't get the expected revision:

 juju status test2
Model  Controller  Cloud/Region         Version  SLA          Timestamp
test   lxd312      localhost/localhost  3.1.2    unsupported  11:19:50+02:00

App    Version  Status   Scale  Charm         Channel      Rev  Exposed  Message
test2           waiting    0/1  juju-qa-test  latest/edge   21  no       waiting for machine

Unit     Workload  Agent       Machine  Public address  Ports  Message
test2/0  waiting   allocating  28       10.220.18.224          waiting for machine

Machine  State    Address        Inst id         Base          AZ  Message
28       pending  10.220.18.224  juju-a38396-28  [email protected]      Running

The returned revision should be 19.

[juanmanuel-tirado]

In the test, we need to deploy a revision previous to the latest one to really check the solution.

[juanmanuel-tirado]

Manual QA works. Part of the CI integration tests fails because the ubuntu charm in version 22 requests storage. That's OK. However, this solution does not mimic the Juju CLI when deploying bundles. For example:

await m.deploy("anbox-cloud-core", "test", revision=60)
...
JujuError: specifying a revision requires a channel for future upgrades. Please use --channel

if using --channel

await m.deploy("anbox-cloud-core", "testb", revision=60, channel="stable")
....
JujuError: revision and channel are mutually exclusive when deploying a bundle. Please choose one.

With the Juju CLI deploying bundles can be done without setting the channel.

juju deploy anbox-cloud-core --revision=60 

I think we can push this one. However, we have to address this in a separated PR.

[juanmanuel-tirado]

LG2M

We expect some CI to fail due to the ubuntu 22 charm requiring storage.

[juanmanuel-tirado]

/merge