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.

Sign up for GitHub

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

Jump to bottom

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
@Aflynn50
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 reneradoi mentioned this issue Aug 29, 2024
Merged
reneradoi added a commit to canonical/opensearch-operator that referenced this issue Aug 29, 2024
@reneradoi
upgrade juju-dependencies (#418)
5ce2068 
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 •
edited
Loading

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
@Gu1nness
fix: Enfore libjuju version
5ed8608 
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 mentioned this issue Sep 5, 2024
Closed
@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.

This was referenced Dec 19, 2024
Merged
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@Aflynn50 Aflynn50

Labels
area/storage kind/bug indicates a bug in the project priority/normal normal priority
Projects
None yet
Milestone
No milestone
5 participants
@Aflynn50 @Gu1nness @lucasgameiroborges @shayancanonical @reneradoi