Tag: Infrastructure via Code

A Basic Template This first section on this page doesn’t add new elements to the script code, but implements a more complex template. Since this is user-supplied data, this is more of template example than a code update.

Overview Same configuration and userdata files as before Improved ’look’ of the code (applied code formatter) Some minor improvements to messages (output) Most importantly, created the get_named_resource function for common tasks like checking for the existence of an image (or other resource) and returning the matching image object (a munch.

Implementation We now add an important piece: write_files support. In this implementation we: Take a colon separated list of local directory names For each directory we process every file in the directory (last directory wins in the case of duplicates) Processing each file means: We determine the target path the for the file by stripping the passed in directory name (so passed/in/dir/etc/aliases becomes /etc/aliases) We read the file If possible we ‘gzip’ (compress) it We base64 encode it (this avoids problems with characters in the file being interpreted by cloud-init as having meaning other than being just data; for example it avoids quoting and whitespace issues).

Preface You’ll notice that the basic-instance.ini config file has two sections with erroneous server_groups. This was done to provide a quite test of the new script’s error-handling.

Preface It should be noted that these additions, combined with testing on a Windows workstation revealed a few errors in the previous version of script. These have been corrected as part of the enhancement process, in part because some new functionality requires the fixes.

Preface Our next phase was adding the configuration items we still needed, along with some enhancements on progress and error reporting. This is by no means a ‘product’, but it’s sufficient at this point (with the addition of userdata handling) for our small ‘cloud’ infrastructure.

ARCHIVED This collection of pages is archived and may contain out-of-date or no longer accurate information. Overview Learning experiments in using bespoke code & data under version control to consistently deploy virtual and bare metal hosts and the applications on them.

Preface Before finding the source of the issues with Terraform on OVH, a possible source of the dysfunction was thought to be with expired tokens. As such a couple of cross-platform token generation scripts using the Python bindings for the OVH API were tried.

Preface The OpenStack SDK is a OpenStack project aimed at providing a complete software development kit for the programs which make up the OpenStack community.

Preface Code The scripts described on this page are available in a Git repo @ https://github.com/danielfdickinson/ivc-in-the-wtg-experiments. First, Just a Template We start with a separate script that only generates userdata (no instance creation).

Preface Adding templating with the ability to add files to the instance and to run scripts during the instance deployment will get us most of the way to a complete solution for our needs, so that’s what this page is about.

Preface Some Thoughts At this point we should think about what is required to meet our Target Requirements. We’re going to put off a number of considerations as they depend on robust use of ‘userdata’ as we will be exploring the use of Jinja to template userdata later in the series.

Preface The Plan This page was intended to complete the OpenStack SDK with templated userdata portion of this Infrastructure Via Code set. This involves: Adding runcmd and bootcmd sections to userdata-default.