<div dir="ltr">Thank you for the write up. Having missed being there in person it is much appreciated :-)</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 7, 2016 at 5:56 AM, Jeremy Stanley <span dir="ltr"><<a href="mailto:fungi@yuggoth.org" target="_blank">fungi@yuggoth.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm Cc'ing this to the openstack-infra ML but setting MFT to direct<br>
subsequent discussion to the openstack-dev ML so we can hopefully<br>
avoid further cross-posting as much as possible. If you're replying<br>
on a particular session topic, please update the Subject so that the<br>
subthreads are easier to keep straight.<br>
<br>
Apologies for the _extreme_ delay in getting this composed and sent<br>
out!<br>
<br>
<br>
Firehose<br>
--------<br>
<br>
<a href="https://etherpad.openstack.org/p/ocata-infra-firehose" rel="noreferrer" target="_blank">https://etherpad.openstack.<wbr>org/p/ocata-infra-firehose</a><br>
<br>
This was primarily a brainstorming/roadmap session on possible<br>
future plans for the <a href="http://firehose.openstack.org" rel="noreferrer" target="_blank">firehose.openstack.org</a> service. Discussed was<br>
potential to have Zuul (post-v3) both consume and emit events over<br>
MQTT, as well as having StoryBoard (should probably support an<br>
analog of the events handled by lpmqtt at a minimum, probably easy<br>
to add given it already has an RabbitMQ one) and Nodepool event<br>
streams. The gerritbot consumer PoC was mentioned, but determined<br>
that it would be better to shelve that until planning for an<br>
Errbot-based gerritbot reimplementation is fleshed out.<br>
<br>
We talked about how the current logstash MQTT stream implementation,<br>
while interesting, has significant scaling (especially bandwidth)<br>
issues with the volume of logging we do in tests while only offering<br>
limited benefit. We could potentially make use of it in concern with<br>
a separate logstash for production server and Ansible logs, but it's<br>
efficacy for our job logs was called into question.<br>
<br>
We also spent much of the timeslot talking about possible<br>
integration with FedMesg (particularly that they're considering<br>
pluggable backend support which could include an MQTT<br>
implementation), which yields much opportunity for collaboration<br>
between our projects.<br>
<br>
One other topic which came up was how to do a future HA<br>
implementation, either by having publishers send to multiple brokers<br>
and configure consumers to have a primary/fallback behavior or my<br>
trying to implement a more integrated clustering solution with load<br>
balancing proxies. We concluded that current use cases don't demand<br>
anywhere near 100% message delivery and 100% uptime, so we can dig<br>
deeper when there's an actual use case.<br>
<br>
<br>
Status update and plans for task tracking<br>
------------------------------<wbr>-----------<br>
<br>
<a href="https://etherpad.openstack.org/p/ocata-infra-community-task-tracking" rel="noreferrer" target="_blank">https://etherpad.openstack.<wbr>org/p/ocata-infra-community-<wbr>task-tracking</a><br>
<br>
As is traditional, we held a fishbowl on our ongoing task tracking<br>
woes. We started with a brief introduction of stakeholders who<br>
attended and the groups whose needs they were there to represent.<br>
After that, some presentation was made of recent StoryBoard<br>
development progress since Austin (including Gerrit integration,<br>
private story support for embargoed security issues, improved event<br>
timelines, better discoverability for boards and worklists, flexible<br>
task prioritization), as well as the existing backlog of blockers.<br>
<br>
We revisited the Infra spec on task tracking<br>
<a href="http://specs.openstack.org/openstack-infra/infra-specs/specs/task-tracker.html" rel="noreferrer" target="_blank">http://specs.openstack.org/<wbr>openstack-infra/infra-specs/<wbr>specs/task-tracker.html</a><br>
for the benefit of those present, and Kendall Nelson (diablo_rojo)<br>
agreed to pick up and continue with the excellent stakeholder<br>
blocking issues outreach/coordination work begun by Anita Kuno<br>
(anteaya).<br>
<br>
<br>
Next steps for infra-cloud<br>
--------------------------<br>
<br>
<a href="https://etherpad.openstack.org/p/ocata-infra-infra-cloud" rel="noreferrer" target="_blank">https://etherpad.openstack.<wbr>org/p/ocata-infra-infra-cloud</a><br>
<br>
This was sort of a catch-all opportunity to hash out current plans<br>
and upcoming needs for the infra-cloud. We determined that the<br>
current heterogeneous hardware in the in-progress "chocolate" region<br>
should be split into two homogeneous regions named "chocolate" and<br>
"strawberry" (our "vanilla" region was already homogeneous). We also<br>
talked about ongoing work to get a quote from OSUOSL for hosting the<br>
hardware so that we can move it out of HPE data centers, and<br>
attempting to find funding once we have some figures firmed up.<br>
<br>
There were also some sideline discussions on possible monitoring and<br>
high-availability options for the underlying services.<br>
Containerization was, as always, brought up but the usual "not a fit<br>
for this use case" answers abounded. It was further suggested that<br>
using infra-cloud resources for things like special TripleO tests or<br>
Docker registry hosting were somehow in scope, but there are other<br>
solutions to these needs which should not be conflated with the<br>
purpose of the infra-cloud effort.<br>
<br>
<br>
Interactive infra-cloud debugging<br>
------------------------------<wbr>---<br>
<br>
<a href="https://etherpad.openstack.org/p/ocata-infra-infra-cloud-debugging" rel="noreferrer" target="_blank">https://etherpad.openstack.<wbr>org/p/ocata-infra-infra-cloud-<wbr>debugging</a><br>
<br>
The original intent for this session was to try to gather<br>
leaders/representatives from the various projects that we're relying<br>
on in the infra-cloud deployment and step through an interactive<br>
session debugging the sorts of failures we see arise on the servers.<br>
The idea was that this would be potentially educational for some<br>
since this is a live bare metal "production" deployment of Nova,<br>
Neutron, Keystone, Glance, et cetera with all the warts and rough<br>
edges that operators handle on a daily basis but our developers may<br>
not have directly experienced.<br>
<br>
As well-intentioned as it was, the session suffered from several<br>
issues. First and foremost we didn't realize the Friday morning<br>
workroom we got was going to lack a projector (only so many people<br>
can gather around one laptop, and if it's mine then fewer still!).<br>
Trying to get people from lots of different projects to show up for<br>
the same slot on a day that isn't for cross-project sessions is<br>
pretty intractable. And then there's the fact that we were all<br>
approaching burnout as it was the last day of the week and coffee<br>
was all the way at the opposite end of the design summit space. :/<br>
<br>
Instead the time was spent partly continuing the "future of<br>
infra-cloud" discussion, and partly just talking about random things<br>
like troubleshooting CI jobs (some people misunderstood the session<br>
description and thought that's what we had planned) or general Infra<br>
team wishlist items. Not a complete waste, but some lessons learned<br>
if we ever want to try this idea again at a future summit.<br>
<br>
<br>
Test environment expectations<br>
-----------------------------<br>
<br>
<a href="https://etherpad.openstack.org/p/ocata-infra-test-env-expectations" rel="noreferrer" target="_blank">https://etherpad.openstack.<wbr>org/p/ocata-infra-test-env-<wbr>expectations</a><br>
<br>
After the morning break we managed to perk back up again and discuss<br>
test platform expectations. This was a remarkably productive<br>
brainstorming session where we assembled a rough list of<br>
expectations developers can and, more importantly, can't make about<br>
the systems on which our CI jobs run. The culmination of these<br>
musings can since be found in a shiny new page of the Infra Manual:<br>
<br>
<a href="http://docs.openstack.org/infra/manual/testing.html" rel="noreferrer" target="_blank">http://docs.openstack.org/<wbr>infra/manual/testing.html</a><br>
<br>
<br>
Xenial jobs transition for stable/newton<br>
------------------------------<wbr>----------<br>
<br>
<a href="https://etherpad.openstack.org/p/ocata-infra-xenial-stable-newton" rel="noreferrer" target="_blank">https://etherpad.openstack.<wbr>org/p/ocata-infra-xenial-<wbr>stable-newton</a><br>
<br>
Another constructive session right on the heels of the last...<br>
planning the last mile of the cut-over from Ubuntu 14.04 to 16.04<br>
testing. We confirmed that we would switch all jobs for<br>
stable/newton as well as master (since the implementation started<br>
early in the Newton cycle and we need to be consistent across<br>
projects in a stable branch). We decided to set a date (which<br>
incidentally is TODAY) to finalize the transition. The plan was<br>
announced to the dev ML a month ago:<br>
<br>
<a href="http://lists.openstack.org/pipermail/openstack-dev/2016-November/106906.html" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/2016-<wbr>November/106906.html</a><br>
<br>
The (numerous) changes in flight today to switch the lingering jobs<br>
are covered under a common review topic:<br>
<br>
<a href="https://review.openstack.org/#/q/topic:st-nicholas-xenial" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/q/topic:st-nicholas-xenial</a><br>
<br>
<br>
Unconference afternoon<br>
----------------------<br>
<br>
<a href="https://etherpad.openstack.org/p/ocata-infra-contributors-meetup" rel="noreferrer" target="_blank">https://etherpad.openstack.<wbr>org/p/ocata-infra-<wbr>contributors-meetup</a><br>
<br>
At this stage things were starting to wind up and a lot of people<br>
with early departures had already bowed out. Those of us who<br>
remained were treated to our own room for the first time in many<br>
summits (no offense to the Release and QA teams, but it was nice to<br>
not need to share for a change). Since we were a little more at<br>
liberty to set our own pace this time we treated it as a sort of<br>
home base from which many of us set forth to pitch in on<br>
Infra-related planning discussions in other teams' spaces, then<br>
regroup and disseminate what we'd done (from translation platform<br>
upgrades to release automation designs).<br>
<br>
We also got in some good one-on-one time to work through topics<br>
which weren't covered in scheduled sessions, such as Zuul v3 spec<br>
additions or changes to the pep8 jobs to guard against missing sdist<br>
build dependencies. As the afternoon progressed and the crowd<br>
dwindled further we said our goodbyes and split up into smaller<br>
groups to go out for one last meal, commiserate with those who found<br>
themselves newly in search of employment and generally celebrate a<br>
successful week in Barcelona.<br>
<br>
<br>
That concludes my recollection of these sessions over the course of<br>
the week--thanks for reading this far--feel free to follow up (on<br>
the openstack-dev ML please) with any corrections/additions. Many<br>
thanks to all who attended, and to those who could not: we missed<br>
you. I hope to see lots of you again at the PTG in Atlanta, only a<br>
couple months away now. Don't forget to register and book your<br>
flights/lodging!<br>
<span class="HOEnZb"><font color="#888888">--<br>
Jeremy Stanley<br>
</font></span><br>______________________________<wbr>_________________<br>
OpenStack-Infra mailing list<br>
<a href="mailto:OpenStack-Infra@lists.openstack.org">OpenStack-Infra@lists.<wbr>openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-infra</a><br></blockquote></div><br></div>