What I want to talk about in Hong Kong


The Hong Kong OpenStack summit is fast approaching, assuming all goes well (DISCLAIMER HERE), I'll be there for the OpenStack Board of Directors meeting on 11/4 and the conference the remainder of the week. I'm looking forward to a number of really great sessions. But, most of all, I look forward to the 'hallway track.' Unlike past years, I won't be speaking and I also won't be carrying the responsibility of managing a large organization or running a huge 24x7 operation. This time, I'll be 100% focused on engaging in the summit. With that in mind, I wanted to highlight a few areas I want to dive into during the summit. If any of these resonate with you, look for me at Breakfast with the Board on Wednesday morning or find me somewhere during the week. I'll be the American with his right arm in a sling.

OpenStack Core Definition

I think this is one of the most important topics that the OpenStack Foundation Board of Directors is leading. Rob Hirschfeld has done a fantastic job of leading the effort to define core. He has pulled in a huge cross-section of the community and put us on a path to move forward on this critical issue. I am very happy with the current direction of having core verified through specific tests and requiring the use of some OpenStack code. It seems as though we have surfaced a lot of the critical issues and are about ready to move forward to the tough work of defining the required details. I am hopeful Rob's goal of having a full process in place in 2014 can be realized. I would love to talk more about this with anyone in the community. Are we on the right track? missing something? totally offbase? Getting input from everyone now will help make sure we keep this on pace to finish.

Individual Memeber Election Process

We didn't move the ball forward quickly enough, IMHO, on this issue in 2013. I am at least partly to blame for that. It didn't receive my constant attention or focus through much of the year. I am convinved, based on the results and community feedback, that we need to move away from the current cumulative voting as prescribed by the bylaws. I have a strong preference to move to Condorcet but Single Transferrable Vote (STV) is another viable option. We finally have some momentum on getting this to the community for vote in the next few months. I would love to get more input on this area. Do you agree we need to move forward on a change? Are we moving too fast? Do you have a strong preference on Condorcet or STV?

OpenStack Scope

The Board and TC made some headway in broadening the kinds of project categories for OpenStack with the creation of Integrated projects. Obviously the board needs to complete work on Core to finish this off. But, the work done by the TC broke the logjam of new projects and some of the confusion around the path for Incubated projects. I would love to get feedback on how people that that is working.

From my own point of view, I dont think we are done with this yet. I trust the TC's decisions around the current new slate of projects. But, over time, I am worried that the overall scope of OpenStack may be getting too broad. The TC and our amazing OpenStack CI team have become extremely efficient at managing new projects. But, these projects all take up mailing list bandwidth, conference time and speaking slots and potentially distract from the focus on core projects.

I don't have a well formed opinion about whether we are in the right place. But, the scope creep and lack of clear definition around what should be managed by the foundation and TC make me a bit nervous. Do you think we are on the right track? Should we be expanding faster? or slower? Am I worried about nothing? Am I just too old and conservative in my thinking? I would love to engage with people on this topic and get a better sense about other feelings on this issue.

Rackspace Alignment and Engagement

As I pointed out before the Portland Summit, Rackspace needed to reenergize our efforts in the community and close some alignment gaps with common OpenStack practice. We've largely stayed on track with these efforts throughout the year (I intend to have a detailed update on the Rackspace blog before the summit). But, I know we can do more. I think we can make improvements in our Rackspace structure and processes that will enable us to more consistently engage in the community and keep our offerings more aligned with common OpenStack practices. If you have experience with organizational models that allow product/service companies to effective engage in upstream while maintaining customer facing obligaitons, I would love to hear more. If you see places where we are completely missing the mark, let me know. I'd even listen to where we are getting right! Let's share ideas and make everyone better.


Assuming I can get used to not using the "Q word", I want to dive deep into Neutron. Our early efforts around the networking projects yielded a product last year. However, the tradeoff was that we've diverged from the current code and we haven't been involved in upstream development. This is especially true for myself. The completion of some stability projects along with some new people on the team give us an opportunity to reengage. I would love to talk about how we help get pluggable IPAM so that Rackspace can move towards an upstream networking implementation. I would also like to know where I and other Rackers can begin to help and get more tightly integrated across the Neutron project. I want to see the transition from Nova Network to Neutron go smoothly. I think it is important for Neutron to become the OpenStack differentiator it can be. I'll be in a number of Neutron sessions but feel free to grab me for some deep discussion around all of this.

Comments powered by Disqus

Contents © 2014 Troy Toman - Powered by Nikola