[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