Exploring Openstack for Huawei
I am an industry veteran, with experience spanning computer bring up to AI, networks, mobile compute, and embedded systems. But my attention always seems to return to close to the metal, large infrastructure. Starting out in EE as a systems engineer, I migrated to SW development then on to QA and SW Process. During the journey, I have analysed Space Shuttle launch communications, modelled complex space systems. I have tested compilers, debuggers and visualization tools for a SIMD system and done software bringup for a SPARC based, multiprocessor mainframe. I have managed teams supporting software release, compute farms for chip design, and QA and escalation for mobile embedded compute systems and location based apps on mobile phones. Ensuring all of these were successes is why I am a champion for operations, interoperability, quality, reliability and usability. They all go hand-in-hand in creating success.
As for Open Source, I have been aware and peripherally involved in Open Source since the original creation of Copy Left, but am finally fully immersed in it now, as an OpenStack resource within OpenStack and Huawei. I have learned through my endeavors that my skillset is best applied once a certain level of maturity has been achieved in a project. My abilities are a great fit for where OpennStack is now and where we can take it.
Most importantly, I meld a passion for quality performance with a pragmatism gained in the real world.
Projects/Work Groups: DefCore, Refstack, Product Work Group, Logging Work Group, Women of OpenStack, Diversity Work Group ,and (soon to be) Stable project (plus I hang out in Infra, collaborate with Oslo, follow the TC, Ops and Dev MLs)
I'm involved in the following OpenStack projects: Quantum,Ceilometer,Oslo,Release
My OpenStack successes have been in the advancing the state of all those parts of OpenStack that aren't directly project code. The "soft" areas of OpenStack, you might say. My drive is to see OpenStack become the ubiquitous Cloud Operating system in the world, but my strengths are in building and improving the infrastructure of the project so that it will meet the "-ilities" requirements of the business world. Quality, performance, usability, maintainability, scalability, extensibility, reliability, interoperability, and etc.
My biggest successful contribution to OpenStack has been in raising awareness of the needs of the user community within the developer community and working across projects and communities to establish lines of communication and collaboration. I am a driver in the Product Work Group, the Logging Work Group, DefCore, Refstack and participate in many other aspects of OpenStack. What I bring to OpenStack is being able to identify specific needs and finding people with their own passions to address those needs. I view myself as a catalyst, getting the needed energy in the right places at the right time. My biggest success is opening eyes and minds of memberrs of various OpenStack communities to the needs and capabilities of other communities that then leads to good things happening.
I have served on the boards of Home Owners Associations, Neighborhood Associations and a 501c3 that was focused on providing technical education and tools to other nonprofits for use in their management of their financial and client operations. I have held the roles of member at large, treasurer, vice president and president, with fiduciary and community responsibilities of managing >$100k budgets and >$5M reserves (I know, small potatos) and the contracts associated with maintaining the property. I have participated in settling disputes between neighbors as well as participating in contract related mediation.
While the OpenStack board is the next level for me, I am fully capable of stepping up to the position.
The OpenStack Board has high level business contacts with the 150 companies that are supporting the OpenStack initiative and should be the best source of where these companies think OpenStack is with regard to being a ubiquitous cloud computing platform and where it needs to go in the near and mid future. The board needs to ensure the OpenStack brand offers a clear and compelling set of offerings. For all of this to happen, the board needs to act as high level stratigist, advisor, business mentor, and reality check to the OpenStack contributing communities. It needs to inform the development community of the short and long term needs of the business communities -- the endusers, the consultants, the vendors, the cloud providers. It needs to provide advice on where the development community needs more focus (compelling capabilities). It needs to provide priorities in development to maintain and grow the OpenStack user base (-ilities themes). It needs to engage the corporate community in providing the needed resources to support OpenStack's priorities. It needs to engage the users in gathering the data on what works in OpenStack, what doesn't, and how the users would like to see it move forward.
The Board's input should be the plans of the developers (including information on areas not planned because of lack of resources), the feedback of the users and the roadmaps of the corporate participants. The Board's output should be recommendations for Development roadmaps and priorities based on the inputs it gathers, focused outreach to the corporate community to fill the needs not being met, and management of the IP, marketing and communications of the communities and the Foundation to protect,evangelize, and grow the OpenStack brand and speed OpenStack adoption.
The Board needs to focus on barriers to adoption of OpenStack. Most of the barriers are actively being worked on, but they still require sheparding and status checks. These barriers include:
* The time needed from installation to production deployment. The issues behind this are manyfold and include: inconsitencies in APIs across project boundaries; configuration information scattered across multiple system locations with no global configuration option available; little information on additional software and systems (notably monitoring) needed to be configured and in place before a cloud can move to production; etc.
* The time needed to analyze, test and rollout upgrades from one OpenStack Release to a later one +1 or worse +n versions newer. Several barriers include: live migration not complete; database upgrades; custom configuration maintained across upgrades; changes in software feature behaviors; etc.
* Gaps in features/capabilities needed by various verticals before adoption is an option: scalability; federation - including identity, policy, control plane management; etc.
* Clarity of OpenStack as products: What is OpenStack? What are the projects in the big tent? How do you differentiate between them? How do you define interoperability when the configurations and options need a database to track? Are DefCore and Interoperability the same?
There are quite a number of obstacles the board needs to prioritize and tackle. The first task is to examine the current priorities and determine if they are being addressed and if they need to be adjusted. Without more insight into the needs of current and potential OpenStack users (yes, there is some data in the user survey, but I am hoping some exists also from the contributing companies), I can't say what the top *priority* should be, but I have listed a number of the top priorities to be considered in the running.
Rochelle has already been nominated by: