obtain storage path in charm container by storage name
See original GitHub issueI would like to be able to obtain the mounted storage location in a charm container, by storage name.
For example:
storage:
logs:
type: filesystem
# specifying location on the charm container is optional
# when unspecified, defaults to /var/lib/juju/storage/<name>/<num>
From charm code, I would like to be able to do something like “get_storage_path(“logs”)”.
One option is to increase the scope of self.meta
from metadata.yaml
to a broader definition.
(self.meta.storages["logs"].location
in this case would be None
.)
Issue Analytics
- State:
- Created 2 years ago
- Comments:18 (18 by maintainers)
Top Results From Across the Web
Storage - Juju
If left unset, the charm container will have the storage volume mounted at a predictable path at /var/lib/juju/storage/<name>/<num> , where <num> is the ......
Read more >Storage provider - doc - Charmhub - Juju Discourse
The 'cinder' storage provider has a 'volume-type' configuration option whose value is the name of any volume type registered with Cinder.
Read more >Azure Media Services (v3) - specific output asset container ...
When using the REST API for Create Asset you are able to set the container name: ... You are right, working like a...
Read more >Blob Containers - Get - REST API (Azure Storage Resource ...
The name of the storage account within the specified resource group. Storage account names must be between 3 and 24 characters in length...
Read more >ConfigMaps | Developer Guide - OpenShift Documentation
The ConfigMap object provides mechanisms to inject containers with configuration data while keeping containers agnostic of OpenShift Container Platform.
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
The storage paths for some clouds are deterministic, but I don’t believe that they are guaranteed to be so in the future. AFAIK, the path being deterministic for sidecar charms is a consequence of the current implementation, and not necessarily an intentionally supported feature.
It’s safest to get the path to the storage at runtime, as close to the code that needs it as possible. The lookup is cheap, in terms of CPU resources, and the call is a one liner, so it should do no harm to require charms to do so.
If there’s a circumstance where a charm absolutely cannot get the storage path at the time that it needs it with things as they are currently written, we can re-open and investigate this issue. I believe that it should remain closed for now, however.
Just wanted to drop a quick note here: I think this is a good idea, and I’ve proposed fixing up location as part of the general update we’re doing to support metadata v2. Will update when/if plans get more concrete.