Next ssh into the instance, and proceed to follow the steps for setting up the Stackato instance that is mentioned in my previous blog under the section Configuration of the Stackato Instance. Make sure the DNS name setup in AWS Route 53 is used with “kato rename public-DNS-name” and “kato setup core api.public-DNS-name” configuration steps.
You may be forgiven for thinking that a version 1.0 software release indicates some sort of significant milestone for the lifecycle of a project. Perhaps in many cases it does but with Ansible, not so much. Michael DeHaan articulates it much better than I could in this post to the project mailing list. My personal experience from using Ansible since v0.8 is that each release delivers consistency, quality and increased flexibility. It’s great to see fast releases delivering something which is incrementally more useful and enjoyable to use. There’s always new handy stuff in each release.
For those using AWS and Eucalyptus, Ansible 1.0 is a perfect example of incremental AWSomeness (geddit?!). Along with a host of other improvements it delivers the following for AWS/Eucalyptus users:
An updated ec2 module; ported to boto by our very own tgerla and now with the capability to launch multiple instances. It works a treat and now you can deploy many instances and configure them all with simple plays. This brings direct dependencies of boto and m2crypt but looses the dependency of euca2ools. Huge thanks to skvidal here for his counsel.
A new ec2_facts module written by silviud, this pulls the same information that facter would from an instance (basically all the metadata). Advantage being re-use of the facts in a playbook and of course not requiring facter and its ruby dependencies to be installed in the instance.
Better still, ec2-related stuff in Ansible is becoming even more popular. Just recently the module was again updated to support tagging (although this won’t be out-of-the-box until 1.1)!