asgard
asgard copied to clipboard
Netflix
Support for launching instances with new General Purpose SSD EBS storage for root volumes
AWS have launched a new type of EBS, General Purpose SSD storage.
It appears currently with Asgard, even if the AMI is setup to use the new gp2 type EBS volumes, when launching a c3.xlarge instance with Asgard I get the error "Client.InvalidParameterCombination: Could not create volume with size 8GiB and iops 24 from snapshot 'snap-df0d1112'"
I have not dug into this yet, but I am guessing that Asgard is specifying some block device mappings here?
Digging into this further, this is not an issue with Asgard, it is an issue with Launch Configurations / Auto Scaling Groups not yet supporting the gp2 instances.
Reopening this, as EC2 now supports the gp2 volumes in Launch Configurations, but with no block device mappings set in the launch configurations the instances still fails to launch with the same error.
@zshenker Could you point me in the direction of any docs / other forums discussing this issue with launch configurations? We've run into the same issue and I'd like to get some more detail to see if we can work around it.
We're creating an AMI using the AWS APIs, which fails to launch using a scaling group + launch config, but which can be launched just fine through the AWS Console.
The error we get in the scaling group history is an unhelpful Cancelled state with the message: "Launching a new EC2 instance: xxx. Status Reason: Instance became unhealthy while waiting for instance to be in InService state."
But when you look at the instance that it spun up and then instantly terminated, it shows in its 'State transition reason': "Client.InvalidParameterCombination: Could not create volume with size 100GiB and iops 300 from snapshot 'snap-xxx'"
Which indicates we might have the same issue you're discussing here.
@zshenker could you post your working block device mapping here ? Would be great to use the new t2 family! Thanks!
@luketn Are you trying to launch instances with PIOPS volumes?
@maartenvanderhoef I have not yet been able to get instances with gp2 volumes working with Asgard.
I cannot currently see a way (with just configuration changes) to get Asgard to create a launch configuration that specifies a block device mapping for the root volume with a gp2 EBS volume. I have only been able to do this manually so far.
Is there something that I am missing? @claymccoy @joesondow
@zshenker you're not missing anything. We're looking to improve this story, but will not be adding this functionality to Asgard. All of our effort is dedicated to building the next Continuous Delivery/Deployment suite of tools, and that project is where we will be looking to bring these new features.
That said, if you're willing to put together a pull request, and can find somebody from the community to test it and validate it, we can merge the changes into our repo.
@zshenker No - it looks like the issue was we were had our launch config not specifying any parameters for the block devices (passing an empty array). I think this meant that it was taking an incorrect default set of settings when launching the AMI. Still looks like a bug to me but we may have a workaround.
@danveloper I'm curious to know more about the "next Continuous Delivery/Deployment suite of tools"? Is there any information about these tools out there in the wild today?
@aaronknister no, but there will be very soon. It's not that we're being secretive, it's that we're iterating rapidly, trying out brand new things, and failing quickly on those that don't work. Until recently, we wouldn't have a comprehensive story to tell. Now, we're getting to a point where we have some solid foundation, and we're nearing (and exceeding in some respects) feature parity with Asgard. As soon as that is done, we'll release all the info we can. In the meanwhile, I'd be happy to answer any conceptual questions, if you had any (ie. will the new tooling be a microservice suite?, etc).
@danveloper I'm particularly interested to know if the new product will be easily adaptable to support other cloud infrastructure providers.
The platform that we're building will be inherently extensible due to our need to support more robust delivery pipelines, like for CDN deployments, which utilize other cloud providers.