OpenStack DefCore Community Review – TWO Sessions April 21 (agenda)

Posted on April 15, 2015 by Rob H

During the DefCore process, we’ve had regular community check points to review and discuss the latest materials from the committee. With the latest work on the official process and flurry of Guidelines, we’ve got a lot of concrete material to show.

To accommodate global participants, we’ll have TWO sessions (and record both):

April 21 8 am Central (1 pm UTC) https://join.me/874-029-687
April 21 8 pm Central (9 am Hong Kong) https://join.me/903-179-768

Consult the call etherpad for call in details and other material.

Planned Agenda:

Background on DefCore – very short 10 minutes
- short description
- why board process- where community
Interop AND Trademark – why it’s both – 5 minutes
Vendors AND Community – balancing the needs – 5 minutes
Mechanics
- testing & capabilities – 5 minutes
- self testing & certification – 5 minutes
- platform & components & trademark – 5 minutes
Quick overview of the the Process (to help w/ reviewers) – 15 minutes
How to get involved (Gerrit) – 5 minute

OpenStack DefCore Process Draft Posted for Review [major milestone]

Posted on March 23, 2015 by Rob H

OpenStack DefCore Committee is looking for community feedback about the proposed DefCore Process.

March has been a month for OpenStack DefCore milestones. At the March Board meeting, we approved the first official DefCore Guideline (called DefCore 2015.03) and we are poised to commit the first DefCore Process draft.

Once this initial commit is approved by the DefCore Committee (expected at DefCore Scale.8 Meeting 3/25 @ 9 PT), we’ll be ready for broader input by the community using the standard OpenStack Gerrit review process. If you are not comfortable with Gerrit, we’ll take your input anyway that you want to give it except via telepathy (we’ve already got a lot on our minds).

Note: We’re also looking for input on the 2015.next Guideline targeted for 2015.04,

The DefCore Process documents the rules (who, what, when and where) that will govern how we create the DefCore Guidelines. By design, it has to be detailed and specific without adding complexity and confusion. The why of DefCore is all that work we did on principles that shape the process.

This process reflects nearly a year of gestation starting from the June 2014 DefCore face-to-face. Once of the notable recent refinements was to organize material into time phases and to be more specific about who is responsible for specific actions.

To make review easier, I’ve reposted the draft. Comments are welcome here and on the patch (and here after it lands).

DRAFT: OpenStack DefCore Process 2015A (reposted from OpenStack/DefCore)

This document describes the DefCore process required by the OpenStack bylaws and approved by the OpenStack Technical Committee and Board.

Expected Time line:

Time Frame	Milestone	Activities	Lead By
-3 months	S-3	“preliminary” draft (from current)	DefCore
-2 months	S-2	ID new Capabilities	Community
-1 month	S-1	Score capabilities	DefCore
Summit	S	“solid” draft	Community
Summit	S	Advisory items selected	DefCore
+1 month	S+1	self-testing	Vendors
+2 months	S+2	Test Flagging	DefCore
+3 months	S+3	Approve Guidance	Board

Note: DefCore may accelerate the process to correct errors and omissions.

Process Definition

Continue reading →

Art Fewell and I discuss DevOps, SDN, Containers & OpenStack [video + transcript]

Posted on February 25, 2015 by Rob H

A little while back, Art Fewell and I had two excellent discussions about general trends and challenges in the cloud and scale data center space. Due to technical difficulties, the first (funnier one) was lost forever to NSA archives, but the second survived!

The video and transcript were just posted to Network World as part of Art’s on going interview series. It was an action packed hour so I don’t want to re-post the transcript here. I thought selected quotes (under the video) were worth calling out to whet your appetite for the whole tamale.

My highlights:

