Final OpenStack Voting Push, we’re still short [update: we made it]

20121014-132246.jpgThere are still a LOT (more than 75%) of OpenStack community members who have not voted.  If you are in that number, please cast your ballot.

[NOTE 1/16: We made it!  OpenStack reach quorum at 7pm on Thursday – 20 hours before the polls close]

Have you voted and tired of these messages?  Your bylaws vote (yes or no) means nothing if we do not reach quorum.  So, contact your OpenStack friends and make sure they voted.

If you think you should have gotten a ballot, but can’t find it.  Please contact ‘secretary@openstack.org’ to check it out.

While inactive members have been removed from the system, there are some people whose ballots did not arrive (like mine) and had to ask for it to be resent.

PS: Yes, that is Niki Acosta with me in Boston.

 

OpenStack PSA: Individual members we need more help – Please Vote!

1/17 Update: We did it!  We reached quorum and approved all the changes!  Also, I am honored to have been re-elected to the Board.  Thank you for the support.

I saw the latest report and we’ve still got a LONG WAY TO GO to get to the quorum that we need.  Don’t let your co-worker or co-contributor be the one missing vote!

Note: If you thing you should have gotten a ballot email but did not.  Contact the OpenStack Election Secretary for assistance.  OpenStack voting is via YOUR PERSONALIZED EMAIL only – you cannot use someone else’s ballot.

Here’s the official request that we’ve been forwarding in the community

OpenStack Individual Members we need your help – Please Vote!

Untitled drawingIncluded on the upcoming individual elections ballot is set of proposed bylaw changes [note: I am also seeking re-election]. To be enacted, these changes require approval by the individual members. At least 25% of the Individual Members must participate in this election in order for the vote to take effect which is why we are reaching out to you. The election will start Monday January 12, 2015 and run thru Friday January 16, 2015.

The unprecedented growth, community size and active nature of the OpenStack community have precipitated the need for OpenStack Bylaw updates. The updates will enable our community to adapt to our continued rapid growth, change and diversity, while reflecting our success and market leadership. Although the proposed changes only effect a small set of verbiage in the bylaws, the changes eliminate some of the hard coded values and naive initial assumptions that found their way into the bylaws when they were initially created in 2013. Those initial assumptions did not anticipate that by 2015 we would have such a large, active community of over 17,000 individual members, over 430 corporate members, and a large diverse set of OpenStack based products and services.

Through many months of community iterative discussion and debate, the DefCore team and board have unanimously accepted a set of changes that are now placed before you for your approval. The changes replace the original hard coded “core” definition with a process for determining the software elements required for use of the OpenStack commercial trademark. Processes which will also account for future revisions and determinations for Core and Trademark Policy.

Note: Another change sets the quorum level at a more reasonable 10%, so these PSAs should not be required in the future.

Complete details on the proposed changes are located at:
https://wiki.openstack.org/wiki/Governance/Foundation/2014ProposedBylawsAmendment

Complete details on the 2015 Board Election are located at:
http://www.openstack.org/election/2015-individual-director-election/

Online Meetup Today (1/13): Build a rock-solid foundation under your OpenStack cloud

Reminder: Online meetup w/ Crowbar + OpenStack DEMO TODAY

HFoundation Rawere’s the notice from the site (with my added Picture)

Building cloud infrastructure requires a rock-solid foundation. 

In this hour, Rob Hirschfeld will demo automated tooling, specifically OpenCrowbar, to prepare and integrate physical infrastructure to ready state and then use PackStack to install OpenStack.

 

The OpenCrowbar project started in 2011 as an OpenStack installer and had grown into a general purpose provisioning and infrastructure orchestration framework that works in parallel with multiple hardware vendors, operating systems and devops tools.  These tools create a fast, durable and repeatable environment to install OpenStack, Ceph, Kubernetes, Hadoop or other scale platforms.

 

