Charm storage metadata #77
Conversation
| // Shared indicates that the storage is shared between all units of | ||
| // a service deployed from the charm. It is an error to attempt to | ||
| // assign non-shareable storage to a "shared" storage requirement. | ||
| Shared bool |
There was a problem hiding this comment.
I'd personally like to see, for each of these attributes and where applicable, a comment indicating what the default value is if not explicitly specified in the metadata. The defaults are specified in the schema definition elsewhere, but this is where the main doc for the meaning of each attribute is, so someone reading the code may find it useful. YMMV.
|
provisional LGTM pending william's approval |
| ) | ||
|
|
||
| // Storage represents a charm's storage requirement. | ||
| type Storage struct { |
There was a problem hiding this comment.
can we be explicit about serialization names throughout please?
There was a problem hiding this comment.
Can do, though I'm reluctant to increase the use of bson tags here. I'll whip up a patch tomorrow to duplicate the Meta structure in juju/state.
There was a problem hiding this comment.
I asked Rog about this, and he said that Meta is being used directly in the charm store code. So I went ahead and added bson tags with names to everything.
|
@fwereade PTAL. |
Charms will be able to specify what their storage requirements/wants are.
- consistent bson tags on Meta, Relation, Storage - fix CountMax default value, and test
- No more filesystem - No more persistent - Change count to multiple.range - Add description field I have not yet added minimum size or properties: these can be added later.
axw
force-pushed
the
charm-meta-storage
branch
from
defe341
to
eed4aaf
Compare
|
PTAL. I've updated again to match recent changes to the spec.
I have not yet added minimum size or properties: these can be added later. |
|
LGTM |
We introduce a new "storage" attribute to charm metadata, which describes required and optional storage for a charm. Each may be raw block devices, or file systems. The charm declares the name, type and some restrictions on the storage, and the administrator specifies how to fulfil that storage when deploying the charm.
The metadata format is based on the storage phase 1 scope document:
https://docs.google.com/a/canonical.com/document/d/1-9ZPfdgpkj2R9mBG_tlSclGGyK3tRpMf2L4C37mzYD8/edit#bookmark=id.6abw2ee0ebgm
which is mostly the same as described in the spec: https://docs.google.com/a/canonical.com/document/d/1OhaLiHMoGNFEmDJTiNGMluIlkFtzcYjezC8Yq4nAX3Q/edit
Note that the spec was never signed off, and the scope document is yet to be reviewed. This metadata format is subject to change, and should not be documented until it is finalised. In the short term, this unblocks further work on storage in Juju (which should be uncontroversial).
There are also two new hook kinds defined for notifying units of storage attachment and detachment.