expose storage provisioning failures more clearly

I seem to be able to import larger filesystems just fine

$ juju import-filesystem ebs vol-0adf6e5d88f10e999 data
importing "vol-0adf6e5d88f10e999" from storage pool "ebs" as storage "data"
imported storage data/5

$ juju storage
[Storage]
Unit Id Type Pool Provider id Size Status Message
      data/5 filesystem ebs vol-0adf6e5d88f10e999 4.9TiB detached

but alas, I still get a failure with the larger volume https://paste.ubuntu.com/p/zzYHGH2mNT/

juju controller machine-0.log | http://paste.ubuntu.com/p/6hd5JbxJ5W/

I don't see an actual error in: https://paste.ubuntu.com/p/FX9qbmbQGQ/ is it just that machine 4 (for elasticsearch/4) stays in allocating?

@jameinel yeah ...... the other part is such that if you import the volume and attach it, it will hang and never attach.

What seems to be happening is that "--storage foo=ebs,2000G" defaults to the standard volume-type:

https://jujucharms.com/docs/2.3/charms-storage#aws/ebs-(ebs)

Which I suspect maps to the prev gen of EBS, which is limited to 1TB:

https://aws.amazon.com/ebs/previous-generation/

You can work around this by using the 'gp2' volume-type in a new storage pool:

juju create-storage-pool mybytes ebs volume-type=gp2

And then deploy like:

juju deploy postgresql --storage pgdata=mybytes,2000G

So what I think needs to happen to really fix this bug is either:

a) change our default ebs volume-type to 'gp2'
b) capture some error at the aws provider, hopefully telling us why 2TB is not available with prev-gen ebs, and display that to the user (versus our current UX of keeping the unit in 'waiting' forever).

Also worth noting.. gp2 is probably the same as the default juju "ebs-ssd" storage pool, meaning you might be able to do the following without creating a new pool:

juju deploy postgresql --storage pgdata=ebs-ssd,2000G

I'm not sure how you'd get a magnetic pool > 1TB; perhaps a new ebs pool with "volume-type=[st1|sc1]"?

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html

Oh mylanta, we *do* expose an error... It's not obvious at first:

$ juju storage
[Storage]
Unit Id Type Pool Provider id Size Status Message
postgresql/0 pgdata/0 filesystem pending

But you can see it with the --volume flag:

$ juju storage --volume
[Volumes]
Machine Unit Storage Id Provider Id Device Size State Message
0 postgresql/0 pgdata/0 0 error volume size 2000 GiB exceeds the maximum of 1024 GiB

How about we set the storage status to something besides 'pending' if the underlying volume is in 'error'?

@kwmonroe "How about we set the storage status to something besides 'pending' if the underlying volume is in 'error'?:" - 100%

"volume-type=[st1|sc1]" - dreaming! possibly a new bug for the support of st1 and sc1?

Filed this https://bugs.launchpad.net/juju/+bug/1753593 in support of st1, sc1, and io1.

This bug has not been updated in 2 years, so we're marking it Low importance. If you believe this is incorrect, please update the importance.