Thursday, 23 July 2015

Virtualenv and library fun

Doing python development means using virtualenv, which is wonderful.  Still, sometimes you find a gotcha that trips you up.

Today, for whatever reason, inside a venv inside a brand new Ubuntu 14.04 install,  I could not see a system-wide install of pywsman (installed via sudo apt-get install python-openwsman)

For example:
mrda@host:~$ python -c 'import pywsman'
# Works

mrda@host:~$ tox -evenv --notest
(venv)mrda@host:~$ python -c 'import pywsman'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: No module named pywsman
# WAT?

Let's try something else that's installed system-wide
(venv)mrda@host:~$ python -c 'import six'
# Works

Why does six work, and pywsman not?
(venv)mrda@host:~$ ls -la /usr/lib/python2.7/dist-packages/six*
-rw-r--r-- 1 root root  1418 Mar 26 22:57 /usr/lib/python2.7/dist-packages/six-1.5.2.egg-info
-rw-r--r-- 1 root root 22857 Jan  6  2014 /usr/lib/python2.7/dist-packages/
-rw-r--r-- 1 root root 22317 Jul 23 07:23 /usr/lib/python2.7/dist-packages/six.pyc
(venv)mrda@host:~$ ls -la /usr/lib/python2.7/dist-packages/*pywsman*
-rw-r--r-- 1 root root  80590 Jun 16  2014 /usr/lib/python2.7/dist-packages/
-rw-r--r-- 1 root root 293680 Jun 16  2014 /usr/lib/python2.7/dist-packages/

The only thing that comes to mind is that pywsman wraps a .so

A work-around is to tell venv that it should use the system-wide install of pywsman, like this:

# Kill the old venv first
(venv)mrda@host:~$ deactivate
mrda@host:~$ rm -rf .tox/venv

Now startover
mrda@host:~$ tox -evenv --notest --sitepackages pywsman
(venv)mrda@host:~$ python -c "import pywsman"
# Fun and Profit!

Wednesday, 22 July 2015


I've put together a little test network at home for doing some Ironic testing on hardware using NUCs.  So far it's going quite well, although one problem that had me stumped for a while was getting the NUC to behave itself when obtaining an IP address with DHCP.

Each time I booted the network, a different IP address from the pool was being allocated (i.e. the next one in the DHCP address pool).

There's already a documented problem with isc-dhcp-server for devices where the BMC and host share a NIC (including the same MAC address), but this was even worse because on closer examination a different Client UID is being presented as part of the DHCPDISCOVER for the node each time. (Fortunately the NUC's BMC doesn't do this as well).

So I couldn't really find a solution online, but the answer was there all the time in the man page - there's a cute little option "ignore-client-uids true;" that ensures only the MAC address is used for DHCP lease matching, and not Client UID.  Turning this on means now that on each deploy the NUC receives the same IP address - and not just for the node, but also for the BMC - it works around the aforementioned bug as well.  Woohoo!

There's still one remaining problem, I can't seem to get a fixed IP address returned in the DHCPOFFER, I have to configure a dynamic pool instead (which is fine because this is a test network with limited nodes in it).  One to resolve another day...

Tuesday, 28 April 2015

OpenStack Hint of the Day: Wed Apr 29

When running tox and you get something like this:

mrda@garner:~/src/python-ironicclient (review/michael_davies/file-caching)$ tox -e py34
py34 runtests: PYTHONHASHSEED='3098345924'
py34 runtests: commands[0] | python testr --slowest --testr-args=
running testr
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} ${PYTHON:-python} -m discover -t ./ ${OS_TEST_PATH:-./ironicclient/tests/unit}  --list 
db type could not be determined
error: testr failed (3)
ERROR: InvocationError: '/home/mrda/src/python-ironicclient/.tox/py34/bin/python testr --slowest --testr-args='
________________________________________________________________________________________________ summary _________________________________________________________________________________________________
ERROR:   py34: commands failed

The solution is to "rm -rf .testrepository/" and try again.

(Thanks to this little reference hidden away

Thursday, 20 November 2014

Playing with the network

I'm in the position of needing to improve my internet connectivity, so one of the first steps is to decouple all the things that provide the services I rely upon.

Stage one is to turn my modem into just an ADSL endpoint, removing any DHCP, NAT, and PPPoE termination from the device so that it has a single function.

Fortunately my nb604n ADSL modem has a nice easy-to-follow guide for taking it into bridge mode:

Now onto greater things!

Saturday, 5 July 2014

LCA2015 CFP Closing Real Soon Now

It's July, which means the LCA2015 CFP is open... but not for much longer.

I've been reading through what's been submitted so far, and it looks like will again have an excellent program.  But, as Co-Chair of the Papers Committee, I want the program to be even better! :-)

So if you're working on a open-source or open-hardware project, and you're doing cool stuff, why not come to Auckland in January and speak at one of the best community-driven open-source conferences in the world?  We've got some great information on how to get your proposal accepted (also in video) to help you put your proposal together.

But to be a speaker at LCA2015 you need to make a proposal to speak to the CFP (which closes next Friday Sunday on July 13).  So hurry up, and submit your proposal today!

Sunday, 25 May 2014

OpenStack Summit Keysigning

It's been a while since I've gone to a GPG keysigning, but at the Juno OpenStack Summit in Atlanta I joined in.  After all, it was my first summit and getting some id authentication is worthwhile.

After the keysigning party I made use of caff to sign all those keys.  But of course I needed to configure SMTP first in my development VM.  There's a nice guide to getting postfix working with gmail which helped that go quickly.  Just remember that gmail likes Application-specific passwords nowadays.

Oh, and another thing.  GPG has awful error messages.  When you receive your key signed by a third-party and you try to gpg --import it and you get the dreaded:

$ gpg --import your-signed-key.asc 
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0
$ file your-signed-key.asc 
your-signed-key.asc: PGP message

...remember that the key has probably been encrypted with your public key so only you can read it.  The way around this is a simple:

$ gpg --decrypt your-signed-key.asc | gpg --import

Things would be mush easier if gnupg provided suggestions, but life often isn't that easy :)

Saturday, 18 January 2014

LCA TV: More fun at 2014

LCA2014 was a whole lot of fun, for so many reasons!  One thing I love is talking with people from all over the Free and Open Source community from around the world - meeting new people doing exciting things, as well as catching up with those who have become dear friends from years of shared experiences.

This year James Bromberger had a wonderful idea: LCA TV.  How about we interview people on the couch and broadcast these casual chats live alongside the conference video streams?  A kind of free software equivalent of David Letterman or Steve Vizard.  This fantastic new thing allowed me to combine a few of my favourite things together, and allow others to get to know some of the conference attendees in a more casual setting.

So, how did it go?  It went off like a bang, and despite having a few technical challenges, I think this 'experiment' was a raving success, and hopefully the start of yet another LCA tradition!

The result of these videos are now available over on youtube: and will soon also appear on the LCA mirror.