MANCHESTER, England — Working on OpenStack development has its rewards. The folks who gathered at the first European Operator’s Meetup – some traveling from as far away as Japan and Australia – cited plenty of benefits from contributing to OpenStack. These included getting bugs fixed, designing the future of the project from an operators point of view and contributing new capabilities that help the larger community.
That said, it’s not always easy. Here are some common pain points along with ways to smooth them over. You can read all the notes and resources from the session on the Etherpad. All the Etherpads from the two-day meetup, which took place at the windswept Salford Quays, are available online. Sponsors included Canonical, Codethink, Datacentred and Midokura.
Your team is small but the project is supersized
Matt Jarvis, head of cloud at Datacentred and one of the organizers, launched the session with a common problem to Europeans. “Many of us work for small or medium enterprises, on teams of 10 engineers or so. Having been inside IBM and worked at startups, I can attest that in a smaller company it’s challenging to find time — other than when you have a bug that’s absolutely critical for you — to contribute on a regular basis.” His sentiment was echoed by many of the operators present, who cited “small team, high workload” as a frequent problem.
• If your organization permits, split hours can help with time zone problems and help share the workload.
• And if busy operators tend to find workarounds and get on with it, taking the time to file bugs in Launchpad can save you time and headaches in the long run.
• About those workarounds, you’ll find more of them from operators just like you over at OSOps tools-contrib, what’s been a “dumping ground” for handy tools and shortcuts contributed by the community. Read more about what you’ll find there and how to get involved.
Getting involved is a steep learning curve
“The initial setup to be able to contribute can be a bit intimidating,” noted several participants. And the first big commit, code style, maybe the same as previous point.
Solutions: Getting everyone signed up for all the accounts was also cited as a problem, “[you] need a half a day to get all the accounts and get through the process,” one commenter noted.
Get started with: http://docs.openstack.org/infra/manual/developers.html#getting-started
• The Infra team members present also noted that the is working on fixing things – including moving from Launchpad ID to OpenStackID to make the process easier.
• If you’re attending the Summit, get your team to Upstream Training for a head start. In the two-day training students pick a real bug to work on, set up a development environment, get online accounts for all the tools, sign the contributor license agreements and learn about the workflow release cycle. More about what it’s like here
Staying current is a challenge
Solutions: If you’re already not on the dev-ops mailing list, that’s a good place to start. Pro tip: filter your email for project tags [in brackets] that interest you. If you have usage questions, check out Ask OpenStack.
The busiest channel for Ops discussions is IRC, but only about half of the hundred or so participants at the Meetup are active on the #openstack-operators channel. “The IRC logs are lovely reading first thing in the morning, over coffee,” joked Monty Taylor, an OpenStack board member whose day job is at IBM.
Few of the participants were aware of or had participated in the of bi-weekly OSOps Meetings on IRC:
Mike Perez, cross-project developer coordinator at the OpenStack Foundation, also writes up a weekly summary of the dev mailing list discussions — it’s available on the ops mailing list and dev mailing list on Fridays. An example: http://lists.openstack.org/pipermail/openstack-operators/2016-February/009516.html
It’s also cross-posted on the OpenStack blog.
Between sessions at the Meetup in the Level 7 lounge.
You’re running a release (or two or more) behind and having trouble finding resources or running into bugs
“It’s hard to catch up what’s going on upstream when it can take over a year to get a full production-ready cloud,” says Workday’s Edgar Magana. “The people on my team are discovering bugs that are not backported… And there’s an amazing amount of time that a developer has to invest if not fixing a bug that’s a typo.”
This is a situation where Google can turn up old results (or bury results that reference the earlier releases) leading to a ton of frustration.
Solutions: The Docs team at work on the problem
For now, session moderator Jesse Pretorius of Rackspace says that for finding older documentation, it may be helpful to look for documentation from vendors who provide OpenStack packages as a product. These write-ups may have their own peculiarities for the specific product but will provide a “reasonable reference.”
One final suggestion: find time to answer the User Survey to ensure that your voice is heard and shared.