Skip to content

Instantly share code, notes, and snippets.

Ansible scaffolding for project, created in root of project directory
$ ansible-galaxy init ansible
$ mkdir -p ansible/playbooks/groups ansible/playbooks/hosts ansible/roles
Create the base role for the project for all common tasks
$ ansible-galaxy init -p ansible/roles/base
Project should now have TLD of ansible that holds the playbooks and roles
nzwulfin / atomic vm notes
Created October 3, 2016 14:10
Details for local atomic test VMs
Tunir VM
Create F23 virtual machine (2G, 2vC, 10G)
u: tunir / p: Ap
git clone
install python-paramiko python-sqlalchemy python-redis redis python-libcloud
redis (no config, start / enable)
git clone
fedora to remote
cp fedora.txt .json ~/tunir
* curl -O
nzwulfin / synthetic-upgrade-rollback
Created September 19, 2016 18:25
Manual test: synthetic upgrade and rollback target with ostree commit
## Set up new branch based on existing tree and deploy
sudo ostree commit -b synthetic_test --tree=ref=fedora-atomic:fedora-atomic/24/x86_64/docker-host | tee target_commit.txt
sudo ostree admin deploy synthetic_test
sudo systemctl reboot
atomic host status
<active commit == target_commit.txt>
## Create a 'noop' commit based on the new branch as an upgrade target
sudo ostree commit -b synthetic_test --tree=ref=synthetic_test | tee target_upgrade.txt
sudo atomic host upgrade
nzwulfin / deploy -rollback-upgrade parents
Created September 19, 2016 15:01
Issues with ref parent with rollback vs upgrade
I chatted with miabbott on IRC to find the right `ostree rev-parse` syntax to find the parent of the current deployment:
`ostree rev-parse fedora-atomic/24/x86_64/docker-host^`
This would allow the test case to find the previous tree to deploy to test rollbacks and upgrades.
Building test cases for Tunir, I wanted to see what the error output would be for the very first tree in a release cycle (i.e. Fedora 24) so the test case wouldn't try to rollback to something that didn't exist.
After updating to the current tree (24.45) I then deployed 24, and rebooted. Once on 24, I rolled back to 24.45. The oddness happened here. I tried the `ostree rev-parse` command on this rolled back 24.45 and it threw the error as if the tree was still 24.
If I ran an upgrade from 24 to 24.45, the `ostree rev-parse` worked as expected and showed the parent, 24.44.
nzwulfin / gist:893e03fd44af9c79c80b646eec557c2d
Created September 16, 2016 18:02
Deploy previous version of atomic host to test upgrade / rollback
sudo atomic host status
sudo atomic host deploy $(ostree rev-parse fedora-atomic/24/x86_64/docker-host^)
sudo systemctl reboot
sudo atomic host status
docker run -it --name target centos:7
ansible-playbook -i vms site.yml
import requests, os
api = GIT_API_URL + '/users/' + USER + '/repos?type=all'
def get_repos(url):
nzwulfin / local compser
Last active February 12, 2016 16:11
Working with the local compose for the ASC changes
rpm-ostree compose tree --proxy= --repo=/srv/rpm-ostree/fedora-atomic/23 fedora-atomic-docker-host.json
sudo ostree remote add atomic-storage-clients --no-gpg-verify
sudo atomic host rebase atomic-storage-clients:fedora-atomic/rawhide/x86_64/docker-host
CEPH (on ceph-admin):
mkdir test-cluster && cd test-cluster
ceph-deploy new ceph-server-1 ceph-server-2 ceph-server-3
nzwulfin / virsh domifaddr
Created January 22, 2016 15:47
Not seeing IP address with user session guest on system default network
Expiry Time MAC address Protocol IP address Hostname Client ID or DUID
2016-01-22 11:20:50 52:54:00:8f:f2:d5 ipv4 composer ff:00:8f:f2:d5:00:01:00:01:1e:04:85:9c:52:54:00:8f:f2:d5
2016-01-22 11:36:10 52:54:00:b9:5e:96 ipv4 atomic-001 ff:00:b9:5e:96:00:01:00:01:1e:34:fb:ee:52:54:00:b9:5e:96
sudo virsh domifaddr fedora23-composer
Name MAC address Protocol Address
nzwulfin / Docs we need for
Created August 28, 2015 17:39
IRC discussion main points on things to be done
13:17:45 < nzwulfin> we could ship an example...
13:18:32 < jbrooks> I think that'd be handy, worth talking about, I know I've made them before w/ a change pw on first login req
13:19:31 < nzwulfin> yeah we can try to set some sane defaults, but as a "if you really can't get this step, just go here"
13:19:36 < nzwulfin> safety net
13:20:52 < jbrooks> Another thing could be where we list the different types of install media we have available, each could link
to a brief getting started w/ that media type
13:21:13 < nzwulfin> yeah i started down that path originally when i was thinking about it .. one per provider
13:21:23 < jbrooks> iso, qcow (byo cloud-init or not), vagrant
13:21:39 < nzwulfin> part of what i get hung up on is .. how much do we expect someone to know about the provider
13:22:22 < jbrooks> We should do one for ec2, too