I recently upgraded from Juju 1.18 to 1.18.1, and suddenly my charm to deploy a MapR hadoop cluster stopped working. I traced the problem to the fact that non-root disks are no longer associated with the instances, even though the constraints to the juju-deploy option have not changed.

As far as I can tell, there is not yet a juju constraint that defines non-boot storage. The documentation for the root-disk constraint specifically notes "Additional storage that may be attached separately does not count towards this value."

Two questions:

  1. What changed ? The default m1.xlarge instances have 1 or 2 ephemeral disks when I create them within the basic ec2 commands ... but not when Juju creates them
  2. What is the Juju-supported mechanism for defining additional storage volumes.
  • This seems like poor behavior on our part, it would really help us if you could add the exact constraint you are using to your question, thanks! – Jorge Castro Apr 30 '14 at 22:31
  • If you can also check to see if you're getting m1.xlarges or m3.xlarges with the same constraints you used previously that can help us debug. – Jorge Castro Apr 30 '14 at 22:50

This appears to be the issue.

"For M3 instances, you must specify instance store volumes in the block device mapping for the instance. When you launch an M3 instance, we ignore any instance store volumes specified in the block device mapping for the AMI."

So, if you were switched to m3 instances from m1 instances by the pricing drop, you may well no longer be getting instance store when our images previously included it:

Here are some workarounds:

  • In Juju 1.20 you will specifically be able to specify m1.xlarge so that Juju doesn't try to be smarter than you (and fail) at giving you the proper instance. We have this in 1.19, however that is the unstable release and might bring some other regressions.
  • The second option, the one recommended by the Juju Core team, is that you specify the constraints to be more specific so that you get an m1.xlarge. In order to this, we need to find out what specific constraints you are using so that we can determine what to add to your constraints so that you get an m1.xlarge and only an m1.xlarge.

As far as to what Juju-supported mechanism for defining additional storage volumes:

We currently do not handle additional storage volumes, but is very much on the roadmap for this cycle. However there are many use cases for how to do storage volumes and we would like to know how you'd like to see this supported, so if you can post your requirements to the Juju mailing list you can help shape how the feature will be specced out.

Related bugs:

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.