ed – Page 24 – Walking Contradiction

Ride to the River 2016

The Valero Ride to the River is a two-day cycling event to raise money for research for a cure for Multiple Sclerosis. This was the third time I’ve ridden in it, but what made this year different is that this is the first time that Mother Nature didn’t completely wash out one of the days. We had gorgeous weather, with temperatures cool in the morning, and only climbing to the low 80sF (around 25-27C) in the afternoon.

Starting off on Day 1 (that’s me in the bright green)

The ride starts in San Antonio, and wanders east and north until it reaches New Braunfels. This route is about 71 miles, but near the end there is a choice: turn left, and finish your ride. Or, you can turn right, and go up the Guadalupe River for 15 miles, turn around, and return back, making the total ride 100 miles. As I had done a full century on my last ride, I didn’t feel the need to push myself to prove anything. I had told everyone that I was only doing the 71. But as the ride progressed, I continued to feel fresh. This was most likely due to the very mild weather: temperatures never rose very high, and there were enough clouds so that you weren’t baking in the sun the entire time. By the time I reached the lunch rest stop (50 miles in), I started thinking seriously about going for the century, but I told my wife I’d wait until the last rest stop before the decision point.

When I reached that stop, at around mile 65, I knew that I wanted to do the full century. I remembered the only other time that I did this course, and what a struggle those last 30 miles were, so I braced myself for the ride. I was very surprised to find that, while definitely an effort, it was nowhere near as exhausting as it had been the previous time. Either they smoothed the hills out, or I was in much better shape! ? So while I didn’t set any speed records, I finished the century much easier than my previous two. Here’s the record of my ride, thanks to the Runkeeper app.

Enjoying a well-deserved beer after completing the century!

My well-earned Century Rider armband. — My Century Rider armband.

The next day offered a choice of two looping routes: 61 miles or 38 miles through the Texas Hill Country. I had done the 61 mile route a couple of years ago, and remembered how grueling the hills were on that ride, so I chose to only do the 38. For comparison, the route for Day 1 was through areas to the east of San Antonio, which is relatively flat. I had about 4,300′ of total climb (43 ft/mile). This route took us to the northwest of New Braunfels, which is much hillier by far. The total climb was about 2,700′, or over 71 ft/mile! And as you can see from the graph below, most of that climb was in the first half of the ride. There isn’t much else to say about the Day 2 ride. The weather was once again perfect, and while the ride was difficult at times, it felt good overall. Here’s the Runkeeper summary for Day 2.

Of course, I can’t take all the credit. The ride was extremely well-organized by the MS Society, with well-staffed rest stops every 12-15 miles. They also arranged for police support for traffic management, so that riders didn’t get stuck (or struck!) at busy intersections. My belated apologies to the drivers who were made to wait while 2,000 riders passed through!

I also don’t think I would have been able to accomplish this without the loving support of my wife Linda, who gives me the motivation to stay healthy so that I can live a long life with her! Three years ago I thought it was a pretty amazing accomplishment to complete a century at age 55, but now to have done two centuries this year at age 58 is really more than I ever expected to achieve, and I have Linda to thank for that.

Pair Development

If you’ve worked on large open source projects, one of the difficulties is dividing the workload. The goal, of course, is to spread it out so that every developer has a workload that will keep them busy, and everyone is working in sync towards a common goal. This isn’t easy in practice, as there is no top-down authority to hand out assignments and keep everyone on track, as there is in a corporate development environment. It requires a good deal of communication among the members of the team, as well as a good deal of trust.

This problem was brought to light recently in the Nova community. The issue was with the subteam working on the scheduler/placement engine, of which I’m a member. During the Newton development cycle, there was a significant bottleneck due to the fact that one person, Chris Dent, was responsible for a large chunk of work in designing and coding the Placement API and underlying engine, while the rest of us could only help by doing reviews after the code was written. And this isn’t a new thing: during Mitaka, it was Jay Pipes who was the bottleneck with the development of the Resource Providers concept, and in Liberty, it was Sylvain Bauza with the huge amount of work he did to integrate the Request Spec into Nova. Don’t get me wrong: I’m not criticizing any of these people, as they all did great work. Rather, I am expressing frustration that they bore the brunt of the load, when it didn’t have to be that way. I think that it is time to try a different approach in Ocata.

