Open Stack

On 10/08/2014 05:29 PM, Adam Lawson wrote:
> It seems I left out a response. Sorry for the follow-on but here's what was
> missing.
> 
> *Topic: Technical Committee Mission*
> *How do you feel the technical committee is doing in meeting the technical
> committee mission?*
> 
> *"The Technical Committee ("TC") is tasked with providing the technical
> leadership for OpenStack as a whole (all official programs, as defined
> below). It enforces OpenStack ideals (Openness, Transparency, Commonality,
> Integration, Quality...), decides on issues affecting multiple programs,
> forms an ultimate appeals board for technical decisions, and generally has
> oversight over all the OpenStack project."*
> 
> I believe the TC has thus far done a pretty fair job given the team and its
> charter are both rather new. While the TC has been providing leadership for
> individual components, I would not characterize the TC today as providing
> highly visible leadership (necessary for openness and transparency) which I
> would like to see improved. Much of the TC's work today coalesces around
> providing a safe harbor for meaningful program integration and ensure
> challenges are resolved optimally but the TC needs to get better at
> identifying the good/poorly-defined boundaries of this kind of technical
> governance model. In other words, the TC needs to get better at being a
> good TC. The instantiation of a TC is a perfect first step but the pink
> elephant in the room seems to be around cross-project and architectural
> guidance; ensuring Openstack as a whole is moving in a direction that
> doesn't require accommodating things we shouldn't be doing in the first
> place. The lack of API standardization is a great example of moving in a
> direction without a big picture context.
>  Communications that have gone back and forth and debated about the big
> tent model, layers/cascading, scaling documentation, etc have been visible
> and the candor of opposing viewpoints have been awesome to follow. But we
> could really benefit from some structural adjustments so more decisions
> placed before the team are equally visible, a visible and transparent
> decision-making process enabling those who use Openstack understand the
> architectural perspectives shepherding it. Not just the decision that have
> 100+ replies on the mailing list
>  "Oversight over all the projects" is an area that I'm anticipating where
> we have some easy low-hanging fruit. Where we are today with regard to
> focus is understandable given the number of fires affecting individual
> programs that cannot be ignored. But we have a big opportunity (there's
> that word again) to get some traction on the larger architectural decisions
> that may require more work up front but produce some big wins over the long
> term. Customers who want to use Openstack have often played the "constant
> change = unstable" card for good reason; Openstack has a long way to go
> before it gets to Production-quality for the masses (i.e. without heavy
> re-development requirements). I believe the TC can and should influence
> that with better solution-level leadership.
>  - The deployment challenge is beyond ready for attention.
> - A working default 'out-of-the-box' config that can boot an instance
> accessible over the network is STILL a challenge. Long past due in my mind.
> - Programs like Oslo that address library requirements moves a cloud closer
> to Production-capable but really shouldn't be optional. Doing something
> well shouldn't be optional. In fact, a Production context shouldn't be one
> option of many despite the prevalence of Openstack PoC and pilots; it
> should be a consistent design assumption. Gating a feature to the point
> that it's 'good enough' is part of the problem. It must be
> Production-worthy otherwise it is NOT good enough. That's ready for
> attention.
>  We might not be able to address all of these and some ideas could use a
> lot more cross-talk, but if elected I would like to champion improving how
> the TC approaches problems and vets their potential solutions.
> 
> 
> *Adam Lawson*
> 
> AQORN, Inc.
> 427 North Tatnall Street
> Ste. 58461
> Wilmington, Delaware 19801-2230
> Toll-free: (844) 4-AQORN-NOW ext. 101
> International: +1 302-387-4660
> Direct: +1 916-246-2072
>
Thanks Adam, I will add this to the wikipage.

