[openstack-dev] [all] Onboarding rooms postmortem, what did you do, what worked, lessons learned

Miguel Lavalle miguel at mlavalle.com
Mon May 22 18:28:39 UTC 2017


Project: Neutron
Attendees: ~15

Neutron's session was a combination of a slide presentation (
https://www.slideshare.net/MiguelLavalle/openstack-neutron-new-developers-on-boarding)
with predefined exercises on the DevStack VM that was used during the
OpenStack Upstream Institute the weekend prior to the Summit. This is what
we did in more detail:

   - Introduce team members present in the room: Kevin Benton, Armando
   Migliaccio, Swaminathan Vasudevan and Brian Haley, We thought this was
   important to send the message that we are an open and welcoming community /
   project / team.
   - Quick overview of Neutron team organization, IRC meetings and the
   concept of the Neutron Stadium of related projects. We also showed the
   project's mascot and handed out stickers.
   - We didn't want to make any assumptions as to prior knowledge of the
   attendees, so we started from the beginning. We reviewed the concepts
   associated to ReST APIs from the point of view of Neutron. We gave them the
   exercise to create and update a port using the OpenStack client with the
   --debug option and then we reviewed the different pieces of the requests
   and responses: HTTP verb, Neutron endpoint, URI, response code, etc. We
   used annotated slides with examples to show these pieces.
   - Neutron's plug-in based architecture, core resources, core plug-in,
   extensions and service plug-ins. The exercise was to list the extensions
   configured in their DevStacks, set-up a new extension in the configuration
   files, re-start the Neutron server and see the attributes added by the new
   extension to ports using the client.
   - Back-end implementation: L2 agent. With graphic slides we reviewed how
   a port is connected to a virtual network using the integration bridge, the
   other bridges that are part of the landscape and we followed the flow of
   the L2 agent wiring a port for Nova. The exercise was to boot an instance,
   use ovs-vsctl and brctl to see how the port was wired and looked at related
   pieces of code in the OVS agent and RPC classes.
   - Back-end implementation: L3 agent. With graphic slides we reviewed how
   routers and floating ips are processed and the different types of routers
   (legacy, DVR, HA, etc.). The exercise was to associate a floating ip to the
   port of the instance created in the previous exercise and using
   iptables-save, examine the entries added by the floating ip creation. We
   also looked at relevant code in the agent and  RPC classes.
   - The ML2 plug-in. We reviewed the relationship of the ML2 plug-in and
   the DB plug-in and then, using slides with annotated pseudo-code, went over
   the inner working of the ML2 plug-in: the initiation of the DB transaction,
   pre-commit and post-commit mechanism driver methods, network and port
   contexts, type drivers, port binding, the creation of the response
   dictionary and how all these elements contribute and can affect the DB
   performance. The exercise was to review actual code and then add a
   LOG.debug statement to log the vif_type attribute resulting from a port
   binding.

It is important to mention that the 90 minutes originally scheduled weren't
long enough to cover all these topics. Since the level of interest was so
high among the audience, we decided to try to get together the following
day. With the help of the Foundation support team, we were able to schedule
a 1 hour follow up session that was attended by about a third of the
audience and where we were able to finish all the agenda.


What went well:

   - Current Neutron team members welcoming the on-boarding attendees.
   - The fact that audience members actually showed up for a follow up
   session on Thursday at 3pm and their comments at the end (there was even
   some clapping), suggests that the combination of practical exercises and
   the slides did a good job training the prospective new team team members.
   - The prompt response of the Foundation team to schedule a follow up
   session.


What needs improvement:

   - Make the OpenStack Up-Stream Institute DevStack an explicit requisite
   for the on-boarding session. While many of our attendees had the VM, many
   didn't. I think the importance of this is illustrated by the fact that the
   people motivated enough to show up for the follow up session all had the VM
   in their laptops and followed the exercise to the very end.
   - More time. In our experience, a 3 hours session with a break would be
   ideal. Given the importance for the community of bringing in new developers
   and the fact that our audience was willing to attend a follow up session, a
   3 hours up front investment in new talent seems reasonable.


On Mon, May 22, 2017 at 8:11 AM, Alexandra Settle <a.settle at outlook.com>
wrote:

> Project: Documentation and I18N
> Attendees: 3-5 (maybe?)
> Etherpad: https://etherpad.openstack.org/p/doc-onboarding
>
> What we did:
>
> We ran the session informally based off whoever was there. Due to the
> small attendance, we just ran through how the project works (docs like code
> and all that).
> Discussed the docs ML, IRC, and how best to get started (find some low
> hanging fruit). Ian also took the group through the translation team
> process, and gave a little demo on how the Zanata translation tool was used.
>
> We gave everyone back 30 minutes of their lives.
>
> On 5/19/17, 2:22 PM, "Sean Dague" <sean at dague.net> wrote:
>
>     This is a thread for anyone that participated in the onboarding rooms,
>     on either the presenter or audience side. Because we all went into this
>     creating things from whole cloth, I'm sure there are lots of lessons
>     learned.
>
>     If you ran a room, please post the project, what you did in the room,
>     what you think worked, what you would have done differently. If you
>     attended a room you didn't run, please provide feedback about which one
>     it was, and what you thought worked / didn't work from the other side
> of
>     the table.
>
>     Hopefully we can consolidate some of that feedback for best practices
>     going forward.
>
>         -Sean
>
>     --
>     Sean Dague
>     http://dague.net
>
>     ____________________________________________________________
> ______________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:
> unsubscribe
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170522/06ae599b/attachment.html>


More information about the OpenStack-dev mailing list