juju / python-libjuju

Python library for the Juju API
Apache License 2.0
60 stars 100 forks source link

[Bug]: series is required when deploy local charm #824

Closed beliaev-maksim closed 1 year ago

beliaev-maksim commented 1 year ago

Description

In our CI we use juju 2.9.42 and run integration tests

      - name: Setup operator environment
        uses: charmed-kubernetes/actions-operator@main
        with:
          provider: microk8s
          channel: 1.24/stable
          # Pinning juju agent to 2.9.42 to keep compatibility with pythonlib-juju<3
          bootstrap-options: --agent-version="2.9.42"

however, we get the following error

Traceback (most recent call last):
  File "/home/runner/work/knative-operators/knative-operators/tests/test_cos_integration.py", line 27, in test_build_deploy_knative_charms
    await ops_test.model.deploy(
  File "/home/runner/work/knative-operators/knative-operators/.tox/cos-integration/lib/python3.8/site-packages/juju/model.py", line 1820, in deploy
    raise JujuError(
juju.errors.JujuError: Couldn't determine series for charm at /home/runner/work/knative-operators/knative-operators/.tox/cos-integration/tmp/pytest/cos-test0/charms/knative-operator_ubuntu-20.04-amd64.charm. Pass a 'series' kwarg to Model.deploy().

Here is the failed CI: https://github.com/canonical/knative-operators/actions/runs/4568754484/jobs/8075207231

Urgency

Annoying bug in our test suite

Python-libjuju version

juju==3.0.4

Juju version

2.9.42

Reproduce / Test

we use this procedure to build and deploy local charm:

async def test_build_deploy_knative_charms(ops_test: OpsTest):
    # Build knative charms
    charms_path = "./charms/knative"
    knative_charms = await ops_test.build_charms(
        f"{charms_path}-operator", f"{charms_path}-serving", f"{charms_path}-eventing"
    )

    # Deploy knative charms
    await ops_test.model.deploy(
        knative_charms["knative-operator"],
        application_name="knative-operator",
        trust=True,
        resources=KNATIVE_OPERATOR_RESOURCES,
    )
juanmanuel-tirado commented 1 year ago

I need to have a longer discussion around this issue. Meanwhile, one workaround could be setting the default-series for the model. juju model-config default-series=focal

juanmanuel-tirado commented 1 year ago

A brief summary.

This is fixed in the 3.1 branch. Because your constrained to use juju 2.9, we will have to prepare a new release in the 3.0 series backporting the fix.

cderici commented 1 year ago

@beliaev-maksim Pylibjuju 3.0.4 is a bit old version at this point (and a bit tricky one ngl), however, we do have some versions that includes a solution to this problem which you should be able to easily upgrade to (i.e. 2.9.42.1).

I believe the solution to this problem is https://github.com/juju/python-libjuju/pull/783 and it seems we released it with 2.9.38.1. I can cherry-pick those fixes onto our new 3.0 branch and basically make a 3.0.5 for you that works no problem, but I just want to understand first, is there a particular reason that you can't use the pylibjuju 2.9.42.1, since you're using a 2.9.42 juju agent on the controller?

beliaev-maksim commented 1 year ago

I think we can

overall, I use it due to the promise was that we 3.0 works on both ends :)

for now I just use the workaround provided by Juan and set series on model, which works just fine

beliaev-maksim commented 1 year ago

so, I think there is no need to backport it to 3.0

but up to Juan

cderici commented 1 year ago

No you're right that's accurate, the 3.0 is sort of a transitional version to allow people some time to upgrade their juju (along with their pylibjuju) to 3.0 and onwards, trying to support 2.9 and 3.0 at the same time. At 3.1 we break this and remove the juju 2.9 support.

Problem is as long as people are keep staying in 2.9 and 3.0, supporting them is getting harder every day. That's why we created a 2.9 branch on libjuju to backport patches as we continue to fix bugs on the main branch. Ultimately, I think we did a poor job communicating that 3.0 should not be a version that people settle in and stay there.

Anyways I'm glad that the workaround is working for you guys. I'll close this issue, and we'll discuss what to do with the 3.0 branch. In the meantime, let us know if you have any trouble using 2.9.42.1, it's a way easier place for us to fix any of your problems right away (without worrying about a weird intermediate transitional version like 3.0.5 😄 )