Thanks,
Anita.
> 
> On Tue, Oct 7, 2014 at 7:06 PM, Adam Lawson <alawson at aqorn.com> wrote:
> 
>> Hello everyone!
>>
>> I'll be perfectly straight and dedicate paragraph #1 to address the
>> painfully obvious. A number of you are probably reading this after seeing
>> 'TC Candidacy', looked at my name and wondered 'who is this guy?' In short,
>> I'm pretty low-key but I've been heavily involved in Openstack since the
>> Folsom release - advising, architecting and deploying Openstack-based
>> application clouds for numerous companies and end users. I'm probably a lot
>> like many of you in fact; not the loudest or most witty voice in the room,
>> I read more than I write, I don't bully ideas and I've never run for
>> anything in my life because I hate the spotlight. But the importance of
>> Openstack in the cloud marketplace is increasingly important as is the
>> integrity of its technical direction. So I'm going to step on a limb here
>> and enter the circle.
>>
>> My involvement has been primarily focused on large designs and deployments
>> of custom automated Openstack clouds. And while I am more than proficient
>> in Python and numerous other languages including .NET/J2EE and others, my
>> greatest pleasure has been architecting solutions that are powered by
>> Openstack. Focusing on that has really given me a unique perspective. Not
>> just on individual components and how they interact with each other, but
>> also how they collectively perform within the context of a heterogenous
>> hybrid cloud solution while adhering to industry best practices. This
>> perspective is one that I hope to bring to the technical committee if the
>> Openstack community is so inclined. Not only to shepherd how Openstack is
>> put together but to help enable an easier and more seamless adoption cycle
>> within the enterprise.
>>
>> Lastly in the spirit of full disclosure, I am the principal architect for
>> an Openstack consulting company I founded which strives for an accelerated
>> enterprise adoption of the open cloud through, in part, the successes of
>> Openstack. So one could say I am vested in Openstack in a pretty unique way
>> compared to most others. So where technical direction is concerned, I
>> believe I have a deep well of experience from which to draw via designing
>> and developing production Openstack clouds in the real world - day in and
>> day out - which I believe would be of immense value to the TC and the
>> community supporting the project itself.
>>
>> I know there are some really smart people who want to also serve on the TC
>> with focuses on various areas of Openstack and thankfully the committee was
>> designed to accommodate multiple unique perspectives for that very reason.
>> My hope is that the community chooses to include my program-agnostic
>> architectural influence to the TC while maintaining the same work ethic and
>> unyielding commitment to efforts that will deliver excellence to and within
>> the Openstack platform.
>>
>> So without any further adieu, below are my thoughts re the requested
>> questions and thanks for your consideration!
>>
>> *"My name is Adam Lawson, running for election to the Openstack Technical
>> Committee, and I approve this message."* ; )
>>
>> *Topic: OpenStack Mission*
>> *How do you feel the technical community is doing in meeting the OpenStack
>> Mission?*
>>
>> *“To produce the ubiquitous Open Source Cloud Computing platform that will
>> meet the needs of public and private clouds regardless of size, by being
>> simple to implement and massively scalable.”*
>>
>> The whole point of mission statements is merely to identify what we are
>> striving to achieve or accomplish within the organization. With that said,
>> I feel that technical leadership is the first step to accomplishing a
>> technical goal. So to that end, the existence of the TC is a positive first
>> step. But it's just one step or many more to come.
>>  Within this particular TC cycle, I'd like to see the TC demonstrate
>> leadership to drive a reduction of lingering technical debt and address API
>> and module standardization. Openstack in its current form has a number of
>> challenges that are affecting our ability to scale and while some of this
>> can be solved organizationally, technical debt and standardization are
>> challenges that will not be easy to resolve and might not even be 100
>> percent solvable within a single release cycle. But I look forward to how
>> the TC *will* shepherd improvements to both process and the product and
>> help drive the mission.
>>  On a side note, "easy to implement" is still just a goal and the
>> engineering requirement to deploy and manage Openstack is still a
>> prohibitive hurdle for many organizations. But we have more than one tool
>> in front of us that will help us to help others who want to use Openstack
>> but .. can't. That's something I'd really like to see change soon.
>>
>> *Topic: Contributor Motivation*
>> *How would you characterize the various facets of contributor motivation?*
>>  I like what I read earlier today: "People want to do work that matters
>> and enjoy doing it." This sums up Openstack contributors very well but it
>> sums up a lot of us too though, doesn't it.
>>  Many of us are lucky enough to be able to work on Openstack full-time as
>> a job. There are many others who work with Openstack in the context of
>> Consumers, Users, Operators, Solutions Architects where it is not their
>> full-time job but they participate with the Openstack community because of
>> other reasons. Whatever the reason (philanthropy, my good looks), folks
>> want to work on what matters and if it doesn't matter, there is no
>> motivation to continue.
>>  - I see friendly interactions within the community even when we
>> disagree. That's motivating.
>> - I see members within the Openstack community soliciting and offering
>> help to each other - even between companies who could technically be called
>> competitors. That's motivating.
>> - I see the same people who earn a living on selling and supporting
>> proprietary deployments of Openstack offering their assistance and
>> perspectives to those who are not using their product and possibly never
>> will. That's motivating.
>>  The culture developed and nurtured by the Openstack community is nothing
>> short of admirable and from someone who is socially-driven (despite my
>> little shell), I have to say that so long as the TC adheres to and advances
>> this culture, motivation will be easy to find for those who desire to get
>> engaged.
>>  For those who need a little help, I think the Upstream University is
>> another place to encourage new contributors and get them motivated through
>> empowerment via learning/knowledge and the satisfaction of watching their
>> hard work being used and consumed by countless companies and individuals.
>> *Topic: Rate of Growth*
>> *There is no argument the OpenStack technical community has a substantial
>> rate of growth. What are some of the consequences of this rate?*
>>  I believe Openstack is on the cusp of experiencing growth pains like it
>> never has before. I don't think we've even touched on what those pains will
>> look like when we hit some of our long-term adoption goals/milestones. But
>> pain drives change and change that drives improvement is good. So we can
>> all tell change is on the horizon.
>>  One of the consequences of rapid growth can be disproportionality
>> between different areas of the Openstack and its community. Code might get
>> ahead of docs, the need for process might get ahead of the definition of
>> those processes and scale requirements might reveal all of those unsightly
>> warts we've been content to ignore for the last year.
>>  I don't see growth as having consequences per se. Without wanting to
>> sound cliché, I see Openstack as approaching growth-related challenges that
>> we need to treat as real opportunities. So long as we focus on the task at
>> hand and not lose sight of the 'why' not allow overwhelm-ment (is that a
>> word?) from affecting the measure of correction that may be needed to
>> resolve a challenge, I think we'll continue  to land on our feet from cycle
>> to cycle.
>>
>> *Topic: New Contributor Experience*
>> *How would you characterize the experience new contributors have
>> currently?*
>>  I mentioned Upstream University earlier and I think it's worth repeating
>> that working on something that matters is motivating.
>>  I do *not* believe however that maintaining the status quo is ever an
>> acceptable approach with technical leadership as provided by the TC.
>> Quirks, 'that is the way we've always done it' and 'get used to it' are
>> completely unacceptable. We can't discourage change if it helps but we
>> can't allow unnecessary or poorly-prioritized changes to negatively affect
>> our progress on the project as whole either.
>>  With that said, I'm pretty sure new contributors that are contributing
>> to Openstack (more than casually) understand the dynamics around
>> contributing to a high-volume open source project like Openstack. For those
>> who do not, the learning curve can be pretty steep but beneficial. And we
>> need to be careful not to allow the process to suffer for high performers
>> in the name of inclusiveness.
>>  One of my goals, if elected, will be to facilitate a superior product
>> via process(es) that enables a scalable contribution pipeline for
>> experienced developers - coupled with an effective onboarding process for
>> those who are just getting started with Openstack's development cadence. I
>> think the priority definitely needs to be where we get our biggest bang
>> since our resources are obviously not unlimited but I hope that an
>> effective contributor experience does a good job at accommodating both new
>> and existing contributors and I hope we aren't afraid to challange the
>> status quo if we're failing that goal somehow.
>> *Topic: Communication*
>> *How would you describe our current state of communication in the
>> OpenStack community?*
>>  While I think our communication overall is encouraging and moving in a
>> positive direction as a whole, I think cross-project and communication
>> between developers and the consumers remains to be a challenge.
>> Understandable though when you have multiple mailing lists with countless
>> updates and program owners and contributors who can't possibly read every
>> message to se if there's something that requires their attention.
>>  IRC and email tends to be our forte but I envision expanding the
>> Operator Summits to include cross-project summits where brainstorming
>> between 2-3 programs that compliment each other (i.e, Swift/Sahara,
>> TripleO/Ironic/Nova) can be *highly* beneficial. I know we already have
>> mid-cycle meet-ups but this level of collaboration might even benefit from
>> a dedicated design summit. No sponsors - just a place where ideas dedicated
>> to the technical direction of Openstack share the spotlight. Just a thought.
>>
>> *Topic: Relationship with the Foundation Board*
>> *The technical committee interacts with the foundation board on several
>> different fronts. How would you describe these interactions?*
>>  There's a world of difference between project governance and technical
>> leadership. I admittedly have not sat down with the Foundation members
>> within a TC context so I couldn't speak to how it works well or not today.
>> But what I can say is that I've read what the other candidates who have
>> served on the TC in the poast have shared and my interpretation is that
>> things seem to be a bit frosty.
>>  But I've run into this before. Regardless, I think a clear definition of
>> roles and responsibilities would be of value to both the Foundation and the
>> TC and the relational elements that affect their ability to work together
>> effectively. I'm looking forward to seeing this interaction firsthand and
>> making up my own mind. But until then, onward and upward!
>>
>> *Foundation:* http://www.openstack.org/community/members/profile/11026
>> *IRC:* greenhorn
>> *Website:* http://www.aqorn.com/about
>>
>> Mahalo,
>> Adam
>>
>> *Adam Lawson*
>>
>> AQORN, Inc.
>> 427 North Tatnall Street
>> Ste. 58461
>> Wilmington, Delaware 19801-2230
>> Toll-free: (844) 4-AQORN-NOW ext. 101
>> International: +1 302-387-4660
>> Direct: +1 916-246-2072
>>
>>
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>