UPDATE: Friday 8th May 2015
Eucalyptus has fixed the only product issue we have found while using cfn-* tools on the on-premise cloud and the release is ready to be shipped out as 4.1.1
Eucalyptus officially released support for AWS Cloudformation back in 4.0.0 but with the latest release of Eucalyptus i.e. 4.1.0 this support is now out of tech preview mode. What this means for the cloud users is that they can use Cloudformation just like they use it on AWS and get official support from Eucalyptus for it. Yes our support is not just paid support but we have a very extensive community to help you get started or solve your problems.
When it comes to Cloudformation support in Eucalyptus the first thing that came to my mind was can I take one of the sample templates from AWS website and create a stack out of it on my Eucalyptus cloud. I don’t have to worry about the disclaimer put on the templates at AWS that says:
WARNING: This template creates one or more Amazon EC2 instances and an Elastic Load Balancer. You will be billed for the AWS resources used if you create a stack from this template.
Because I run my own AWS cloud in a Virtual Machine on my laptop.
As soon as I started looking at the templates on AWS I found that almost all of them were using the Cloudformation helper scripts in one way or the other. Obviously this was something I wanted to make sure works with my Eucalyptus cloud.
To my surprise everything works except one bug (https://eucalyptus.atlassian.net/browse/EUCA-10616) only.
To give you an example I share some of the command line snippets from the helper scripts:
Output from cfn-get-metadata against a Cloudformation endpoint on Eucalyptus:
/opt/aws/bin/cfn-get-metadata --stack WordPress --url \ https://cloudformation.cloud.jeevanullas.in --role adminrole \ --region eucalyptus --resource WebServer
Can be seen here
Similarly output from cfn-signal against a Cloudformation endpoint on Eucalyptus can be seen here
In the above output I used cfn-signal with a WaitCondition that had a WaitConditionHandle to signal creation of particular resource from the stack.
Of-course you cannot escape cfn-init the most powerful of all the helper script out there from AWS. As you can perhaps gather from the AWS documentation link.
In my case I used cfn-init against the AWS wordpress template that sets up the wordpress stack on Eucalyptus without any changes.
In order to get going I would highly encourage you to make sure service DNS names are enabled for your Eucalyptus cloud. By default the Eucalyptus installation uses IP addresses for the webservices endpoints but in order to work with the helper scripts you need DNS names for the services (EC2/Cloudformation/S3/IAM etc.)
Also please ensure you have a re-direct rule on your host (running Eucalyptus) that puts all traffic coming on port 443 to port 8773. This is mandatory because by default Eucalyptus webservices only listen on 8773 whether its HTTP or HTTPS. Again cloudformation helper scripts use HTTPS only with DNS names so you need to have this in place before proceeding.
Finally you need to have the region set for Eucalyptus cloudformation correctly because this is what the AWS Cloudformation template would eventually used.
All these 3 points I covered in my last blog post that is available here http://jeevanullas.in/blog/things-i-do-after-installing-eucalyptus/
Now coming back to the issues you would have to work around if you plan to run Cloudformation helper scripts from AWS against Eucalyptus.
a) Cloudformation helper scripts assume that the webservice endpoint is HTTPS. Not a bad assumption to make but in case of Eucalyptus running on a VM for only your own development purpose you might not have a SSL cert authorized with a known CA and you might still be using the self-signed certificate from Eucalyptus default installation. If that is the case you will have to disable SSL verification in the cloudformation helper script (unfortunately its not as simple as changing a config file):
/usr/lib/python2.6/site-packages/cfnbootstrap/util.py
As you have guessed already it’s the ‘verify’ that you would have to set to False.
Again running a production cloud on Eucalyptus, you should use a real SSL cert with your cloud. I covered it in my previous blog post http://jeevanullas.in/blog/things-i-do-after-installing-eucalyptus/
b) Cloudformation helper scripts grab detail about particular stack resource. The output from the webservice is a JSON that the script then parses and builds important structures. One of those parameters returned from the webservice is ‘LastUpdatedTimestamp’. Unfortunately the value for this parameter returned by Eucalyptus isn’t the same as returned by AWS Cloudformation. Clearly it’s a BUG in Eucalyptus which we are going to have to fix. More detail for the same here:
https://eucalyptus.atlassian.net/browse/EUCA-10616
The code used by cloudformation helper script is at
/usr/lib/python2.6/site-packages/cfnbootstrap/cfn_client.py
As can be seen from above the ‘LastUpdatedTimestamp’ coming from the webservice is then passed as an argument to datetime. Because the value returned by Eucalyptus is out of range an error is thrown out but for AWS it works.
Without spending much time on how I can fix this properly I decided to comment this line (Line 221) and get away with it. So far has not done much damage but I fully expect it to trigger some misbehaviour if you care about the last updated timestamp for that resource in the given stack to make some business decision.
Once I had fix this issue, I built an EMI with these changes and ensure all my templates uses it for the future use. As you have guessed it right, I had to add one more string in the official AWS templates for this to work:
"eucalyptus" : { "PV64" : "emi-1da38bb5", "HVM64" : "emi-1da38bb5", "HVMG2" : "NOT_SUPPORTED" },
You need to add the above in your AWSRegionArch2AMI section of the template.
That’s pretty much it. In case you experience any discrepancy other than these please do file a bug report in the system.
Happy Cloudformation on Eucalyptus without worrying about your AWS bills.