.. partnering with a start-up was really hard, but partnering with an open source project actually gave us a lot more influence and control.
Then we got into OpenStack, … we [Dell] wanted to invest our time and that we could be part of and would be sustained and transparent to the community.
Incumbents are starting to be threatened by these new opened technologies … that I think levels of playing field is having an open platform.
…I was pointing at you and laughing… [you’ll have to see the video]
docker and containerization … potentially is disruptive to OpenStack and how OpenStack is operating
You have to turn the crank faster and faster and faster to keep up.
Small things I love about OpenStack … vendors are learning how to work in these open communities. When they don’t do it right they’re told very strongly that they don’t.
It was literally a Power Point of everything that was wrong … [I said,] “Yes, that’s true. You want to help?”
…people aiming missiles at your house right now…
With containers you can sell that same piece of hardware 10 times or more and really pack in the workloads and so you get better performance and over subscription and so the utilization of the infrastructure goes way up.
I’m not as much of a believer in that OpenStack eats the data center phenomena.
First thing is automate. I’ve talked to people a lot about getting ready for OpenStack and what they should do. The bottom line is before you even invest in these technologies, automating your workloads and deployments is a huge component for being successful with that.
Now, all of sudden the SDN layer is connecting these network function virtualization .. It’s a big mess. It’s really hard, it’s really complex.
The thing that I’m really excited about is the service architecture. We’re in the middle of doing on the RackN and Crowbar side, we’re in the middle of doing an architecture that’s basically turning data center operations into services.
What platform as a service really is about, it’s about how you store the information. What services do you offer around the elastic part? Elastic is time based, it’s where you’re manipulating in the data.
RE RackN: You can’t manufacture infrastructure but you can use it in a much “cloudier way”. It really redefines what you can do in a datacenter.
That abstraction layer means that people can work together and actually share scripts
I definitely think that OpenStack’s legacy will more likely be the community and the governance and what we’ve learned from that than probably the code.

Nextcast #14 Transcription on OpenStack & Crowbar > “we can’t hand out trophies to everyone”

Posted on December 26, 2014 by Rob H

Last week, I was a guest on the NextCast OpenStack podcast hosted by Niki Acosta (EMC) [Jeff Dickey could not join]. I’ve taken some time to transcribe highlights.

We had a great discussion about OpenStack, Ops and Crowbar. I appreciate Niki’s insightful questions and an opportunity to share my opinions. I feel that we covered years of material in just 1 hour and I appreciate the opportunity to appear on the podcast.

Video from full post (youtube) and the audio for download.

Plus, a FULL TRANSCRIPT! Here’s my Next Cast #14 Short Transcripton

The objective of this transcription is to help navigate the recording, not replace it. I did not provide complete context for remarks.

04:30 Birth of Crowbar (to address Ops battle scars)
08:00 The need for repeatable Ready State baseline to help community work together
10:30 Should hardware matter in OpenStack? It has to, details and topology matters not vendor.
11:20 OpenCompute – people are trying to open source hardware design
11:50 When you are dealing with hardware, it matters. You have to get it right.
12:40 Customers are hardware heterogeneous by design (and for ops tooling). Crowbar is neutral territory
14:50 It’s not worth telling people they are wrong, because they are not. There are a lot of right ways to install OpenStack
16:10 Sometimes people make expensive choices because it’s what they are comfortable with and it’s not helpful for me to them they a wrong – they are not.
16:30 You get into a weird corner if you don’t tell anyone no. And an equally weird corner if you tell everyone yes.
18:00 Aspirations of having an interoperable cloud was much harder than the actual work to build it
18:30 Community want to say yes, “bring your code” but to operators that’s very frustrating because they want to be able to make substitutions
19:30 Thinking that if something is included then it’s required – that’s not clear
19:50 Interlock Dilemma [see my back reference]
20:10 Orwell Animal Farm reference – “all animals equal but pigs are more equal”
22:20 Rob defines DefCore, it’s not big and scary
22:35 DefCore is about commercial use, not running the technical project
23:35 OpenStack had to make money for the companies are paying for the developers who participate… they need to see ROI
24:00 OpenStack is an infrastructure project, stability is the #1 feature
24:40 You have to give a reason why you are saying no and a path to yes
25:00 DefCore is test driven: quantitative results
26:15 Balance between whole project and parts – examples are Swiftstack (wants Object only) and Dreamhost (wants Compute only)
27:00 DefCore created core components vs platform levels
27:30 No vendor has said they can implement DefCore without some effort
28:10 We have outlets for vendors who do not want to implement the process
28:30 The Board is not in a position to make technical call about what’s in, we had to build a process for community input
29:10 We had to define something that could say, “this is it and we have to move on”
29:50 What we want is for people to start with the core and then bring in the other projects. We want to know what people are adding so we can make that core in time
30:10 This is not a recommendation is a base.
30:35 OpenStack is a bubble – does not help if we just get together to pad each other on the back, we want to have a thriving ecosystem
31:15 Question: “have vendors been selfish”
31:35 Rob rephrased as “does OpenStack have a tragedy of the commons” problem
32:30 We need to make sure that everyone is contributing back upstream
32:50 Benefit of a Benevolent Dictator is that they can block features unless community needs are met
33:10 We have NOT made it clear where companies should be contributing to the community. We are not doing a good job directing community efforts
33:45 Hidden Influencers becomes OpenStack Product group
34:55 Hidden Influencers were not connecting at the summit in a public way (like developers were)
35:20 Developers could not really make big commitments of their time without the buy in from their managers (product and line)
35:50 Subtle selfishness – focusing on your own features can disrupt the whole release where things would flow better if they helped others
37:40 Rob was concerned that there was a lot of drift between developers and company’s product descriptions
38:20 BYLAWS CHANGES – vote! here’s why we need to change
38:50 Having whole projects designated as core sucks – code in core should be slower and less changing. Innovation at the core will break interoperability
39:40 Hoping that core will help product managers understand where they are using the standard and adding values
41:10 All babies are ugly > with core, that’s good. We are looking for the grown ups who can do work and deliver value. Babies are things you nurture and help grow because they have potential.
42:00 We undermine our credibility in the community when we talk about projects that are babies as if they were ready.
43:15 DefCore’s job was to help pick projects. If everyone is core then we look like a youth soccer team where everyone is getting a trophy
44:30 Question: “What do you tell to users to instill confidence in OpenStack”
44:50 first thing: focus on operations and automation. Table stakes (for any cloud) is getting your deployments automated. Puppies vs Cattle.
45:25 People who were successful with early OpenStack were using automated deployments against the APIs.
46:00 DevOps is a fundamental part of cloud computing – if you’re hand-built and not automated then you are old school IT.
46:40 Niki references Gartner “Bimodal IT” [excellent reference, go read it!]
47:20 VMWare is a great crutch for OpenStack. We can use VMWare for the puppies.
47:45 OpenStack is not going to run on every servers (perhaps that’s heresy) but it does not make sense in every workload
48:15 One size does not fit all – we need to be good at what we’re good at
48:30 OpenStack needs to focus on doing something really well. That means helping people who want to bring automated workloads into the cloud
49:20 Core was about sending a signal about what’s ready and people can rely on
49:45 Back in 2011, I was saying OpenStack was ready for people who would make the operational investment
50:30 We use Crowbar because it makes it easier to do automated deployments for infrastructure like Hadoop and Ceph where you want access to the physical media
51:00 We should be encouraging people to use OpenStack for its use cases
51:30 Existential question for OpenStack: are we a suite or product. The community is split here
51:30 In comparing with Amazon, does OpenStack have to implement it or build an ecosystem to compete
53:00 As soon as you make something THE OpenStack project (like Heat) you are sending a message that the alternates are not welcome
54:30 OpenStack ends up in a trap if we pick a single project and make it the way that we are going do something. New implementations are going to surface from WITHIN the projects and we need to ready for that.
55:15 new implementations are coming, we have to be ready for that. We can make ourselves vulnerable to splitting if we do not prepare.
56:00 API vs Implementation? This is something that splits the community. Ultimately we to be an API spec but we are not ready for that. We have a lot of work to do first using the same code base.
56:50 DefCore has taken a balanced approach using our diversity as a strength
57:20 Bylaws did not allow for enough flexibility for what is core
59:00 We need voters for the quorum!
59:30 Rob recommended Rocky Grober (Huawei) and Shamail Tahir (EMC) for future shows

7 Open Source lessons from your English Composition class

Posted on August 11, 2014 by Rob H

We often act as if coding, and especially open source coding, is a unique activity and that’s hubris. Most human activities follow common social patterns that should inform how we organize open source projects. For example, research papers are very social and community connected activities. Especially when published, written compositions are highly interconnected activities. Even the most basic writing builds off other people’s work with due credit and tries create something worth being used by later authors.

Here are seven principles to good writing that translate directly to good open source development:

Research before writing – take some time to understand the background and goals of the project otherwise you re-invent or draw bad conclusions.
Give credit where due – your work has more credibility when you acknowledge and cross-reference the work you are building on. It also shows readers that you are not re-inventing.
Follow the top authors – many topics have widely known authors who act as “super nodes” in the relationship graph. Recognizing these people will help guide your work, leads to better research and builds community.
Find proof readers – All writers need someone with perspective to review their work before it’s finished. Since we all need reviewers, we all also need to do reviews.
Rework to get clarity – Simplicity and clarity take extra effort but they pay huge dividends for your audience.
Don’t surprise your reader – Readers expect patterns and are distracted when you don’t follow them.
Socialize your ideas – the purpose of writing/code is to make ideas durable. If it’s worth writing then it’s worth sharing. Your artifact does not announce itself – you need to invest time in explaining it to people and making it accessible.

Thanks to Sean Roberts (a Hidden Influences collaborator) for his contributions to this post. At OSCON, Sean Roberts said “companies should count open source as research [and development investment]” and I thought he’s said “…as research [papers].” The misunderstanding was quickly resolved and we were happy to discover that both interpretations were useful.

OpenStack DefCore Update & 7/16 Community Reviews

Posted on July 14, 2014 by Rob H

Buy The Shirt! (proceeds to Girls Who Code)

The OpenStack Board effort to define “what is core” for commercial use (aka DefCore). I have blogged extensively about this topic and rely on you to review that material because this post focuses on updates from recent activity.

First, Please Join Our Community DefCore Reviews on 7/16!

We’re reviewing the current DefCore process & timeline then talking about the Advisory Havana Capabilities Matrix (decoder).

To support global access, there are TWO meetings (both will also be recorded):

July 16, 8 am PDT / 1500 UTC
July 16, 6 pm PDT / 0100 UTC July 17

Note: I’m presenting about DefCore at OSCON on 7/21 at 11:30!

We want community input! The Board is going discuss and, hopefully, approve the matrix at our next meeting on 7/22. After that, the Board will be focused on defining Designated Sections for Havana and Ice House (the TC is not owning that as previously expected).

The DefCore process is gaining momentum. We’ve reached the point where there are tangible (yet still non-binding) results to review. The Refstack efforts to collect community test results from running clouds is underway: the Core Matrix will be fed into Refstack to validate against the DefCore required capabilities.

Now is the time to make adjustments and corrections!

In the next few months, we’re going to be locking in more and more of the process as we get ready to make it part of the OpenStack by-laws (see bottom of minutes).

If you cannot make these meetings, we still want to hear from you! The most direct way to engage is via the DefCore mailing list but 1×1 email works too! Your input is import to us!

OpenCrowbar stands up 100 node community challenge

Posted on July 2, 2014 by Rob H

OpenCrowbar community contributors are offering a “100 Node Challenge” by volunteering to setup a 100+ node Crowbar system to prove out the v2 architecture at scale. We picked 100* nodes since we wanted to firmly break the Crowbar v1 upper ceiling.

The goal of the challenge is to prove scale of the core provisioning cycle. It’s intended to be a short action (less than a week) so we’ll need advanced information about the hardware configuration. The expectation is to do a full RAID/Disk hardware configuration beyond the base IPMI config before laying down the operating system.

The challenge logistics starts with an off-site prep discussion of the particulars of the deployment, then installing OpenCrowbar at the site and deploying the node century. We will also work with you about using OpenCrowbar to manage the environment going forward.

Sound too good to be true? Well, as community members are doing this on their own time, we are only planning one challenge candidate and want to find the right target.

We will not be planning custom code changes to support the deployment, however, we would be happy to work with you in the community to support your needs. If you want help to sustain the environment or have longer term plans, I have also been approached by community members who willing to take on full or part-time Crowbar consulting engagements.

Let’s get rack’n!

* we’ll consider smaller clusters but you have to buy the drinks and pizza.

Hugs & Rants Welcome: OpenStack reaching out with “community IRC office hours”

Posted on May 22, 2014 by Rob H

This is a great move by the OpenStack community managers that I feel like is worth amplifying. Copied from community email:

Hello folks

one of the requests in Atlanta was to setup carefully listening ears for developers and users alike so they can highlight roadblocks, vent frustration and hopefully also give kudos to people, suggest solutions, etc.

I and Tom have added two 1 hour slots to the OpenStack Meetings calendar

Tuesdays at 0800 UTC on #openstack-community (hosted by Tom)

Fridays at 1800 UTC on #openstack-community (hosted by Stefano)

so if you have anything you’d like the Foundation to be aware of please hop on the channel and talk to us. If you don’t/can’t use IRC, send us an email and we’ll use something else: just talk to us.

Regards,

Stef

https://wiki.openstack.org/wiki/Meetings/Community

Anyone else find picking OpenStack summit sessions overwhelming?!

Posted on March 3, 2014 by Rob H

The scope and diversity of sessions for the upcoming OpenStack conference in Atlanta are simply overwhelming. As a board member, that’s a positive sign of our success as a community; however, it’s also a challenge as we attempt to pick topics. That’s why we turn to you, the OpenStack community, to help sift and select the content.

Even if you are not attending, we need your help in selection! Content from the summits is archived and has a much larger outside of the two conference days. You’re voice matters for the community.

While it’s a simple matter to ask you to vote for my DefCore presentation and some excellent ones from my peers at Dell, I’d also like share some of my thoughts about general trends I saw illustrated by the offerings:

Swift has a strong following as a solution outside of other products
Ceph seems to emerging as a critical component with Cinder
Neutron has breath but not depth in practice
HA and Upgrades remain challenges
We are starting to see specializations emerge (like NFV)
OpenStack case studies! There are many – some of uncertain utility as references
Some community members and companies are super prolific in submitting sessions. Perhaps these sessions are all great but on first pass it seems out of balance.
Vendor pitch or conference session? You often get both in the same session. We’re still not certain how to balance this.

The number and diversity of sessions is staggering – we need your help on voting.

We also need you to be part of the dialog about the conference and summits to make sure they are meeting the community needs. My review of the sessions indicates that we are trying to serve many different audiences in a very limited time window. I’m interested in hearing yours! Review some sessions and let me know.

OpenStack Board Elections: What I’ll do in 2014: DefCore, Ops, & Community

Posted on January 13, 2014 by Rob H

OpenStack Community,

The time has come for you to choose who will fill the eight community seats on the Board (ballot links went out Sunday evening CST). I’ve had the privilege to serve you in that capacity for 16 months and would like to continue. I have leadership role in Core Definition and want to continue that work.

Here are some of the reasons that I am a strong board member:

Proven & Active Leadership on Board – I have been very active and vocal representing the community on the Board. In addition to my committed leadership in Core Definition, I have played important roles shaping the Gold Member grooming process and trying to adjust our election process. I am an outspoken yet pragmatic voice for the community in board meetings.
Technical Leader but not on the TC – The Board needs members who are technical yet detached from the individual projects enough to represent outside and contrasting views.
Strong User Voice – As the senior OpenStack technologist at Dell, I have broad reach in Dell and RedHat partnership with exposure to a truly broad and deep part of the community. This makes me highly accessible to a lot of people both in and entering the community.
Operations Leadership – Dell was an early leader in OpenStack Operations (via OpenCrowbar) and continues to advocate strongly for key readiness activities like upgrade and high availability. In addition, I’ve led the effort to converge advanced cookbooks from the OpenCrowbar project into the OpenStack StackForge upstreams. This is not a trivial effort but the right investment to make for our community.
And there’s more… you can read about my previous Board history in my 2012 and 2013 “why vote for me” posts or my general OpenStack comments.

And now a plea to vote for other candidates too!

I had hoped that we could change the election process to limit blind corporate affinity voting; however, the board was not able to make this change without a more complex set of bylaws changes. Based on the diversity and size of OpenStack community, I hope that this issue may no longer be a concern. Even so, I strongly believe that the best outcome for the OpenStack Board is to have voters look beyond corporate affiliation and consider a range of factors including business vs. technical balance, open source experience, community exposure, and ability to dedicate time to OpenStack.

Rob Hirschfeld

On Computing, Containers, Cloud & Tech Culture

Tag Archives: community