A few weeks ago I had the opportunity to attend to the Barcelona OpenStack summit ‘Ocata design session’ and this post is related to collect some overall information about it. In order to achieve this, I’m crawling into my paper notes to highlight the aspects IMHO are relevant.
Sessions list by date.
Tuesday - Oct. 25th
- RDO Booth: Carlos Camacho TripleO composable roles demo (12:15pm-12:55pm)
- What the Heck is OoO: Owls All the Way Down (5:55pm – 6:35)
Wednesday - Oct. 26th
- Anomaly Detection in Contrail Networking (1:15pm-1:29pm)
- Freezer: Plugin Architecture and Deduplication (3:05pm-3:45pm)
- TripleO: Containers - Current Status and Roadmap (3:55pm-4:35pm)
- TripleO: Work Session - Growing the team (5:05pm-5:45pm)
- TripleO: Work Session - CI - current status and roadmap (5:55pm-6:35pm)
Thursday - Oct. 27th
- Zuul v3: OpenStack and Ansible Native CI/CD (11:00am-11:40am)
- The Latest in the Container World and the Role of Container in OpenStack (11:50am-12:30pm)
- TripleO: Upgrades - current status and roadmap (1:50pm-2:30pm)
- Mistral: Mistral and StackStorm (3:30pm-4:10pm)
- Nokia: TOSCA & Mistral: Orchestrating End-to-End Telco Grade NFV (5:30pm-6:10pm)
Friday - Oct. 28th
- TripleO: Work Session - Composable Undercloud deployment with Heat (9:00am-9:20am)
- TripleO: Work Session - GUI, CLI, Validations current status, roadmap, requirements (9:20am-9:40am)
- TripleO: Work Session - Multiple topics - Blueprints, specs, tools and Ocata summary. (9:50am-10:30am)
Beyond the analysis of “What I did there in a week” I want to state a few relevenat facts for me.
Why is important to attend to a design session (My case: Upstream TripleO developer)?
I think when working remotely in OpenStack projects, for example, in such a complex project as TripleO is really hard to know what other people are doing. So forth, design sessions force engineers to realize about your peers work on different OpenStack projects or even in the same project ;)
This will give you some ideas for future features, new services to integrate, issues that you might have in the future among many others. Also for TripleO specific case if you are interested in working in a specific service, you can get into those services sessions to know more about them.
Where is the value for companies when sending engineers to design sessions?
There might be several answers for this question, but I believe the overall answer will be that sending engineers to the design sessions allow engineers to be aligned based on companies goals, mostly for cases when several companies are related to the same project. Also allow team members to know each others, maybe this can be a soft benefit, for me as important as being aligned for future features or architectural agreements.
Is it really mandatory to send people to design sessions?
I think this is not mandatory at all, but at the a relevant factor might be that all knowledge/value generate in those sessions can be delivered and processed by the rest of the team members.
Do attendees gain value when attending to these design sessions?
Off course they will gain lot of value:
- You might have a wrong impression about people on IRC, meeting them in person can change this dramatically ‘or not’.
- Know better and engage with your team members and other peers.
- Better alignment with your project goals.
- Discuss blueprints and have a better understanding about the features life-cycle and roadmap.
- Know what other people are doing.
- Improve you overall knowledge about other projects (This time is for doing that “Not in your free time if you like it like me”).
If we are in a design session, are we in “working mode” or just in “learning mode”?
Hardest question by far, I had the remorse of feeling that I was not working enough. There were a lot of distractions if you wanted to actually make some time for coding or reviewing submissions. But that’s the thing, I believe is good time to align and after the summit you will always have time for coding :)
What about some business alignment?
I believe this is also an important factor to know about how OpenStack evolves with the time, release announcements and how summits are actually evolving.