TripleO / Ironic Meetup in Sunnyvale

Last week a group of developers working on the OpenStack projects TripleO and Ironic convened in the sunny vale of Sunnyvale for a mid-cycle meetup.

Yahoo! Sunnyvale Campus

My focus was primarily on Ironic, though lots of discussion about TripleO happened. (Here is some Tuskar documentation, for example.) I thought it would be worthwhile to quickly summarize my experiences:

  • About 40 people turned out, including some really bright folks from HP, Yahoo!, Mirantis, Rackspace, and Red Hat. (And surely some others that I’ve temporarily forgotten—sorry!) Just meeting everyone I’ve been working with online was pretty valuable.
  • A whole ton of patches got rapidly tested and merged, since sitting in the same room instead of being on separate continents made it much more efficient. In fact, a lot of patches got written and merged.
  • We hit feature freeze Tuesday. On Monday, -2’s were given to bigger patches to ensure that we had time to review everything. The -2 will be lifted once development for Juno opens up. Some of the things bumped include:
  • Because of feature freeze across projects, the Ironic driver for Nova was temporarily copied into Ironic’s source tree so we can work on it there.
  • Described in the same email linked above, a lot of work went into extending CI coverage for Ironic though it hasn’t yet landed. This test integration will be necessary to graduate from incubation.
  • We also identified end-user documentation as an important task, one which is both required to graduate incubation and as something that can be done during feature freeze in addition to bugfixes. This Etherpad tries to outline what’s required.
  • A lot of whiteboarding was done around a ramdisk agent for Ironic. The idea is that nodes can boot up a richer agent to support more advanced configuration and lifecycle management. The link here goes to the introduction of a pretty interesting thread.

Fixing Alembic error with multiple heads

Today I went to run automated tests in my Ironic development setup, and tests failed with a slew of errors like this:

CommandError: Only a single head is supported. The script
 directory has multiple heads (due to branching), which must be 
 resolved by manually editing the revision files to form a linear 
 sequence. Run `alembic branches` to see the divergence(s).

This was quite baffling to me, and I at first assumed it was a git thing, given the references to branches and head.

I am still moderately confused. But here is how I fixed it.

Please note that: * I have little idea what I’m doing. This is what worked for me, not necessarily what someone clueful would do. * My fix involves trashing your database and recreating it. That’s perfectly acceptable for my test database, but proceed with caution.

Run alembic branches

The error told me to run alembic branches, but that failed:

$ alembic branches
  No config file 'alembic.ini' found, or file
  has no '[alembic]' section

The solution is to find your alembic.ini file. In Ironic, that’s ironic/db/sqlalchemy. cd into there, and now it will work:

$ alembic branches
None -> 2581ebaf0cb2 (branchpoint), initial migration
     -> 2581ebaf0cb2 -> 21b7629c61e7 (head), 
     -> 2581ebaf0cb2 -> 21b331f883ef (head), Add provision_updated_at

The alembic documentation talks a little bit about this, for further reading.

Look for .pyc files

Each of those hashes should point to a Python file in alembic/versions/.

I think where I went wrong is that I had switched branches and ended up with a .pyc file, but not matching .py. The name should match one of the hashes above. (I suppose you could safely just delete all the .pyc files, actually.)

Downgrade to alembic base

I’m actually not sure if this was necessary, but I did this: alembic downgrade base. If it bombs out with errors, I think we’ll fix them momentarily.

Delete the tables from your database

Now we’re basically going to start a new database.

I fired up mysql, ran USE ironic, and then deleted all the tables. You might have to play with ordering to get it right, due ot foreign key constraints.

Re-run alembic

In Ironic, we have ironic-dbsync to do this for us. If not using Ironic, I think alembic upgrade head is analogous.

And then you should be good. Hopefully.