Things I Thought I Knew

It's been a humbling week for me. Which is good because it means I'm learning things, but I will admit it would be nice to not find out I'm completely wrong about quite so many things in such a short span of time. I figured I would share what I've learned so it might be useful to someone else, because evidently it wasn't obvious to me.

First off, the following two statements are false (explanations to follow):

• /opt/stack is for development - nope
• The Python fixtures package is only for unit testing - also wrong

Corrected versions:
/opt/stack is a volatile location and devstack reserves the right to delete any changes you made there - This is, at least, the view of the people who are in charge of devstack. Their preferred workflow is to have your working git repositories hosted somewhere other than your devstack VM, and use the devstack git repo configuration to point it at those working repos to pick up your local changes.

The reasoning behind this is that a lot of people don't realize running stack.sh can, in some circumstances, do a git reset --hard of your git repos in /opt/stack. Having them stored permanently somewhere else eliminates this concern. Of course, it means that you've now got two repos to keep in sync and you have to re-pull or re-stack to have your changes take effect in devstack, on top of any necessary service restarts. Because of this, I'm probably going to stick with the unendorsed method of doing development in /opt/stack. I know git well enough to put my changes somewhere safe if I need to re-run stack.sh, which I don't normally do while in the middle of making changes to my local repos anyway. So I guess in the end I didn't actually learn anything, but at least now I know I'm off the map and here be dragons. :-)

For the curious, this all came out of the following discussion on openstack-dev: http://lists.openstack.org/pipermail/openstack-dev/2014-February/027819....

Fixtures can be used for a lot more than just unit tests - This misconception on my part came from the way we're currently using fixtures in all of the OpenStack projects I work on. Namely, they're only in unit tests. It turns out there's a whole bunch of non-unit-testy stuff that they can do as well that we apparently just aren't leveraging (buzzword bingo!) at the moment. I can't give any specific examples of other places they can be used (well, other than the link below), but I think it's worth noting anyway because if your only exposure to fixtures has been through OpenStack you might be under the same misconception I was.

This point brought to you by: https://review.openstack.org/#/c/78588/ (in which I make the incorrect assertion that fixtures are only for testing - consider this blog post my penance for that bit of ignorance :-)

Bonus points:
The OpenStack pypi mirror is not something I should be advertising widely - This one is extra credit because I kind of already knew that, but after I recommended someone switch their pip configuration to point at the OpenStack mirror (which I am pointedly not giving an address for, although you could probably figure it out if you try really, really hard) because shockingly they were having download problems from pypi, I was gently admonished that I oughtn't be doing that, at least without a big disclaimer, because it's a basically unsupported thing with no guaranteed capacity. Mind you, this unsupported thing still works infinitely better (not an exaggeration - I've never had a download failure from the OpenStack mirror, so mathematically speaking "infinitely" is accurate ;-) than the regular pypi mirrors. Plus it seems to be more squid friendly, so I spend less time downloading from any remote server and more time getting stuff done.

So yes, once again I'm largely going to ignore what I've learned and keep using the mirror, whether it's right or not. I guess the real takeaway from this post is that I'm a stubborn ass. At least now you know. :-)