search

juju / python-libjuju

Python library for the Juju API
Apache License 2.0
59 stars 98 forks source link

Parsing of storage constraints fails #1093

Open reneradoi opened 2 weeks ago

reneradoi commented 2 weeks ago

Description

Hi Team!

After upgrading our libs to 3.5.2 one of our integration test fails with this error:

[...]
File "/home/ubuntu/actions-runner/_work/opensearch-operator/opensearch-operator/.tox/integration/lib/python3.10/site-packages/juju/constraints.py", line 131, in parse_storage_constraint
    for m in STORAGE.finditer(constraint):
TypeError: expected string or bytes-like object

This is presumably due to https://github.com/juju/python-libjuju/pull/1053, which added parsing the storage constraints by applying re.finditer() on the given constraints. But as some of these (e.g. size) are integers and no strings, this fails.

We define the storage constraints like this: storage = {"opensearch-data": {"pool": "opensearch-pool", "size": 2048}} This cannot be changed to string as per https://github.com/juju/python-libjuju/blob/main/juju/client/_definitions.py#L6531-L6532.

Urgency

Annoying bug in our test suite

Python-libjuju version

3.5.2.0

Juju version

3.4.3, 3.5.3

Reproduce / Test

storage = {"opensearch-data": {"pool": "opensearch-pool", "size": 2048}}
ops_test.model.deploy(my_charm, num_units=1, series=SERIES, storage=storage)
shayancanonical commented 2 weeks ago

Encountered the same issue. The reason I suspect is that:

1053 expects to parse storage (in the _deploy() helper function) as following here:

ops_test.model.deploy(..., storage={"pgdata": "lxd-btrfs,2048"})

However, the ops_test.model.deploy() method still expects the storage to be passed as follows here:

ops_test.model.deploy(..., storage={"pgdata": {"pool": "lxd-btrfs", "size": 2048})

client.Constraints returns a custom object which is incompatible with the expected type in _deploy()

Gu1nness commented 1 week ago

I do have the same issue on mongodb operator with a tests similar to @reneradoi

lucasgameiroborges commented 1 week ago

This affects postgreSQL charms as well, exact same issue.