To make the AARCH64 ipxe process work using bifrost, I had to
git clone https://github.com/ipxe/ipxe.git
make bin-arm64-efi/snponly.efi ARCH=arm64
sudo cp bin-arm64-efi/snponly.efi /var/lib/tftpboot/ipxe.efi
This works for the Ampere reference implementation servers that use a Mellanox network interface card, which supports (only) snp.
(With apologies to Bergman and Legrand)
I need to modify how the ipxe container mounts directories. Why? AARCH64 iPXE stuff. Specifically, I need to get my own version of a file into the directory that a container mounts when it is running. How do I do that? I don’t know yet, so I am going to look.
I am constantly creating and deleting virtual machines. These virtual machines often are RHEL systems, and need to be registered with Red Hat’s CDN. While In the past I had a Role that was wrapped into other provisioning playbooks to perform this task, I find that there are enough one-offs to make it useful to do this as a stand alone playbook. Here is how I set it up, including my rational.
“Let the complexity emerge.” Probably the best advice I ever got in coding. Do something in as straight-forward manner as possible. When you find your self repeating code, extract it. Here’s an example from an ansible playbook I’m working on.
After some discussion with Bill Nottingham I got a little further along with what it would take to integrate Ansible Tower and FreeIPA. Here are the notes from that talk.
Ansible is a workflow engine. I use it to do work on my behalf.
FreeIPA is an identity management system. It allows me to manage the identities of users in my organization
How do I get the two things to work together? The short answer is that it is trivial to do using Ansible Engine. It is harder to do using Ansible tower.
Edit: Second part is here. Third part is coming.
Me. Us. Them.
The story I tell when I explain the various offereings that Red Hat has based on Ansible follow is based on the progression of Me. Us. Them.
Me: Get my playbook working for me on my workstation. For this, I use Ansible Engine.
Us: Share my playbook with my larger team. For this, I use Ansible Tower.
Them: Make a Self service catalog for the larger organization to consume. This is where Ansible integration into other products comes in to play. I typically talk about CloudForms integration here, but Satellite and OpenShift are also capable of making use of Ansible here.
Here is how I have my local setup for doing Ansible based development. This is organized roughly around how Tower will later consume the roles and playbooks I design here.
Ansible exists to help automate the time consuming repeated tasks that technologist depend upon. One very common jobs is to create and tear down a virtual machine. While cloud technologies have made this possible to perform remotely, there are many times when I’ve needed to setup and tear down virtual machines on systems that were stand alone Linux servers. In this case, the main interfaces to the machine are ssh and libvirt. I recently worked through an Ansible role to setup and tear down an virtual machine via libvirt, and I’d like to walk through it, and record my reasons for some of the decisions I made.
Now that we can use the REST API to list inventory, it is not a big stretch to decide we want to kick off Jobs, too. Here it is in a nutshell, and some related operations for working with jobs and templates.
In an earlier post, I wrote about using the OpenStack Ansible inventory helper when calling and Ansible command line tools. However, When developing an playbook, often there is more information pulled from the inventory than just the set of hosts. Often, the inventory also collects variables that are used in common across multiple playbooks. For this reason, and many more, I want to be able to call an Ansible playbook or Ad-Hoc command from the command line, but use the inventory as defined by an Ansible Tower instance. It turns out this is fairly simple to do, using the REST API.