Rob will show off the latest features and discuss key concepts from the Crowbar operational model including Ready State, Functional Operations and Late Binding. These concepts, built into Crowbar, can be applied generally to make your operations more robust and scalable.

Voting time for OpenStack! Your help needed to push Bylaws & DefCore forward.

1/17 Update: We did it!  We reached quorum and approved all the changes!  Also, I am honored to have been re-elected to the Board.  Thank you for the support!

What does OpenStack mean to you?

Vote Now!To me, it’s more than infrastructure software: it’s a community of people and companies working together in revolutionary way.  To make that work, we need people who invest time to bring together diverse interests and perspectives.

I have worked hard to provide neutral and inclusive view points on the OpenStack board.  The critical initiatives I focused on [DefCore, Gold Membership, Product Managers] need focused leadership to progress.  I have proven my commitment to those efforts and would be honored to be re-elected [see my platforms for 2012, 2013 & 2014].

But more important than voting for me, is that we reach a 25% quorum!

Why?  Because there are critical changes to the OpenStack bylaws on the ballot.

What type of changes?  Basically, the changes allow OpenStack governance to keep up with the pace of our evolution.    These are pragmatic changes that have been thoroughly discussed in the community.  They enable OpenStack to:

  • set a smarter quorum – past elections only achieved half the required turn out to changes the bylaws
  • enable the DefCore process – current core is defined as simply using code in select projects.
  • improve governance of required committees
  • tweak release language to match current practice,

To hit 25%, we need everyone, not just the typical evangelists to encourage voting.  We need you to help spread the word and get others to do the same.

I’m counting on you, please help. 

Research showing that Short Lived Servers (“mayflies”) create efficiency at scale [DATA REQUESTED]

Last summer, Josh McKenty and I extended the puppies and cattle metaphor to limited life cattle we called “mayflies.” It was an attempt to help drive the cattle mindset (I think of it as social engineering, or maybe PsychOps) by forcing churn. I’ve come to think of it a step in between cattle and chaos monkeys (see Adrian Cockcroft).

While our thoughts were on mainly ops patterns, I’ve heard that there could be a real operational benefit from encouraging this behavior. The increased turn over in the environment improves scheduler optimization, planned load drains and coping with platform/environment migration.

Now we have a chance to quantify this benefit: a college student (disclosure: he’s my son) has created a data center emulation to see if Mayflies help with utilization. His model appears to work.

Now, he needs some real world data, here’s his request for assistance [note: he needs data by 1/20 to be included in this term]:

Hello!

I am Alexander Hirschfeld, a freshman at Rose-Hulman Institute of Technology. I am working on an independent study about Mayflies, a new idea in virtual machine management in cloud computing. Part of this management is load balancing and resource allocation for virtual machines across a collection of servers. The emulation that I am working on needs a realistic set of data to be the most accurate when modeling the results of using the methods outlined by the theory of mayflies.

Mayflies are an extension of the puppies verses cattle approach to machines, they are the extreme version of cattle as they have a known limited lifespan, such as 7 days. This requires the users of the cloud to build inherently more automated and fault-resistant applications. If you could send me a collection of the requests for new virtual machines(per standard unit of time and their requested specs/size), as well as an average lifetime for the virtual machines (or a graph or list of designated/estimated life times), and a basic summary of the collection of servers running the virtual machines(number, ram, cores), I would be better able to understand how Mayflies can affect a cloud.

Thanks,
Alexander Hirschfeld, twitter: @d-qoi

Needless to say, I’m really excited about the progress on demonstrating some the impact of this practice and am looking forward to posting about his results in the near future.

If you post in the comments, I will make sure you are connected to Alex.

OpenCrowbar v2.1 Video Tour from Metal to OpenStack and beyond

With the OpenCrowbar v2.1 out, I’ve been asked to update the video library of Crowbar demos.  Since a complete tour is about 3 hours, I decided to cut it down into focused demos that would allow you to start at an area of interest and work backwards.

