Skip to content

Instantly share code, notes, and snippets.


Matthew Micene nzwulfin

View GitHub Profile
View ansible directory scaffolding
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 Oct 3, 2016
Details for local atomic test VMs
View atomic vm notes
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 Sep 19, 2016
Manual test: synthetic upgrade and rollback target with ostree commit
View synthetic-upgrade-rollback
## 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 Sep 19, 2016
Issues with ref parent with rollback vs upgrade
View deploy -rollback-upgrade parents
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 Sep 16, 2016
Deploy previous version of atomic host to test upgrade / rollback
View gist:893e03fd44af9c79c80b646eec557c2d
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
View gist:08c2534aa8413803353e
docker run -it --name target centos:7
ansible-playbook -i vms site.yml
View git repos
import requests, os
api = GIT_API_URL + '/users/' + USER + '/repos?type=all'
def get_repos(url):
nzwulfin / local compser
Last active Feb 12, 2016
Working with the local compose for the ASC changes
View local compser
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 Jan 22, 2016
Not seeing IP address with user session guest on system default network
View virsh domifaddr
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 Aug 28, 2015
IRC discussion main points on things to be done
View Docs we need for
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