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.

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

Add Support for Juju Storage #112

Open
Yrrsinn opened this issue Feb 2, 2016 · 4 comments
Open

Add Support for Juju Storage #112

Yrrsinn opened this issue Feb 2, 2016 · 4 comments
Assignees

Comments

@Yrrsinn
Copy link

Yrrsinn commented Feb 2, 2016

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)

@marcoceppi
Copy link
Contributor

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.

@mitechie
Copy link
Contributor

@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.

@cholcombe973
Copy link

This is a blocker for me also on the gluster charm.

@tkuhlman
Copy link
Contributor

tkuhlman commented Jan 9, 2017

I just created PR #169 which address this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants