<div dir="ltr"><div><div>Project: Neutron<br></div>Attendees: ~15<br><br></div>Neutron's session was a combination of a slide presentation (<a href="https://www.slideshare.net/MiguelLavalle/openstack-neutron-new-developers-on-boarding">https://www.slideshare.net/MiguelLavalle/openstack-neutron-new-developers-on-boarding</a>) 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:<br><ul><li>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.<br></li><li>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. <br></li><li>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.</li><li>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.</li><li>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.</li><li>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.</li><li>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.</li></ul><p>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.</p><p><br></p><p>What went well:</p><ul><li>Current Neutron team members welcoming the on-boarding attendees.</li><li>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.<br></li><li>The prompt response of the Foundation team to schedule a follow up session.<br></li></ul><p><br></p><p>What needs improvement:</p><ul><li>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.</li><li>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.<br></li></ul></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 22, 2017 at 8:11 AM, Alexandra Settle <span dir="ltr"><<a href="mailto:a.settle@outlook.com" target="_blank">a.settle@outlook.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Project: Documentation and I18N<br>
Attendees: 3-5 (maybe?)<br>
Etherpad: <a href="https://etherpad.openstack.org/p/doc-onboarding" rel="noreferrer" target="_blank">https://etherpad.openstack.<wbr>org/p/doc-onboarding</a><br>
<br>
What we did:<br>
<br>
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).<br>
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.<br>
<br>
We gave everyone back 30 minutes of their lives.<br>
<span class="im HOEnZb"><br>
On 5/19/17, 2:22 PM, "Sean Dague" <<a href="mailto:sean@dague.net">sean@dague.net</a>> wrote:<br>
<br>
This is a thread for anyone that participated in the onboarding rooms,<br>
on either the presenter or audience side. Because we all went into this<br>
creating things from whole cloth, I'm sure there are lots of lessons<br>
learned.<br>
<br>
If you ran a room, please post the project, what you did in the room,<br>
what you think worked, what you would have done differently. If you<br>
attended a room you didn't run, please provide feedback about which one<br>
it was, and what you thought worked / didn't work from the other side of<br>
the table.<br>
<br>
</span><span class="im HOEnZb"> Hopefully we can consolidate some of that feedback for best practices<br>
going forward.<br>
<br>
-Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" rel="noreferrer" target="_blank">http://dague.net</a><br>
<br>
</span><div class="HOEnZb"><div class="h5"> ______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div>