Jump to: navigation, search

Operations/Meetups

< Operations
Revision as of 16:06, 16 October 2018 by Emccormickva (talk | contribs) (Venue Selection)

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:

  1. Gather feedback on the issues that come up in running OpenStack and work to communicate this throughout the community
  2. Create a forum in which to share best practices and architectures between interested parties
  3. 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:

planning

Rocky release (Vancouver, May 21-24 2018)

Mid Cycle (Tokyo, March 2018)

Queens release (Sydney, November 6-8 2017)

Mid-Cycle (August, 2017)

Pike release (Boston, May 8-11, 2017)

Mid-Cycle (Mar, 2017)

Ocata release (Barcelona, October 2016)

Mid-Cycle (Aug 25-26, 2016)

Newton release (Austin, May 2016)

Mid-Cycle (Feb, 2016)

Mitaka release (Tokyo, October 2015)

Mid-Cycle (August, 2015)

"L" release (Vancouver, May 2015)

Mid-Cycle (Mar, 2015)

  • March 9th and 10th, Philadelphia, USA
  • etherpads

Kilo (Paris, November 2014)

Mid-cycle (San Antonio, August 2014)

Juno (Atlanta, May 2014)


Mid-Cycle (San Jose, March 2014)

Moderators Guide

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:

  1. Gather feedback on the issues that come up in running or using OpenStack and work to communicate this throughout the community
  2. Create a forum in which to share best practices and architectures between interested parties
  3. Increase constructive, proactive involvement from those running or using clouds


General Sessions

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

Ops Meetups are organised by the Ops Meetups Team. This team is an open team that meets regularly - if you are interested in this event, do get in touch!

Here's a high-level timeline of the process:

  • Approximate date/region decided: 5 months before
  • Venue booked: 4 months before
  • Agenda Brainstorming Starts: 2 months before
  • Registration Opens: 2 months before
  • Draft Agenda Release: 1 Month before
  • Agenda Complete: 3 weeks before
  • All moderators found: 2 weeks before
  • Registration Closes: 1 week before (for catering)

Date and Region selection

The Ops Meetups gain much of their timing cues from the OpenStack release cycle. There is always an event at the OpenStack Summit, which is held in a regional rotation:

  • Year 1 - Late April/Early May - North America
  • Year 1 - Late October/Early November - Europe
  • Year 2 - Late April/Early May - North America
  • Year 2 - Late October/Early November - Asia Pacific

There are also events between the summit. These have traditionally been held in February/March and August, however the cadence and regional location is currently being discussed by the Ops Meetups Team.

Based on community feedback, the Ops Meetups Team chooses the approximate dates and regions for events.

Venue Selection

Once an approximate date range (eg "mid-to-late August") and region (eg "North America") is known, work can begin on the venue. Finding a venue that's flexible, yet large enough to fit the growing ops community is always a challenge. Attendance has fluctuated over the years, but have generally ranged from 100 - 200. We have also had a varying number of parallel tracks depending on the facility:

  • Theater/fishbowl style seating for 100-200
    • Note: the Philadelphia mid-cycle in March 2015 had 175+ registrations and approx. 150 people on-site
    • Note: Palo Alto mid-cycle in August 2015 had 303 registrations and approx 195 on site.
    • Note: Manchester mid-cycle in February 2016 had 130 on-site.
  • At least 2 rooms to run parallel breakout sessions or a themed track is desirable but not required.
    • Note: for the mid-cycle meetups, the group often meets all together in the morning, and at the end of the event for a feedback session. The rest of the schedule can be broken out into tracks. For example, in Philadelphia, the main room used in the morning was broken up into two spaces, which were used separately in the afternoon. In Tokyo, the large room was used for general sessions while a smaller room was used for an NFV themed track which was of particular interest to many local attendees.
  • 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. This is sometimes provided by the host, but has also been sponsored separately.
  • 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


We have been extremely fortunate to have had excellent organisations step up and offer their own space, or offer to underwrite a commercial meeting space. If you see someone from an organisation who has hosted one of these events before, please share your gratitude - it's a large part of what makes it possible. A very big thank you to our past hosts:

  • eBay/Paypal
  • Rackspace
  • Comcast
  • HP
  • Datacentred
  • Bloomberg
  • Enter
  • NTT


In May 2016, the Ops Meetups Team decided the most fair way of finding a venue was to email out an open call for venues and see what came back. The key was to facilitate a fair process to choose between proposals, if we had more than one. This call for hosts should happen as soon as the region and approximate date range are decided, to allow the most possible time for planning.

Underwriters

The community strongly believes that Ops Meetups should be non-commercial events, and is willing to accept a cheaper "level of production" instead of being bombarded with marketing. However, running an event does still cost money!

Underwriters are the financial backers of the event. They're organisations who believe in improving OpenStack ops, and usually run clouds themselves. Between them they cover any venue, catering and ancillary costs to run the event. In the past, we've added underwriter names and logos to the registration site, event signage and name badges. We've also allowed a modest number of banners to be placed in the main area, and encouraged a representative from each underwriter to welcome people to the event so their face and brand are known.

In some cases, especially with an in-house venue and in-house catering, the host has also been the underwriter. However, according to OpenStack's event principles, we should facilitate equal participation from all commercial members of the community.

Topic Selection

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).

Scheduling

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.

Managing Conflicts

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.

Finding Moderators

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 <tom@example.org> - 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.

Hints:

  • 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.

Registration

We use the Foundation's Eventbrite page.

Once registration is open, we monitor the numbers, adjust venue/food requirements accordingly and make sure things don't get out of control.

Registration closes about a week before the event. Sometimes earlier if we're in a venue with special security requirements.

Advertising

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.

Generally, the following promotion activities are performed:

  • Email previous Summit attendees that have indicated ops in their registration
  • Email previous attendees of the ops midcycles
  • Remind the Ops Mailing list
  • Tweet from the foundation twitter account
  • Contact the local meetup group

Optionally, some other areas to try are:

  • Email a subset of the ActiveUser Contributors that would benefit from attending the ops midcycle
  • Reach out to user survey respondents who have indicated that they can be contacted

Working with Feedback