Ops Meetups give people who run clouds a place to congregate, swap best practices, ideas and give feedback. It has a mostly round table/working/discussion session feel, with only a small number of presentations, with the following aims:
- Gather feedback on the issues that come up in running OpenStack and work to communicate this throughout the community
- Create a forum in which to share best practices and architectures between interested parties
- Increase constructive, proactive involvement from those running clouds
Ops Meetups are typically held as part of the 6-monthly design summit, and also once "mid-cycle". Previous and upcoming Ops Meetups are listed below:
- 1 "M" release (Tokyo, October 2015)
- 2 Mid-Cycle (?, 2015)
- 3 "L" release (Vancouver, May 2015)
- 4 Mid-Cycle (Mar, 2015)
- 5 Kilo (Paris, November 2014)
- 6 Mid-cycle (San Antonio, August 2014)
- 7 Juno (Atlanta, May 2014)
- 8 Mid-Cycle (San Jose, March 2014)
- 9 Moderators Guide
- 10 How Ops Meetups are planned
"M" release (Tokyo, October 2015)
Mid-Cycle (?, 2015)
"L" release (Vancouver, May 2015)
Mid-Cycle (Mar, 2015)
- March 9th and 10th, Philadelphia, USA
- planning etherpad
Kilo (Paris, November 2014)
Mid-cycle (San Antonio, August 2014)
Juno (Atlanta, May 2014)
Mid-Cycle (San Jose, March 2014)
Thank you very much for stepping up to be moderators at the ops meetup. Your work is key to our success!
You are in control of your sessions, however, this document lay down some ideas about what we've seen in the past makes a good session, in case it helps.
We have two different types of sessions. General Sessions and Working Groups. Below, I've separated them out so you can read what's relevant to you.
We have three overall aims:
- Gather feedback on the issues that come up in running or using OpenStack and work to communicate this throughout the community
- Create a forum in which to share best practices and architectures between interested parties
- Increase constructive, proactive involvement from those running or using clouds
Basically, it's you, an etherpad, and room full of a couple hundred people who have OpenStack experience. As the moderator, your efforts result in actionable things we can work on, and the satisfied audience.
- Introduce yourself to the audio guy or gal. You'll be provided with a microphone and asked about laptop connection.
- The best thing to do is convince one of your friends to control the laptop. Get them to control the display of the etherpad, and if it gets big, scroll up and down to ensure the most relevant parts are seen.
- At the start of the session give a 30 second intro to the etherpad, and ask everyone to take notes using it. (Many attendees will not be used to etherpads)
- Kick off the discussion on time, perhaps by starting with some open ended questions, or a show of hands to understand the audience
- Aim to get it to that nirvana state, where the conversation continues without your help
- Don't fall into "Question and Answer" mode - just because you're up the front of the room, some people might expect you to do this. Steer back toward discussion always.
- There will be microphone hogs. Do not be afraid to cut them off. Using language like "Thank you, that is important, we have recorded that on the etherpad" will mean there'll be no hard feelings.
- If you see a nice transition between different topics, take it!
- Most importantly: try and aim for every discussion to have at least one action item - something we can work on. If we don't do this, people are going to stop coming to these things
Overall, have fun! Also *be* fun! If you get bored, the audience will sense it - so if it happens start a new topic. Spontaneity is good! Asking people to do things (file a bug, start a mailing list post) is good!
Working Groups - "Small, working sessions"
These sessions are for a focus on specific topics, and they are long sessions (normally 80 minutes) so you can actually, legitimately get work done - not just talk.
You'll have yourself, and a small group of people who are experienced with OpenStack and actually very interested in getting involved. It's your job as facilitator to try and convert each and every one of these people into a proactive member of your working group, ideally continuing their tenure well after the summit.
Since these are mostly longer session, and about much more specific things, it requires a bit more planning. For some of the groups, you will have met before and have work and processes to continue. Try and seed your etherpads with this information prior to the session.
Try and think of some concrete things that can be done during your time, but also be ready and open to the suggestions of the attendees. If there's a great idea that everyone believes in, go for it and get it done. File bugs. File blueprints. Submit patches. Write documents. Use the whiteboard. You have time for all of this
Of course, all of this information is general. You are the rockstars here - do whatever you think is best . Tom will be on hand for much of the two days for assistance. (call +886 98833 1200 if anything goes horribly wrong)
There are also a few sessions which are a bit different...
Architecture Show and Tell
This is a series of lightening talks - basically a 5-8 minute talk about something cool about your deployment.
Pre-and Post Meetup
Fully realising you are a volunteer with limited time and that you might not get around to any of this, some of the things that are cool to do before or after the meetup are:
- Post a thread on the ops ML asking for ideas for your session (and also advertising it)
- Giving a tweet out with the schedule details
- Filling in the etherpad with some conversation start topics (or, if you are a developer looking for feedback - questions you would like answered)
- Posting on the Ops ML a summary of the session and linking to the etherpad for those who couldn't make it
- Writing a new wiki page under the Operations page with a summary of best practices/new tools you discovered etc
- Following up on action items that people volunteered to do during the meetup ;)
- Organising a followup IRC meeting, if applicable
How Ops Meetups are planned
To be completed
Choosing the topics for the meetup is very important. You want to ensure that you have a reasonable balance between feedback gathering (especially covering current burning issues), best practice sharing, and sessions that get people actually participating.
The general principle here is to get wide feedback - you don't want to have entirely the same topics every meetup, and you definitely don't want to always have the same people making the suggestions (lest it results in an Echo Chamber).
To date, how this has worked has been an etherpad, such as https://etherpad.openstack.org/p/YVR-ops-meetup, seeded with information about the aims and session types of the ops meetup with the following sections for soliciting feedback:
- Session Ideas - General Sessions
- Session Ideas - Working Groups
- Architecture Show & Tell (if you want to present, list your name and email below)
- Moderator volunteers (list your name and email below, along with the sessions you could lead)
Seeding a few known good sessions in each section to provide examples works well, and encouraging a few people to give +1s on their favourite session ease others who aren't as familiar with etherpad into this behaviour.
...To be completed ...
Room Selection, Layout & co-location
So, the hardest rooms to get are the 'big' ones, for our full room discussion.
For the 'big' rooms, there is an argument to maximise attendance somewhat, unlike the 'small' rooms where ideally we want only dedicated/interested people. Co-locating the larger rooms means that we basically have a lot more people we trap in our track for the entire time, by ensuring there's always something interesting for them going on.
With good attendance numbers for the larger sessions, it ensures that the "feedback" aim of the events can be achieved in a broad manner, grabbing the widest views possible from the largest number of people.
However, at 3 parallel rooms, it becomes quite difficult to schedule things so that people can generally get to everything they want to see So, these above argument breaks for large numbers of parallel rooms. I think 3 is about the limit for a single day. If we were ever to need 7 more slots, then we should definitely split the large rooms over multiple days.
Regarding the 'small' rooms - it's quite a bit different. We're not trying to maximise attendance overall, but it is a lot more important that people can get to the groups they want to - like the design summit overall. These are co-located just to avoid Thierry going insane He works so hard to get the schedule sorted out nicely for all the design summit projects. If there's a problem with other tracks in the design summit that want to switch some stuff to Wednesday, I'd be completely open to moving some of our stuff around this summit.
There's also the days themselves to consider: Tuesday, Wednesday and Thursday are probably the 'better' days to have sessions - more than a few people arrive late and miss parts of Monday and leave early and miss parts of Friday.
Conflicts in the layout grid is something to consider very heavily and get sanity checking from others on.
Some times it just works out, for example, the Ops Summit "101" being up against two very technical/advanced topics, since there are definitely different audiences there.
There are also some topics where only certain classes of people care, and so you have to make sure that other more general topics are available so people stick around. eg if you're not running cinder, interested in multiple sites or federation, and they're the only things that are on ... what should you do for 40 minutes?
Then there are the topics that have shared interest. People interested in federations are also likely interested in multi-site clouds, so it isn't appropriate to co-schedule these. Similarly, people interested in billing are also probably interested in legacy applications.
Use best judgement, and get wide feedback.