You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If begin() is used instead of begin_with_initial_hooks, everything is ok, because begin_with_initial_hooks does the attaching (to then emit the StorageAttached event) and begin does not. Similarly, if attach=True is not used, everything is ok.
However, when run as above, an error like this is generated:
Traceback (most recent call last):
File "/tmp/storagetest/test.py", line 41, in <module>
h.begin_with_initial_hooks()
File "/tmp/storagetest/.venv/lib/python3.11/site-packages/ops/testing.py", line 407, in begin_with_initial_hooks
self.attach_storage(s.full_id)
File "/tmp/storagetest/.venv/lib/python3.11/site-packages/ops/testing.py", line 752, in attach_storage
if not self._backend._storage_attach(storage_id):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/tmp/storagetest/.venv/lib/python3.11/site-packages/ops/testing.py", line 2348, in _storage_attach
mounting_dir.symlink_to(target_dir)
File "/usr/lib/python3.11/pathlib.py", line 1199, in symlink_to
os.symlink(target, self, target_is_directory)
FileExistsError: [Errno 17] File exists: '/tmp/ops-harness-z2tflymi/storages/test-storage/0' -> '/tmp/ops-harness-z2tflymi/containers/test-container/mounts/foo'
This happens because the add_storage call mounts the storage, and then the begin_with_initial_hooks attempts to mount it again, but that's already happened, so the symlinking fails.
We should:
Adjust the API documentation so that it explicitly says that attach does nothing if begin hasn't yet been called
Verify that begin has been called (ie. ._charm is not None) before trying to mount the storage
The text was updated successfully, but these errors were encountered:
…e begin (#1150)
One minor fix to the `storage` metadata:
[charmcraft.yaml](https://juju.is/docs/sdk/charmcraft-yaml#heading--storage)
and
[metadata.yaml](https://juju.is/docs/sdk/metadata-yaml#heading--storage)
support a `multiple.range` value in the form `<n>+` - this would
previously error out when we attempted to read the metadata. We now
support this (as an alias for `<n>-`, which is an open-ended range
rather than "n or less", and have a test for it.
Adds a minor clarification in the API docs when `Harness.add_storage`
will emit a storage-attached event.
In `begin_with_initial_hooks`, if the storage has already been attached,
then don't try to attach it a second time, but *do* emit the
storage-attached event, since that will not have been done previously.
Make the `_storage_attach` method safe to call multiple times. This
appears to have been the intention based on comments in the code, but,
in practice, attempting to symlink the mount would fail. Now, if the
symlink already exists (and has the same target) then we continue.
Adds a variety of tests for Harness `add_storage` and `attach_storage`
behaviour.
Fixes#1127
---------
Co-authored-by: Ben Hoyt <ben.hoyt@canonical.com>
For example:
If
begin()
is used instead ofbegin_with_initial_hooks
, everything is ok, becausebegin_with_initial_hooks
does the attaching (to then emit theStorageAttached
event) andbegin
does not. Similarly, ifattach=True
is not used, everything is ok.However, when run as above, an error like this is generated:
This happens because the
add_storage
call mounts the storage, and then thebegin_with_initial_hooks
attempts to mount it again, but that's already happened, so the symlinking fails.We should:
attach
does nothing ifbegin
hasn't yet been calledbegin
has been called (ie.._charm is not None
) before trying to mount the storageThe text was updated successfully, but these errors were encountered: