amulet
amulet copied to clipboard
juju
Add Support for Juju Storage
This is needed for testing charms that depend on the juju-storage feature, these charms come with
- [name]-storage-attached
- [name]-storage-detaching hooks for every used storage relation, which need testing.
A charm can be deployed with different storage provider (e.g. loop or ebs for block)
$ juju deploy <charm> --storage <name>=<pool>,<size>,count
This could be expressed as an extension of Deployment.add(), e.g.
.add( 'servicename', storage={servicestorage:{'pool': 'ebs', 'size': 1024, 'count': 3}})
Juju-Storage also provides the possibility to add storage to already deployed units
$ juju storage add <unit> <name>=<pool>,<size>,count
I'm not sure how the adding (removing) of storage should be expressed in terms of amulet.
Trying to add this support myself, I stopped when I realize that amulet makes use of juju-deployer. juju-deployer does not provide support for juju-storage (not sure if it is expressible in the bundle-format, was not able to create a bundle using juju-gui export on a deployment with juju-storage)
To expand, d.unit should also have a storage_add and storage_remove primitives which Juju has. I completely agree this needs to be added, especially since storage exists in Juju today.
As for the deployer bits, this is in a weird phase change since Juju 2.0 adds native support for bundles, and storage I believe is a part of that primitive, we may need to add storage to deployer as part of this. We can also work around this by transparently supporting it where .add takes a storage parameter, executes a bundle, then invokes the storage add bits via the API after the bundle completes (or in parallel).
@tvansteenburgh opinions on the best approach for this?
@Yrrsinn we'll schedule this in for something we try to tackle very soon to unblock you and others writing charms with storage.
@axw added support to native bundle deploy with storage a bit ago and it's in 2.0. https://github.com/juju/bundlechanges/blob/2618de2ad622b29a396a826628d4a81b8562d6b2/changes_test.go#L1106
I understand that the deployer doesn't but I wonder if it can pass those settings on without interpreting. That one will have to be a different look/chunk of work.
