I’m trying to produce a simple list of instances on the fedora

openstack instance. I want to produce a list every 10m or so and diff

it against the last copy of that list and output the changes.

Here’s what I came up with:
http://fedorapeople.org/cgit/skvidal/public_git/scripts.git/tree/openstack/gather-diff-instances.py

it is based originally on nova-manage. It runs as root on the head system in our cloud and just dumps out json, then diffs the json.

Everything works but I’m trying to figure out if this is the ‘right’
way of going about this.
I thought about doing it via nova instead of using the nova-manage
direct-to-db api but I had 2 problems:

1. I would need to save the plaintext admin pw somewhere on disk to
poll for that info

2. or get a token which I would have to renew every 24 hours

We’re using the above the script as a simple cron job that lets us know
what things are changing in our cloud (who is bringing up new
instances, how many, what ips they are attaching to them, etc)

Additionally, is there a way in the db api to easily query the tenant and user info from keystone? I’d like to expand out the user uuid into username/project name.

 

 

gitproxy

March 22, 2013

gitproxy:
http://skvidal.fedorapeople.org/misc/gitproxy

Dealing with a potential problem we were trying to figure out a way to proxy/redirect git:// calls from one server to another one. This is a fairly ridiculous script I hacked up in the wee-small hours of thursday morning after talking to+Sitaram Chamarty on #git  for a while.

I fully expect this won’t work well under load but it does seem to function in my small tests here.

 

 

diffing two ini files

March 22, 2013

Ever need to diff 2 ini files but their sections and options aren’t in the right order?

Well, I do. I googled but I couldn’t find anything trivially available that did this.

I swear I wrote this once before but I couldn’t find it when I looked through my dirs of misc scripts so:

http://fedorapeople.org/cgit/skvidal/public_git/scripts.git/tree/inidiff

hope it is useful to someone.

A number of people have been surprised by this feature, even though it is documented, so I thought I’d mention it.

Ansible can run actions async. This means it connects to the client system, starts the process and disconnects.

In general you would want all your plays to be synchronous (do thing X, wait for it to be done/watch it, do thing Y).

However, there are times when what you want to do will take a VERY long time or could kill your ssh connection off.

An example is a yum update:

tasks:

– name: yum update

action: command yum -y update

That can take a long time, depending on what’s going on. You want to monitor what it does, but you don’t want a timeout or a reset ssh session/network to kill off that process.

So what do you do? You make it async:

tasks:

– name: yum update

action: command yum -y update

async: 7200

poll: 15

That means – run yum -y update – wait for up to 7200s and poll every 15s to check on the status of the action.

Here’s where we’re using it in fedora:

http://infrastructure.fedoraproject.org/cgit/ansible.git/tree/playbooks/package-update.yml#n11

However, this means if your ssh or network were to die – the yum update process would still run to completion.

But if your connection does die and you cannot check on the status of the job what do you do?

Well -you can connect to any system as the user who was running the job and look in ~/.ansible_async

there will be a file in there for each job that was being run. It may just be a place holder and empty (if the job is still running) or it made be filled with the results if the job is finished.

Pretty handy for a variety of tasks.