You’ve decided that using sudo to run command lines as root is lame and that it is time to step up and do things properly. How do you do that? Well, here’s a simple guide to adding oslo privsep to your project!
Once you’ve added oslo privsep to your project, how do you make a privileged call? Its actually really easy to do. In this post I will assume you already have privsep running for your project, which at the time of writing limits you to OpenStack Nova in the OpenStack universe.
I have reached the point in my life where I needed to write my first program in golang. I pondered for a disturbingly long time what exactly to write, but then it came to me... Back in the day Google had an internal short URL service (think bit.ly, but for internal things). It was called "go" and lived at http://go. So what should I write as my first golang program? go of course. The implementation is on github, and I am sure it isn't perfect. Remember, it was a learning exercise. I mostly learned that golang syntax is a bit bonkers, and that etcd hates me. This code stores short URLs in etcd, and redirects you to the right place if it knows about the short code you used. If you just ask for the root URL, you get a list of the currently defined short codes, as well as a form to create new ones. Not bad for a few hours hacking I think.
Just noting this because it wasted way more of my time that it should have... So you write an etcd app in a different language from your previous apps and it can't see the data that the other apps wrote? Check the versions of your client libraries. The v2 and v3 data stores in etcd are different, and cannot be seen by each other. You need to convert your v2 data to the v3 data store before it will be visible there. You're welcome.
The pyconau call for proposals is now open, and runs until 28 May. I took my teenagers to pyconau last year and they greatly enjoyed it. I hadn't been to a pyconau in ages, and ended up really enjoying thinking about things from topic areas I don't normally need to think about. I think expanding one's horizons is generally a good idea. Should I propose something for this year? I am unsure. Some random ideas that immediately spring to mind: something about privsep: I think a generalised way to make privileged calls in unprivileged code is quite interesting, especially in a language which is often used for systems management and integration tasks. That said, perhaps its too OpenStacky given how disinterested in OpenStack talks most python people seem to be. nova-warts: for a long time my hobby has been cleaning up historical mistakes made in OpenStack Nova that wont ever rate as a major feature change. What lessons can other projects learn from a well funded and heavily staffed project that still thought that exec() was a great way to do important work? There's definitely an overlap with the privsep talk above, but this would be more general. a talk…
This is the second book in the Leviathan Wakes series by James SA Corey. Just as good as the first, this is a story about how much a father loves his daughter, moral choices, and politics -- just as much as it is the continuation of the story arc around the alien visitor. I haven't seen this far in the Netflix series, but I sure hope they get this right, because its a very good story so far.
I registered for city2surf this morning, which will be the third time I've run in the event. In 2016 my employer sponsored a bunch of us to enter, and I ran the course in 86 minutes and 54 seconds. 2017 was a bit more exciting, because in hindsight I did the final part of my training and the race itself with a torn achilles tendon. Regardless, I finished the course in 79 minutes and 39 seconds -- a 7 minute and 16 second improvement despite the injury. This year I've done a few things differently -- I've started training much earlier, mostly as a side effect to recovering from the achilles injury; and secondly I've decided to try and raise some money for charity during the run. Specifically, I'm raising money for the Black Dog Institute. They were selected because I've struggled with depression on and off over my adult life, and that's especially true for the last twelve months or so. I figure that raising money for a resource that I've found personally useful makes a lot of sense. I'd love for you to donate to the Black Dog Institute, but I understand that's not always possible. Either way,…
Aptira is in an interesting position in the Open Source market, because we don’t usually sell software. Instead, our customers come to us seeking assistance with deciding which OpenStack to use, or how to embed ONAP into their nationwide networks, or how to move their legacy networks to the software defined future. Therefore, our most common role is as a trusted advisor to help our customers decide which Open Source products to buy. (My boss would insist that I point out here that we do customisation of Open Source for our customers, and have assisted many in the past with deploying pure upstream solutions. Basically, we do what is the right fit for the customer, and aren’t obsessed with fitting customers into pre-defined moulds that suit our partners.) That makes it important that we recommend products from companies that are well engaged with their upstream Open Source communities. That might be OpenStack, or ONAP, or even something like Open Daylight. This raises the obvious question – what makes a company well engaged with an upstream project? Read more over at my employer's blog...
Lifehacker kindly pointed out that the Hugo nominees are out for 2018. They are: The Collapsing Empire, by John Scalzi. I've read this one and liked it. New York 2140, by Kim Stanley Robinson. I've had a difficult time with Kim's work in the past, but perhaps I'll one day read this. Provenance, by Ann Leckie. I liked Ancillary Justice, but failed to fully read the sequel, so I guess we'll wait and see on this one. Raven Stratagem, by Yoon Ha Lee. I know nothing! Six Wakes, by Mur Lafferty. Again, I know nothing about this book or this author. So a few there to consider in the future.
Mocking is a pretty common thing to do in unit tests covering OpenStack Nova code. Over the years we've used various mock libraries to do that, with the flavor de jour being unittest.mock. I must say that I strongly prefer unittest.mock to the old mox code we used to write, but I think I just accidentally found a fairly big bug. The problem is that python mocks are magical. Its an object where you can call any method name, and the mock will happily pretend it has that method, and return None. You can then later ask what "methods" were called on the mock. However, you use the same mock object later to make assertions about what was called. Herein is the problem -- the mock object doesn't know if you're the code under test, or the code that's making assertions. So, if you fat finger the assertion in your test code, the assertion will just quietly map to a non-existent method which returns None, and your code will pass. Here's an example: #!/usr/bin/python3 from unittest import mock class foo(object): def dummy(a, b): return a + b @mock.patch.object(foo, 'dummy') def call_dummy(mock_dummy): f = foo() f.dummy(1, 2) print('Asserting a call should…