- 1 "M" release (Tokyo, October 2015)
- 2 Mid-Cycle (August, 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
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:
"M" release (Tokyo, October 2015)
Mid-Cycle (August, 2015)
"L" release (Vancouver, May 2015)
Mid-Cycle (Mar, 2015)
- March 9th and 10th, Philadelphia, USA
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.
If you're moderating this, one of the main duties you have to perform (or delegate) is that of timekeeping - we normally cycle through many talks in each session.
Best practice is to get any slides people are using into one laptop before the start of the session.
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
Finding a venue that's flexible, yet large enough to fit the growing ops community is always a challenge. We have some well-understood requirements for venues, though the numbers continue to increase:
- Theater/fishbowl style seating for 200-300
- Note: the Philadelphia mid-cycle in March 2015 had 175+ registrations and approx. 150 people on-site
- Palo Alto mid-cycle in August 2015 had 303 registrations and approx 195 on site.
- These numbers can increase 2-3 times for the ops meetup hosted at OpenStack Summit
- At least 3 rooms to run parallel working group and breakout sessions
- Note: for the mid-cycle meetups, the group often meets all together in the morning, and then makes use of the breakout rooms in the afternoon. For example, in Philadelphia, the main room used in the morning was broken up into two spaces, which were used seperately in the afternoon
- A reliable wireless network, most likely for 500-600 devices
- Projectors, screens, power strips and whiteboards for every room, several handheld microphones for large room(s)
- Coffee and lunch breaks each day, possibly light breakfast depending on cost
- Note: catering is typically where the largest costs are incurred, especially with increasing numbers
- Convenient access to transport, hotels and other venues (eg for an evening event)
- Signage directing people to the appropriate room
- A registration/welcome table in an appropriate space
- Note: for mid-cycle events hosted at an office building, security requirements can provide additional logistical hurdles
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.
Once the etherpad has run its course - normally for around a couple of weeks, the topics are decanted into a schedule across the rooms available, which is then shared with the community for feedback. Missing topics or topics with conflicts might be identified at this time (see also: Managing Conflicts).
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 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.
Each session needs a moderator. Two methods for finding interested people have been tried in the past - call out on the ops mailing list separate to the agenda drafting/planning, and adding a section on the etherpad. The latter was markedly more successful, so be sure to add a section to the planning etherpad:
Moderator volunteers (list your name and email below, along with the sessions you could lead) * Guide for Moderators: https://wiki.openstack.org/wiki/Operations/Meetups#Moderators_Guide * Tom Name <email@example.com> - Introduction sessions, generally available if none else volunteers
Then, once the planning etherpad has run its course, with a couple of mailing list prompts, and you've scheduled sessions, see how you go in matching up moderators with their area of interest. Moderators tend to write down the specific sessions they want to lead, so start there, then add the generalists, and so on.
The final step is to fill the gaps - where there is no moderator assigned. Write some emails: Ask the existing moderator volunteers, ask the mailing list, and finally - if no moderator can be found, it probably means there is less interest than expected and the session should be replaced with something else.
- Keep in mind that each session takes some time and effort to prepare, so typically don't ask one person to moderate more than two sessions.
- First-time moderators might feel more comfortable working with a co-moderator, as would those tackling a difficult topic.
- Since the work sessions take more prep, two or three moderators can be a good idea.
Just ask Allison ;)
Advertising this event is a balance. We want people who are experienced cloud operators to come - it's an event for them. However, if we broadcast loudly, in addition to our ops friends we'll get lots of attendees who are not that :) We attach a disclaimer to all of our email communication and registration pages in an attempt to avoid beginners accidentally attending and having a negative experience:
***Note***: This event assumes OpenStack ops knowledge and is _not_ appropriate for beginners, or a place to learn about OpenStack. The event contains relatively few 'presentations' and is mostly a discussion-style event. To find other OpenStack events in your area, please visit www.openstack.org/events.
That's obviously too long to put in a tweet, so normally start those with something like "Run an #OpenStack Cloud? ...."
It's also very nice to have some prominent developers attend - so a direct tip-off to those folks is one option, or including a line in the weekly newsletter.