I propose that we use Pair Development. No, not Pair Programming – that’s an entirely different thing. Pair Development is when each “chunk” of work is not undertaken by a single developer, but rather to two. They discuss the path they want to take ahead of time, and instead of splitting the work, they both work on the same patches at the same time. Wait, you say – won’t this slow things down? I don’t believe that it will, for several reasons. First, when discussing a design, having multiple sets of eyes will reduce the number of dead ends, in the same way that bugs are reduced in pair programming by having both developers review the code as it is being written. Second, when a reviewer finds an issue with a patch, either developer can make the fix. This is an even greater benefit if the two developers are in different, but overlapping, time zones.

We also have as evidence the week before the most recent Feature Freeze: the placement stuff needed to get in before FF, and so a whole group of us pulled together to make that happen. Having a diverse set of eyes uncovered several edge cases and inconsistencies in the code, and those were resolved pretty quickly. We used IRC mostly, but had a Google Hangout at least once a day to discuss any outstanding, unresolved matters, so that we would all be on the same page. So yeah, the time pressure helped instill a bit of urgency in us all, but I think that it was having all of us own the code, not just Chris, that made things happen as well as they did. I know that I was familiar with the code, having reviewed much of it before, but now that I had to change it and test it myself, my understanding grew much deeper. It’s amazing how deeper you understand something when you touch it instead of just look at it.

Another benefit of pair development is that it provides much more continuity when one of the developers takes some time off. Instead of the progress getting put on hold, the other member of the development pair can continue along. It will also help to have more than one person know the new code intimately, so that when a behavior surfaces that is not expected, we aren’t depending on a single person to figure out what’s going on.

So for Ocata, let’s figure out the tasks, and make sure that each has two people assigned to it. I will wager that come the end of the cycle, it will help us accomplish much more than we have in previous releases.

Changing WordPress Permalinks

When I started this blog a few years ago, I hadn’t used WordPress before, and went with the defaults pretty much everywhere. The one that bothered me, though, was the default format for permalinks: http://example.com/?p=123. That’s just plain ugly. The problem, though, is somewhere along the line I messed up, and ended up with long, unwieldy permalinks like: http://blog.leafe.com/index.php/2016/08/08/on_swift/. I’ve been wanting to switch to something cleaner for a while, but I didn’t want to break all of the existing links that I’ve shared. So I kept the long format.

I finally got sick enough of looking at those terrible URIs and started searching to see if anyone had run into the same issue, and, as expected, I was not along. I found the Change Permalink Helper Wordpress plugin by Frank Bueltge, installed it, and I was done! Simple! That ugly URL above is now http://blog.leafe.com/on_swift/, but the old one still works.

Thanks, Frank, for a nifty little plugin that made my blogging life easier!

Is Swift OpenStack?

There has been some discussion recently on the OpenStack Technical Committee about adding Golang as a “supported” language within OpenStack. This arose because the Swift project had recently run into some serious performance issues, which they solved by re-writing the bottleneck process in Golang with much success. I’m not writing here to debate the merits of making OpenStack more polyglot (it’s no secret that I oppose that), but instead, I want to address the issue of Swift not behaving like the rest of OpenStack.

Doug Hellman summarized this feeling well, originally writing it in a pastebin, but then copying it into a review comment on the TC proposal. Essentially, it says that while Swift makes some efforts to do things the “OpenStack Way”, it doesn’t hesitate to follow its own preferences when it chooses to.

I believe that there is good reason for this, and I think that people either don’t know or forget a lot of the history of OpenStack when they discuss Swift. Here’s some background to clarify:

Back in the late ’00s, Rackspace had a budding public cloud business (note: I worked for Rackspace from 2008-2014). It had bought Slicehost, a company with a closed-source VPS system that it used as the basis for its Cloud Servers product, and had developed a proprietary object storage system called NAST (Not Another S Three: S3, get it?). They began hitting limits with NAST fairly soon – it was simply too slow. So it was decided to write a new system with scalability in mind that would perform orders of magnitude better than NAST; this was named ‘Swift’ (for obvious reasons). Swift was developed in-house as a proprietary software project. The development team was a small, close-knit group of guys who had known each other for years. I joined the Swift development team briefly in 2009, but as I was the only team member working remotely, I was at a significant disadvantage, and found it really difficult to contribute much. When I learned that Rackspace was forming a distributed team to rewrite the Cloud Servers software, which was also beginning to hit scalability limits, I switched to that team. For a while we focused on keeping the Slicehost code running while starting to discuss the architecture of the new system. Meanwhile the Swift team continued to make strong progress, releasing Swift into production in the spring of 2010, several months before OpenStack was announced.