I’ve linked all the videos below by title.  Here’s a visual table on contents:

Video Progression

Crowbar v2.1 demo: Visual Table of Contents [click for playlist]

The heart of the demo series is the Annealer and Ready State (video #3).

  1. Prepare Environment
  2. Bootstrap Crowbar
  3. Add Nodes ♥ Ready State (good starting point)
  4. Boot Hardware
  5. Install OpenStack (Juno using PackStack on CentOS 7)
  6. Integrate with Chef & Chef Provisioning
  7. Integrate with SaltStack

I’ve tried to do some post-production so limit dead air and focus on key areas.  As always, I value content over production values so feedback is very welcome!

10 pounds of OpenStack cloud in a 5 pound bag? Do we need a bigger bag?

Yesterday, I posted about cloud distruptors that are pushing the boundaries of cloud. The same forces pull at OpenStack where we are working to balance between including all aspects of running workloads and focusing on a stable foundation.

Note: I am seeking re-election to the 2015 OpenStack Board.  Voting starts 1/12.

For weeks, I’ve been reading and listening to people inside and outside the community.  There is considerable angst about the direction of OpenStack.  We need to be honest and positive about challenges without simply throwing stones in our hall of mirrors.

Closing 2014, OpenStack has gotten very big, very fast.  We’ve exploded scope, contributions and commercial participants.  Unfortunately, our process infrastructure (especially the governance by-laws) simply have not kept pace.  It’s not a matter of scaling processes we’ve got; many of the challenges created by growth require new approaches and thinking (Thierry’s post).

OpenStack BagIn 2015, we’re trying to put 10 pounds of OpenStack in a 5 pound bag.  That means we have to either a) shed 5 pounds or b) get a bigger bag.  In classic OpenStack style, we’re sort of doing both: identifying a foundational base while expanding to allow more subprojects.

To my ear, most users, operators and business people would like to see the focus being on the getting the integrated release scope solid.  So, in spirit of finding 5 pounds to shave, I’ve got five “shovel ready” items that should help:

  1. Prioritizing stability as our #1 feature.  Accomplishing this will require across the broad alignment of the vendor’s product managers to hold back on their individual priorities in favor of community.  We’ve started this effort but it’s going to take time to create the collaboration needed.
  2. Sending a clear signal about the required baseline for OpenStack.  That’s the purpose of DefCore and should be felt as we work on the Icehouse and Juno definitions.
  3. Alignment of the Board DefCore project with Technical Committee’s Levels/Big Tent initiative.  By design, these efforts interconnect.  We need to make sure the work is coordinated so that we send a clearly aligned message to the technical, operator, vendor and user communities.
  4. Accelerate changes from single node gate to something that’s either a) more services focused or b) multi-node.  OpenStack’s scale of community development  requires automation to validate the new contributions do not harm the existing code base (the gate).  The current single-node gate does not reflect the multi-node environments that users target with the code.  While it’s technically challenging to address this mismatch, it’s also essential so we ensure that we’re able to validate multi-node features.
  5. Continue to reduce drama in the open source processes.   OpenStack is infrastructure software that should enable an exciting and dynamic next generation of IT.  I hear people talk about CloudStack as “it’s not as exciting or active a community but their stuff just works.”  That’s what enterprises and operators want.  Drama is great for grabbing headings but not so great for building solid infrastructure.

What is the downside to OpenStack if we cannot accomplish these changes?  Forks.

I already see a clear pattern where vendors are creating their own distros (which are basically shallow forks) to preserve their own delivery cycle.  OpenStack’s success is tied to its utility for the customers of vendors who fund the contributors.  When the cost of being part of the community outweighs the value, those shallow forks may become true independent products.

In the case of potential forks, they allow vendors to create their own bag and pick how many pounds of cloud they want to carry.  It’s our job as a community in 2015 to make sure that we’ve reduced that temptation.

1/9/15 Note: Here’s the original analogy image used for this post