* Fixed a bug related to Kerberos auth when using winrm with a domain account.
* Fixing several bugs in the s3 module.
* Fixed a bug with upstart service detection in the service module.
* Fixed several bugs with the user module when used on OSX.
* Fixed unicode handling in some module situations (assert and shell/command execution).
* Fixed a bug in redhat_subscription when using the activationkey parameter.
* Fixed a traceback in the gce module on EL6 distros when multiple pycrypto installations are available.
* Added support for PostgreSQL 9.4 in rds_param_group
* Several other minor fixes.
As always, this update is available via PyPi and releases.ansible.com now, and packages for distros will be available as soon as possible.
Back in June, we told you that Windows was coming. We’ve continued to improve the support, with the help of the outstanding Ansible community, and we’d like to highlight some of the improvements in Ansible 1.9. We now offer additional modules, support for domain authentication, and more.
For more information on Ansible’s Windows support, check out our Windows page, or our Ansible Intro to Windows documentation.
As always, we couldn’t do this without our outstanding Ansible community. Thanks to Chris Church, Jon Hawkesworth, Trond Hindenes, Peter Mounce, Chris Hoffman, Paul Durivage, and more!
By now you’ve probably seen or heard the news about Ravello Systems launching Inception—the ability to run nested VMware ESXi on AWS or GCE, including the ability to run VMs on these nested ESXi instances. (Here’s Ravello’s press release.)
In my opinion, this is pretty cool, and it opens the door to a lot of different possibilities: upgrade testing, automation testing, new feature testing, hosted home labs (aka “Lab as a Service”). Lots of folks are interested in using this new Ravello functionality for “Lab as a Service.” Here’s Andrea Mauro’s take on this topic.
As part of the pre-launch activities, a number of bloggers and community advocates were able to work with Ravello on some very interesting projects:
I was also engaged with Ravello on a project: building a (reasonably) large-scale vSphere environment on Ravello. The original goal was to Continue reading
Welcome to Technology Short Take #50, the latest in my series of posts sharing various links and articles pertaining to key data center technologies. I hope that you find something useful here!
In this post I’d like to share a couple of things I recently learned about the interaction between cloud-init and OpenStack Orchestration (aka “Heat”). This may be stuff that you already know, but in the interest of helping others who may not know I’m posting it here.
One issue that I’d been repeatedly running into was an apparent “failure” on the part of Heat to properly apply cloud-init configurations to deployed Ubuntu instances. So, using a Heat template with an OS::Nova::Server
resource defined like this would result in an instance that apparently wasn’t reachable via SSH (I’d get back Permission denied (publickey)
):
resources:
instance0:
type: OS::Nova::Server
properties:
name: cloud-init-test-01
image: { get_param: image_id }
flavor: m1.xsmall
networks:
- port: { get_resource: instance0_port0 }
key_name: lab
Deploying an instance manually from the same image worked perfectly. So what was the deal?
The first thing I learned was that, in some circumstances (more on this in a moment) defaults to injecting SSH keys (like the key named lab
specified in the template) to a user account named “ec2-user”. Ah! I’d been using the default “ubuntu” account specified in Continue reading
Most of you have probably picked up on the news of VMware’s new container-optimized Linux distribution, code-named “Photon”. (More details here.) In this post, I’m going to provide a very quick walkthrough on running Photon on VMware Fusion via Vagrant. This walkthrough will leverage a Vagrant box for Photon that has already been created.
To make things easier, I’ve added a photon
directory to my GitHub “learning-tools” repository. Feel free to pull those files down to make it easier to follow along.
I assume that you’ve already installed Vagrant, VMware Fusion, and the Vagrant plugin for VMware. If you haven’t, you’ll want to complete those tasks—and verify that everything is working as expected—before proceeding.
Install an additional Vagrant plugin that enables Vagrant to better detect and interact with Photon using this command:
vagrant plugin install vagrant-guests-photon
If you don’t install this plugin, you’ll likely get a non-fatal error about Vagrant being unable to perform the networking configuration. (Review the GitHub repository for this plugin if you want/need more details. Also, note that a PR against Vagrant to eliminate the need for this plugin was opened and merged; this fix should show up in a future release of Vagrant.)
In this post, I’ll build on a couple of previous posts and show you how to build your own Docker Swarm cluster that leverages etcd for cluster node discovery. This post builds on the information presented on how to run an etcd 2.0 cluster on Ubuntu as well as the information found in this post on running a Consul-backed Docker Swarm cluster.
To help you follow along, I’ve created a Vagrant environment that you can use to turn up the configuration described in this blog post. These files are found in the “docker-swarm-etcd” directory of my GitHub learning-tools repository. Feel free to use the files in this directory/repository to help with the learning process.
There are 3 major components to this configuration: