These are talks I am involved in. I ask that you help vote them up as they represent important topics for the OpenStack community.
Congress defines the desired state of a cluster. Join us to work on this important project.
Congress:Policy as a Service
Developers have managers that define what they work on. It’s in our best interest to get the managers synched with what the developers sign up for at the summits. Let’s discuss ways of improving this.
Hear from from the organizers from successful user groups.
Panel: Tips and Tools for Building a Successful OpenStack Group
OpenStack Ambassadors represent the user groups from around the world. Find out what’s planned to increase the community involvement and spread OpenStack farther and wider.
Meet the OpenStack Ambassadors
An update on the OpenStack Community Training project. What has worked and what is planned.
OpenStack training – Open Source training an enablement for OpenStack
My experience with open source has taught me a few things about partnerships. I have observed the basic rule that partnerships require give and take. The give and take do not happen in regular intervals, so you need to trust the relationship will cycle back and deliver.
I have a deeper observation about source based businesses. There is a bit of sheek lately to state your code is open source. Typical businesses would see this as a hit to the bottom line. The lost licensing fees means support fees have to pick up the slack. What most people fail to see is that this is huge innovation and long lasting partnership opportunity. With your code in the open you will pick up some contributors to your open source project, but what you really want is your customer’s innovation energy and ideas.
Here is my thinking. What is the first thing most people do when they use a product? No matter how amazing it is, we look to the faults. That Bugatti does 250 MPH, but where’s the cup holder? So when a customer of software looks to its faults, they normally have the support call or the account manager to deal with. When the software is open sourced, who is in the best position to work the problem other than the customer? I know this is not the typical software customer role, but it is a common conversation had over OpenStack software. Coming up with innovative solutions to common problems is what the open source community does best. I would mine 10-20% of your customer base as potential development partners.
Do you want your customers as software development partners? I say yes, for two reasons. First a customer will be invested in certain features that they want to exploit. How better to drive innovation than to make them part of the team. Second is that the customer investment in development will translate into a long term relationship with the software. Your development partners are very likely to incorporate the code into production as their own.
So how do you turn a customers into software development partners? It’s easy and hard at the same time. You need to train the interested customer developers to be part of your team of developers. Easy concept, hard to implement. You will need to have solid training tools. Mentors at the ready. Your code (CI) pipeline will need to be reliable and provide code quality feedback. Your mentors will need to do time on the review side of the pipeline. Once you make the switch, your extended team will need the CI pipeline to have reliable operations coverage. We practice much of this right now with OpenStack. We are in the process of creating the training and mentoring that will sustain the projects.
Summarizing the ideas from above, building long term relationships should always be a goal of any project. Innovation happens with the right mix of people, tools, and ideas. Long term innovation equals happy long term customers. In conclusion, open source business done right, broadens the team and makes everyone stronger.
The OpenStack User Groups are meant to be a place where the OpenStack curious and converted can hang out together. Tonight, 05 June 2014, the monthly OpenStack Beginner Session will be held at Yahoo, 700 North First Avenue, Sunnyale, CA. Mirantis will be leading a presentation on OpenStack architecture.
You will find more information on OpenStack SFBay User Group meetings here. See you there!
Here it is! Colin McNamara and Sean Roberts only speak the truth on the state of training.
The first day of the MSST Spring 2014 conference had Ceph front and center. It was a beautiful late spring day on the Santa Clara University campus in California. Jean-Charles Lopez from Inktank led us off with a detailed background in Ceph’s inner workings. The inventor of Ceph, Sage Weil, was on hand to provide an even deeper dive into the internals. Can I summarize by saying that the Object Storage Device is connected to the journal, librados (direct access through libraries), radosgw (REST gateway), libcephfs (POSIX), and librados (block)? I don’t do the hours of presentation justice with one sentence. The whole of the Inktank Ceph presentation can be found here. I can say that between the access flexibility and their CRUSH data placement algorithm, Ceph is an impressive storage solution. We ranged from Ceph on paper to Ceph in action. The session wrapped up with a full tutorial using a pre-built VM to install Ceph v0.67 Dumpling on. It went very smoothly. I learned new things about Ceph and how to run a training session. Thanks Inktank!
We transitioned into the Seagate Kinetic project. Ricky Huynh and Chiaming Yang lead the presentation. Kinetic pushes the boundary of traditional disks. Seagate has shruged off the commodity label and created something new out of their standard disk offering. They have replaced the onboard SATA daughter card with a CPU, an ethernet connector, and an key-value API. This fits nicely with Ceph, so the bottom layer of disk services can be replaced with a Kinetic key-value disk. No more pesky file structures. While this solution doesn’t likely fit all use cases for distributed storage, it is a welcome option in the nascent field of new tricks for spinning platters. Sage Weil pulled double duty by presenting the technical benefits of Ceph on Kinetic. No Kinetic presentations posted yet. I will update this post when they are available.
This was a good day. See you tomorrow.
These are not all the etherpad links nor all the topics discussed. I am posting my interests for your reference. Feel free to link and comment.
We have been working on updating the definition of the Openstack trademark requirements since last summer. Defining the capabilities of OpenStack clusters leads to interopability. The Refstack project is the culmination of the board, the technical committee, and the tempest group’s work. The work is progressing nicely.
CI / Infrastructure
There were a lot of good sessions. Including ideas on replacements for Jenkins and Gerrit. Here are some of the sessions.
improve gate uptime and feedback
juno cycle improvements
elastic recheck, avoid race conditions
turbo-hipster as the replacement for jenkins
improving third party CI pipeline integration
vinz as the replacement for gerrit
We started discussing what the operators needed with a mini summit a few months ago. We followed up on the actionable items with operator summit sessions with the Project Technical Leads. Intel also helped with enterprise talks focusing on interopability between OpenStack and infrastructure service providers. Find the rest of the operations sessions below.
ops governance, user committee
ops arch sharing
Launchpad has outlived its usefulness and storyboard is the replacement is under development. It is looking very promising. Find it’s design session here. I am thinking of adding one of my projects to it as well.
Policy management is a hot topic as we can not build SLAs without it. Each of the OpenStack projects have some policy controls. Congress intends to tie them together. The 3 hour design session notes are here. I have have posted some about the project in past as well. Here are some of the other project policy sessions.
nova policy or tetris blueprint ,
nova concept scheduling server groups
Nova-network parity is critical work. Mark McClain is leading the charge. This work must be achieved in this cycle or returning Neutron to inucubation is on the table for the Technical Committee..
What use is feature parity without a migration path. Obondarev is working on that.
We need to share the review load. The idea of assigning 2 reviewers to a patch for critical, high priority blueprints was discussed. Perhaps a rotation on call. Tracking critical high, critical bugs to resolution was also considered.
Other various, important design sessions listed below.
Additional testing coverage
Lbaas Juno design
LBaas SSL, L7 focus
IPv6 comcast, intel work so far
neutron core refactoring
distributed virtual router, DVR update
We want continuously improve the OpenStack user groups. The ambassador group got together and discussed ideas for kick starting new groups and quality improvements. I will be posting on these ideas soon.
This post is a follow up to a previous post here.
Teaching the OpenStack architecture and services is a good place to begin. That means no installing software until the student is ready to understand what they are installing. The best place to start is going through the basics in the Associates Training Guide and the intermediate topics in the Operators Training Guide first. These Guides are mostly combined from the existing OpenStack documentation. The Training project aims to reuse the existing materials as much as possible.
The Developer Guide deep dives on the OpenStack CI pipeline. We start with the local tools Pycharm, Git, Sourcetree, Maven, and Git-review. Some review of Gerrit etiquette is in order and why resubmission of your code is part of the learning process. We then dive into the CI pipeline tools GitHub, Gerrit, Jenkins, Gearman, Nodepool, Jeepy, Logstash, and Zuul. The student will have five days of classroom and lab time.
The next three days are devoted to learning the OpenStack APIs in depth. We settled on using Django and Horizon to interact with a variety of OpenStack APIs. We aim to teach enough of the OpenStack API details in three days that the student will have a good grasp of how the APIs work. This should be the basis of further API development during the Architect Training. The Developer Training Guide is under development itself. The Developer Training Guide design is posted here.
There is a glaring, purposeful omission in that learning Python is not part of the Training Guides. Python is the language that OpenStack is written in. Understanding Python is required to become an OpenStack developer. There are some great ways to learn Python out there. The main Developer Guide prerequisite is to learn Python. We recommend Python Koans and Learn Python the Hard Way.
The next post will detail how we plan on implementing OpenStack Developer Training at a location near you.