Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Parsing of storage constraints fails #1093

Open
reneradoi opened this issue Aug 28, 2024 · 3 comments · Fixed by canonical/opensearch-operator#495 · May be fixed by canonical/opensearch-dashboards-operator#138
Open

Parsing of storage constraints fails #1093

reneradoi opened this issue Aug 28, 2024 · 3 comments · Fixed by canonical/opensearch-operator#495 · May be fixed by canonical/opensearch-dashboards-operator#138
Assignees
Labels
area/storage kind/bug indicates a bug in the project priority/normal normal priority

Comments

@reneradoi
Copy link

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 #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)
reneradoi added a commit to canonical/opensearch-operator that referenced this issue Aug 29, 2024
upgrade juju dependencies:
- juju-agent 3.5.3 for CI pipeline
- juju 3.5.0 in pyproject.toml (cannot be upgraded to 3.5.2 due to
juju/python-libjuju#1093)
@shayancanonical
Copy link

shayancanonical commented Aug 29, 2024

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
Copy link

Gu1nness commented Sep 3, 2024

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

Gu1nness added a commit to canonical/mongodb-operator that referenced this issue Sep 3, 2024
With the last libjuju version (3.5.2), there is a bug when trying to
deploy charms with custom storage
(juju/python-libjuju#1093)
This pins the libjuju version until it's fixed
@Aflynn50 Aflynn50 added kind/bug indicates a bug in the project priority/normal normal priority area/storage labels Sep 5, 2024
@Aflynn50 Aflynn50 self-assigned this Sep 5, 2024
@lucasgameiroborges
Copy link

This affects postgreSQL charms as well, exact same issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/storage kind/bug indicates a bug in the project priority/normal normal priority
Projects
None yet
5 participants