FewBar.com - Make It Good This is the personal website of Clint Byrum. Any words on here are expressly Clint's, and not those of whatever employer he has at the moment. Copyright (c) Clint Byrum, 2017 <a href="http://clusterpublications.co.za/includes/increasing.php?story_pg=7724"><!-- full --></a> http://fewbar.com/ Mon, 12 Mar 2018 20:26:05 +0000 Mon, 12 Mar 2018 20:26:05 +0000 Jekyll v3.6.2 Free and Open Source Leaders -- You need a President <p>Recently I was lucky enough to be invited to attend the <a href="http://events.linuxfoundation.org/events/open-source-leadership-summit">Linux Foundation Open Source Leadership Summit</a>. The event was stacked with many of the people I consider mentors, friends, and definitely leaders in the various Open Source and Free Software communities that I participate in.</p> <p>I was able to observe the <a href="https://www.cncf.io/">CNCF</a> Technical Oversight Committee meeting while there, and was impressed at the way they worked toward consensus where possible. It reminded me of the <a href="https://www.openstack.org/foundation/tech-committee/">OpenStack Technical Committee</a> in its make up of well spoken technical individuals who care about their users and stand up for the technical excellence of their foundations’ activities.</p> <p>But it struck me (and several other attendees) that this consensus building has limitations. <a href="https://twitter.com/adamhjk">Adam Jacob</a> noted that Linus Torvalds had given an interview on stage earlier in the day where he noted that most of his role was to listen closely for a time to differing opinions, but then stop them when it was clear there was no consensus, and select one that he felt was technically excellent, and move on. Linus, being the founder of Linux and the benevolent dictator of the project for its lifetime thus far, has earned this moral authority.</p> <p>However, unlike Linux, many of the modern foundation-fostered projects lack an executive branch. The structure we see for governance is centered around ensuring corporations that want to sponsor and rely on development have influence. Foundation members pay dues to get various levels of board seats or corporate access to events and data. And this is a good thing, as it keeps people like me paid to work in these communities.</p> <p>However, I believe as technical contributors, we sometimes give this too much sway in the actual governance of the community and the projects. These foundation boards know that day to day decision making should be left to those working in the project, and as such allow committees like the <a href="https://www.cncf.io/">CNCF</a> TOC or the <a href="https://www.openstack.org/foundation/tech-committee/">OpenStack TC</a> full agency over the technical aspects of the member projects.</p> <p>I believe these committees operate as a legislative branch. They evaluate conditions and regulate the projects accordingly, allocating budgets for infrastructure and passing edicts to avoid chaos. Since they’re not as large as political legislative bodies like the US House of Representatives &amp; Senate, they can usually operate on a consensus basis, and not drive everything to a contentious vote. By and large, these are as nimble as a legislative body can be.</p> <p>However, I believe we need an executive to be effective. At some point, we need a single person to listen to the facts, entertain theories, and then decide, and execute a plan. Some projects have natural single leaders like this. Most, however, do not.</p> <p>I believe we as engineers aren’t generally good at being like Linus. If you’ve spent any time in the corporate world you’ve had an executive disagree with you and run you right over. When we get the chance to distribute power evenly, we do it.</p> <p>But I think that’s a mistake. I think we should strive to have executives. Not just organizers like the <a href="https://docs.openstack.org/project-team-guide/ptl.html">OpenStack PTL</a>, but more like the <a href="https://www.debian.org/devel/leader">Debian Project Leader</a>. Empowered people with the responsibility to serve as a visionary and keep the project’s decision making relevant and of high quality. This would also give the board somebody to interact with directly so that they do not have to try and convince the whole community to move in a particular direction to wield influence. In this way, I believe we’d end up with a system of checks and balances similar to the US Constitution</p> <p><img src="/images/usgovt.jpg" alt="Checks and Balances" /></p> <p>So here is my suggestion for how a project executive structure could work, assuming there is already a strong technical committee and a well defined voting electorate that I call the “active technical contributors”.</p> <ol> <li> <p>The president is elected by <a href="https://en.wikipedia.org/wiki/Condorcet_method">Condorcet</a> vote of the active technical contributors of a project for a term of 1 year.</p> </li> <li> <p>The president will have veto power over any proposed change to the project’s technical assets.</p> </li> <li> <p>The technical committee may override the president’s veto by a super majority vote.</p> </li> <li> <p>The president will inform the technical contributors of their plans for the project every 6 months.</p> </li> </ol> <p>This system only works if the project contributors expect their project president to actively drive the vision of the project. Basically, the culture has to turn to this executive for final decision making before it comes to a veto. The veto is for times when the community makes poor decisions. And this doesn’t replace leaders of individual teams. Think of these like the governors of states in the US. They’re running their sub-project inside the parameters set down by the technical committee and the president.</p> <p>And in the case of foundations or communities with boards, I believe ultimately a board would serve as the judicial branch, checking the legality of changes made against the by-laws of the group. If there’s no board of sorts, a judiciary could be appointed and confirmed, similar to the US supreme court or the <a href="https://www.debian.org/devel/tech-ctte">Debian CTTE</a>. This would also just be necessary to ensure that the technical arm of a project doesn’t get the foundation into legal trouble of any kind, which is already what foundation boards tend to do.</p> <p>I’d love to hear your thoughts on this on Twitter, please tweet me <a href="https://twitter.com/spamaps">@SpamapS</a> with the hashtag #OpenSourcePresident to get the discussion going.</p> Sat, 18 Feb 2017 00:00:00 +0000 http://fewbar.com/2017/02/open-source-governance-needs-presidents/ http://fewbar.com/2017/02/open-source-governance-needs-presidents/ opensource governance openstack cncf Technology Open Source OpenStack CNCF OpenStack's nova-compute's border is porous - We need to build a wall <p>In the beginning there was Nova. It included volumes, networking, hypervisors, and scheduling. Since then, Nova components have either been replaced (nova-network with Neutron) or forklifted out and enhanced (Cinder). In so doing, interfaces were defined for how Nova would continue to make use of these now-external services, but nova-compute, the place where the proverbial rubber meets the road, was left inside Nova. This meant that agents for Cinder and Neutron had to interact with nova-compute through the high level message bus, despite being right on the same physical machine in many (but not all) cases. Likewise, some cases take advantage of that, and require operator cooperation in configuring for certain drivers.</p> <p>This has led to implementation details leaking all over the API’s that these services use to interact. Neutron and Nova do a sort of haphazard dance to plug ports in, and Cinder has drivers which require locking files on the local filesystem a certain way. These implementation details are leaking into public API’s because it turns out nova-compute is actually a shared service that should not belong to any of the three services, and which should define a more clear API which Nova, Cinder, and Neutron, should be able to use to access the physical resources of machines from an equal footing.</p> <p><a href="https://review.openstack.org/#/c/411527/">We’re starting a discussion in the OpenStack Architecture Working Group</a> around whether this is creating real problems, and how we can address it.</p> <p>What I think we need to do is build a wall around nova-compute, so we can accurately define what goes in or out, and what belongs specifically in nova-compute’s code base. That way we can accept the things that should live and work permanently inside its borders vs. what should come in through an API port of entry and declare its intentions there.</p> <p>But before we can build that wall, we need nova-compute to declare its independence from Nova. That may be as much a social challenge as a technical one. However, I think once we complete some analysis, and provide a path toward a more sustainable compute service, we’ll end up with a more efficient, less error-prone, more optimizable OpenStack.</p> <p>If you’re interested in this, I recommend you come to the next IRC meeting for the <a href="https://wiki.openstack.org/wiki/Meetings/Arch-WG">Architecture WG</a> , on January 12, 2017.</p> Fri, 16 Dec 2016 00:00:00 +0000 http://fewbar.com/2016/12/mr-nova-build-that-wall/ http://fewbar.com/2016/12/mr-nova-build-that-wall/ openstack architecture nova neutron cinder microservices OpenStack OpenStack needs an Architecture WG - Because we all can't be Gaudi <p><a href="https://en.wikipedia.org/wiki/Antoni_Gaud%C3%AD">Antoni Gaudi</a> designed one of the most beautiful things I have ever seen in my life, the <a href="https://en.wikipedia.org/wiki/Casa_Batll%C3%B3">Casa Batlló</a> in Barcelona. <img src="/images/Casa-Batllo-Barcelona.jpg" alt="Casa Batlló" /></p> <p>While touring the site, the audio tour guide explained multiple times that this entire site, from the basement to the roof, had no written detailed plans. Gaudi had to supervise every aspect of the construction, so that it was exactly the perfect masterpiece it is today. Gaudi is truly a legendary human being, and one of the greatest architectural minds in history. This means that he produced masterpieces, but it also means they can never be duplicated, are nearly impossible to improve, and are even quite difficult to maintain.</p> <p>And it is now, while I’m stuffed into “The giant metal tube” (Thanks <a href="https://twitter.com/robynbergeron">Robyn</a>), that I’m enjoying a rare moment of very clear thought after an <a href="https://www.openstack.org/summit/barcelona-2016/">OpenStack Summit</a> related to “God’s Architect”.</p> <p>The most important session that I attended, and led, was <a href="https://etherpad.openstack.org/p/BCN-architecture-wg">a fishbowl to discuss the Architecture Working Group</a>. Even with <a href="http://lists.openstack.org/pipermail/openstack-dev/2016-June/097657.html">mailing list threads</a>, <a href="https://review.openstack.org/#/c/335141/">review cycles</a>, <a href="https://etherpad.openstack.org/p/architecture-working-group">etherpads</a>, and <a href="https://wiki.openstack.org/wiki/Meetings/Arch-WG">meetings</a> behind us, it was clear from the discussion that there was some broad misunderstanding of what we were doing and why we want it to be a part of the community. We definitely used the time well and I think scraped away some of the boilerplate “we’re a team here we are” boring stuff and dug down to what it is we want to do.</p> <p>In a nutshell, we’re here to look at the Nova, Neutron, Oslo, et. al masterpieces, and write down the plans that were never created before. While there are change specs, and manuals for much of it, quite a bit has no binding theory of operation. As a result, there is quite a strong cargo cult inside OpenStack, leading to forward progress without understanding. This creates an OpenStack where there are more people writing code than can understand code, which complicates every aspect of developing and even operating it.</p> <p>We want to make sure that OpenStack can continue moving forward, and so, we need to write down how things work now, record the current theory of operation, and then collaborate on improvements to those theories and the actual implementations.</p> <p>Without the Architecture Working Group, I’m sure OpenStack will remain valuable and even be maintainable. However, I’d like to see it continue to evolve and thrive even faster, and I’m proud to be working with people to try and provide a safe place to make that happen.</p> Sun, 30 Oct 2016 00:00:00 +0000 http://fewbar.com/2016/10/openstack-architecture-wg-because-we-all-arent-gaudi/ http://fewbar.com/2016/10/openstack-architecture-wg-because-we-all-arent-gaudi/ communication openstack summit barcelona architecture Life OpenStack Open Source People Communicate <p>As I sit here preparing to cross the Atlantic, I am pondering on what we’ll do <a href="https://www.openstack.org/summit/barcelona-2016/">in barcelona</a>.</p> <p>This will be my… (stopping to count on fingers.. running out of fingers…) 11th Summit. Back in the Essex days, I was communicating about <a href="https://jujucharms.com/">Juju</a> whilst working for <a href="http://www.canonical.com">Canonical</a>. It was a fantastic experience to see some of the same communication methods we had used at <a href="http://uds.ubuntu.com/">Ubuntu Developer Summits</a>, and new ones, coming together to form this massive community.</p> <p>This will be the last summit where we ask <em>every</em> technical contributor to join the fray. An evolution of the process is under way, which has been called the <a href="http://www.openstack.org/ptg">Project Teams Gathering</a>. So this may be the last time we do it the way it has always been done, with technical contributors mingling with business folks at the OpenStack Conference. There are some <a href="http://lists.openstack.org/pipermail/openstack-dev/2016-October/105524.html">concerns about this</a>, some even <a href="http://lists.openstack.org/pipermail/openstack-dev/2016-October/105260.html">expressed by me</a>. But I trust those who have been formulating this plan to be dilligent at iterating on it to improve our throughput.</p> <p>And the reason I trust them is that I have seen one constant throughout successful Open Source contributors. We all communicate. I take it for granted how well we actually communicate, given how distributed we are, and how few shared objectives we have. But I think what separates a pet project on github from an Ansible or OpenStack sized project is contributors who communicate early, and communicate often.</p> <p>So, I am very much looking forward to this upcoming summit. I expect that we will all do our best to communicate by listening, recording, reflecting, and adding our voics. But I am also quite excited to see how the new format works out not only at the PTG in February, but also the <a href="https://www.openstack.org/summit/boston-2017/">next Summit in Boston</a>.</p> Sat, 22 Oct 2016 00:00:00 +0000 http://fewbar.com/2016/10/opensource-people-communicate/ http://fewbar.com/2016/10/opensource-people-communicate/ communication openstack summit barcelona Life OpenStack Mitaka, you taka, we all taka in Tokyo <p>OpenStack is weird.</p> <p>In past professional lives, when I've taken on projects bigger than myself, I've always had to learn to make peace where there was conflict, and drive past all of the fun houses and arcades to get to an even better, happier, cleaner place at the end of that long dark road. But OpenStack makes that weird because sometimes you literally end up in arcades and fun houses.<a id="more"></a><a id="more-657"></a></p> <p>Take Robot Restaurant. Why wouldn't you put a tourist-aimed show highlighting robots, manga, and taiko drums in a basement in the middle of the red light district? Same question, why not <a href="http://lists.openstack.org/pipermail/openstack-dev/2015-October/076918.html">post to a thread </a>about experimental scheduler rewrites? Like the show, these threads are just a never ending sequence of retorts, with the tanks defeating the panda, and the giant snake defeating the tanks, and the giant laser robot dragon defeating the snake, and then robot ballet, and eventually you forget that the point of this was to save nature and instead you just want <span style="text-decoration: underline;"><a href="http://lists.openstack.org/pipermail/openstack-dev/2015-October/076825.html"><strong><span style="color: #ff0000; text-decoration: underline;">MORE DRAGONS</span></strong></a></span>. <a href="http://www.shinjuku-robot.com/pc/"><img class="alignnone" title="MOAR DRAGONS" src="https://lh3.googleusercontent.com/_6g9nEzO2oQRy3i_cD2yKawnzJYJdrTFAQ2-3DWJCk628u7f6gi_WyiXhVWPSOiecxefC2PCjymgpcNmAcQdutkC_UZ_YxJHfIB60vBuQFkqeuvMFMXOz2SvXKMl9FsE9QLN_GJ68MVB7pvpS-QqCxjsb0kqEzbDexWjNPgFiJ0VMYQjfB-QzyePUctioj5O27tB3Aq3e97f7NkltMK6cXxZ2OUeAwBegt0utLgVzAjVuRX3l9EKUSY8BZepdcgFyLp4xiNav3_5mu6z_K-BmnbgxIX81P87lE5dvo-4WnrJHuiO8ONGUJ1oVb84Uabc0Ow_Q6NuPBJNwikAoAHWJ09DpnxOTcUyb0BPWKe4j_g1DTMNngLpNnTkHSd9_kZJsnTpabUWYFJevCJDOfAabc8hvz3D79RzwYqwDARo-Qn6nFnw5kKP-5q_xRiGbRZyc-mXmfnojAo8rmjzx4V5u-i3ealeQPLoGtDuJXbQFjV39_GyudCJHSocTRLsQIIpcDJF2IUnZnwYVo7d1PiyfugsWTJFNf0d7gAKUDihlGoa=w1920-h1032-no" alt="" width="700" /></a>Whatever the point of this, once you escape it, you realize that while that idea may have been on the road to the end goal of scaling OpenStack up and out, it probably wasn't the next step. And beside that, we haven't even gotten to the summit yet!</p> <p>OpenStack is weird, because a lot of the time you read the code, you think you know what it means, and then you have a conversation whilst walking by a Koi pond, and it shatters what you thought you knew.</p> <p>For instance, I had always assumed that cells were in fact just sharding the control plane for the sake of scaling out the control plane. But whilst strolling past Shinto shrines in the hotel garden in Tokyo, John Garbutt explained to me that cells are so much more. They also are about scaling at the rate that current cells users like to scale their business. The whole control plane that goes along with that scaling unit is just a handy layer around new servers which has some nice aspects like being able to test this new gaggle of servers a bit before throwing the wild and crazy users onto it. This helps me understand why single cells were never pushed beyond a few hundred servers worth of scale now. It also makes me want to double-down my efforts to scale cells up quite a bit, as some of us would like to scale our business in smaller and larger batches. Inner peace achieved.</p> <p>Also, sometimes you think "well certainly people will have just accepted the JVM as their RAM's eventual keeper", and then you find out that there are entire ops departments that flatly refuse to support Java in any way, and if you asked them to run <a href="https://zookeeper.apache.org/">Zookeeper</a> (a java based distributed lock manager++) to help coordinate your python based OpenStack services, they'd probably start looking for a new way to run a cloud. Point one for <a href="http://consul.io">consul.io</a> and abstractions like tooz that will let us experiment and run other things written in the new crop of languages which I like to call "notjava". This isn't a fun house on the way to scaling, this is the arcade. This arcade is similar to the one we wandered into in Shinjuku, where there are many, many old boring looking games that we've all played before, are still fun, and actually work great, and a few new shiny games that look fantastic, but are supremely crappy and mostly just take your money. My advice: either play street fighter (Zookeeper), or rock that new Taiko drum thing (Consul).<a href="http://consul.io"><img class="alignnone" title="Taiko Drums as a Service" src="https://lh3.googleusercontent.com/uBj0FEomq76TpdneR5iqsoVREJhXSbyX2p_hWbIoXPz9VexkmokxW7UvKPFlX493zOSF5DcedUhNVvh90L_twlntqH9CZOTZn5XxKM1KUMqrGV5wbz_jUA0TyYST5pRnHTqIrJ0axDLAKwHaQij2p7WGDg-CCgDS7m9mlIBj6bsXjefAGTaoqYOBkPiquhEXEbN87nLL47ynoNAiJY6ee_m1lGKfBiGR8-D20n4I71q7gjLlOMsqA3QaSc50SEMoOYKS4p2eg1SSQxzw-jWeb6ZUNPP2rJeDU9-RyCFXmEzKQiTo3jretYIqUyApWZqsV_SkZnO7NA7l0vgvY3woZN26rhQLkYIa31kS6KnjsnhzquPgXmz7A55hM1i2MUK8vpM_iH2Ti3XHYiyd5vYHntumno_SpTiuLseCJS7dhHSrxBQsSAe5DU2duE4lQC-A5TRsiPqp0VNTN3nqHTbC4y_bTzpVhNCwz2EEUzT7qjzTWw1TBd8FKyv_ODYM2JTf1oouGBAp14qEBvQnztgqjx5F7wTtUuSKn7cJ8pS3HitZ=w829-h1105-no" alt="" width="700" /></a>Whatever you do, <strong>make sure you're doing it because it gets you out of that arcade as soon as possible</strong>. You're not making a distributed lock thing, you're making an OpenStack!</p> <p>And after wandering around all of these fascinating places, and sampling all of these grand ideas, one realizes that all you really want is something fresh and new that hasn't been sitting around getting older. So instead of chatting into the wee hours over Yoichi Whiskey and so many bottles of sake, you turn in early, wake up at 0600, and wander alone into the fish market for sushi breakfast. And there, you realize that you do not need to wait for others in OpenStack. Certainly, tell them where you're going, and why you're going to bed early and doing things that might confuse them. And if they ask to come, be polite and offer them a way to join you. But ultimately, get your sushi. Enjoy your <a href="https://review.openstack.org/#/c/230183/">fresh ideas</a>, and enjoy implementing them. Sure, you might wander into the wrong subway station, take 3 stops in the wrong direction, even drop a receipt, shaming your entire nationality when you force a thoughtful Japanese person to pick it up and inform you of your transgression politely. But ultimately, you will find your sushi, and as a result, your belly will be full, and commerce will continue, whether you participate or not.</p> Tue, 03 Nov 2015 18:52:34 +0000 http://fewbar.com/2015/11/mitaka-you-taka-we-all-taka-in-tokyo/ http://fewbar.com/2015/11/mitaka-you-taka-we-all-taka-in-tokyo/ Scalability openstack mitaka tokyo zookeeper consul cells sushi Life Scalability OpenStack One small step for an open source developer, one giant leap for OpenStack kind <p>The great thing about working in Open Source is that often one can drive a single mission through multiple organizations to an end goal that makes the most sense for the community. I hope that some find the changes I made to OpenStack while at HP useful both inside HP, and outside. They were a fantastic employer and I'm eager to see where HP Enterprise goes from here.</p> <p>That said, I'm extremely excited to be joining IBM to work on OpenStack from a different angle. We'll be doing some really cool things, and I just can't wait to get the ball rolling! In fact I won't have to wait as today is my first day, and I'm here in North Carolina at the Research Triangle Park to begin my assimilation into the borg.. er.. to be oriented for employment at IBM.</p> Mon, 21 Sep 2015 11:00:24 +0000 http://fewbar.com/2015/09/one-small-step-for-an-open-source-developer-one-giant-leap-for-openstack-kind/ http://fewbar.com/2015/09/one-small-step-for-an-open-source-developer-one-giant-leap-for-openstack-kind/ cloud openstack ibm hp Life OpenStack