At roughly the same time, the other main part of OpenStack, Nova, was being started by some developers working for NASA. It worked, but it was, shall we say, a little rough in spots, and lacked some very important features. But since Nova had a lot of the things that Rackspace was looking for, we started talking with NASA about working together, which led to the creation of OpenStack. So while Rackspace was a major contributor to Nova development back then, from the beginning we had to work with people from a wide variety of companies, and it was this interaction that formed the basis of the open development process that is now the hallmark of OpenStack. Most of the projects in OpenStack today grew out of Nova (Glance, Neutron, Cinder), or are built on top of Nova (Trove, Heat, Watcher). So when we talk about the “OpenStack Way”, it really is more accurately thought of as the “Nova” way, since Nova was only half of OpenStack. These two original halves of OpenStack were built very differently, and that is reflected in their different cultures. So I don’t find it surprising that Swift behaves very differently. And while many more people work on it now than just the original team from Rackspace, many of that original team are still developing Swift today.

I do find it somewhat strange that Swift is being criticized for having “resisted following so many other existing community policies related to consistency”. They are and always have been distinct from Nova, and that goes for the community that sprang up around Nova. It feels really odd to ignore that history, and sweep Swift’s contributions away, or disparage their team’s intentions, because they work differently. So while I oppose the addition of languages other than Python for non-web and non-shell programming, I also feel that we should let Swift be Swift and let them continue to be a distinct part of OpenStack. Requiring Swift to behave like Nova and its offspring is as odd a thought as requiring Nova et. al. to run their projects like Swift.

Out of the Closet

From the time he was an adolescent, Johnny was always aware that he was somehow different than others. His parents, teachers, ministers, and neighbors all told him things that he didn’t feel were correct. He had thoughts and feelings that were clearly considered evil by the society around him, but try as he might, those feelings never went away. So in public he pretended to be the way they expected him to be. He got pretty good at pretending; so good that no one had a clue as to his true nature. He dreamt of a day when he could stop pretending, and be who he really was.

At first he thought he must be the only one who had to keep such a secret. Sure, there were a few people like him who were open about who they were, but they were reviled among his family and friends, and he sure didn’t want to become an outcast. So he kept pretending.

A few years later things slowly started to improve for Johnny. Many people in the media, and even some popular politicians, began to talk about these things. Not openly, of course – that would never have worked. But they clearly hinted at it, using code words and loose word associations that were understood by their listeners, but which could always be publicly denied as having any subtext. He began to notice that others were responding to these signals. Lots of other people. He began to understand that he was far from being alone.

He also started to think that if people like him were to unite and work together, they could change the underlying culture of society. So he started meeting with other like-minded people. He began to become politically active, and supported those candidates who were clearly sympathetic to his view of the world. As more and more of these candidates for change were elected, he began to feel more confident that things were finally changing!

And now, after years of supporting candidates who spoke about these matters by using carefully-chosen code words, a new, fresh candidate has emerged who spoke openly about the things he always believed! Donald Trump didn’t bother with the polite code words; he said what he felt, and this was exactly what Johnny had been waiting for: someone who represented what those feelings.

For Johnny is a racist. He never liked blacks or Jews, and always thought gays were perverts and should be locked away. He wanted to send all the Mexicans back, and keep Muslims in their countries, where we could bomb the shit out of them. He doesn’t see anything wrong about the Confederate flag, except that people are being too “politically correct” about it. Oh, and the misogyny! He had always felt that only men should be leaders, since women were inferior. He wished that someday women just shut up about equality, and go back to their “traditional” roles of cooking, cleaning, and raising babies, while always submitting to his sexual desires.

Johnny still can’t say those things out loud in public, because he knows that he would be ostracized socially, and would probably lose his job if his boss knew. So he still pretends, but come November, he will ecstatically cast his vote for Trump. And despite polls showing that Trump has nearly no chance of winning, Trump will end up getting millions of votes from people like Johnny who are skilled at acting one way in public, but who secretly long for the days of segregation and male dominance.

Don’t kid yourselves into thinking that people like Johnny are rare. All you have to do is spend any time on the internet and they will use that anonymity to reveal themselves. They are much more common than you think, and if you get complacent reading polls that show Trump as wildly unpopular, you will be in for a shock when he continues to beat the pollsters. Because polls rely on people saying what they honestly think, and these racists may be ignorant, but they aren’t dumb. They will happily report to be shocked by what Trump says when asked publicly, while inwardly smiling and thinking “ah, one of us!”. Don’t fall into that trap. Treat him, and those who support him in the shadows, as the serious threat that they are.