Published: Fri 09 March 2018
In Tech .
tags: events openstack
I was so excited when it was first hinted in Denver that the next
OpenStack PTG would be in Dublin. In my town! Zero jet lag! Commuting
from home! Showing people around! Alas, it was not to be. Thanks,
Beast from the East .
Now everybody hates Ireland forever.
The weather definitely had some impact on sessions and
productivity. People were jokingly then worryingly checking on the
news, dropping in and out of rooms as they tried to rebook their
cancelled flights. Still we did what we could and had snow-related
activities too - good for building team spirit, if nothing else!
I mostly dropped in and out of rooms, here are some of my notes and
sometimes highlights.
OpenStack Client
Like before, the first two days of the PTG were focused on
cross-projects concerns. The OpenStack Client didn't have a room this
time, which seems fair as it was sparsely attended the last couple of
times - I would have thought there'd have been one helproom session at
least but if there was I missed it.
I regret missing the API Working Group morning
sessions on API discovery and micro-versions, which I think were
relevant. The afternoon API sessions were more focused on services and
less applicable for me. I need to be smarter about it next time.
Packaging RPMs
On Tuesday I dropped by the packaging RPMs Working Group
session. A small group made up of very focused RDO/Red Hat/SUSE
people. The discussions were intense, with Python 2 going End Of Life
in under 2 years now.
The current consensus seems to be to create a RPM-based Python 3 gate
based on 3.6. There's no supported distro that offers this at the
moment, so we will create our own Fedora-based distro with only what we
need at the versions we need it. Once RDO is ready with this, it could
be moved upstream.
There were some concerns about 3.5 vs 3.6 as the current gating is done
on 3.5. Debian also appears to prefer 3.6. In general it was agreed
there should not be major differences and generally ok.
The clients must still support Python 2.
There was a little bit of discussion about the stable policy and how it
doesn't apply to the specs or the rpm-packaging project (I think the
example was with Monasca and the default backend not working (?), so a
spec change to modify the backend was backported - which could be
considered a feature backport, but since the project isn't under the
stable policy remit it could be done).
There was a brief chat at the end about whether there is still interest in
packaging services, as opposed to just shipping them as containers. There
certainly still seems to be at this point.
Release management
A much more complete summary
has already been posted on the list, and I had to leave the session
halfway to attend something else.
There seems to be an agreement that it is getting easier to upgrade
(although some people still don't want to do it, perhaps an education
effort is needed to help with this). People do use the stable point
release tags.
The "pressure to upgrade": would Long-Term Support release actually
help? Probably it would make it worse. The pressure to upgrade will
still be there except there won't be a need to work on it for another
year, and it'll make life worse for operators/etc submitting back fixes
because it'll take over a year for a patch to make it into their
system.
Fast-Forward Upgrade (which is not skip-level upgrades) may help with
that pressure... Or not, maybe different problems will come up because
of things like not restarting services in between upgrades. It batches
things and helps to upgrade faster, but changes nothing.
The conversation moved to one year release cycles just before I
left. It seemed to be all concerns and I don't recall active support
for the idea. Some of the concerns:
Concerns about backports - so many changes
Concerns about marketing - it's already hard to keep up with all
that's going on, and it's good to show the community is active and
stuff is happening more than once a year. It's not that closely tied
to releases though, announces could still go out more regularly.
Planning when something will land may become even harder as so much
can happen in a year
It's painful for both people who keep up and people who don't,
because there is so much new stuff happening at once.
TripleO
The sessions began with a retrospective on
Wednesday. I was really excited to hear that tripleo-common was going
to get unit tests for workflows. I still love the idea of workflows but
I found them becoming more and more difficult to work with as they get
larger, and difficult to review. Boilerplate gets copy-pasted, can't
work without a few changes that are easy to miss unless manually tested
and these get missed in reviews all the time.
The next session was about CI . The focus during
Queens was on reliability, which worked well although promotions
suffered as a result. There were some questions as to whether we should
try to prevent people from merging anything when the promotion pipeline
is broken but no consensus was really reached.
The Workflows session
was really interesting, there's been a lot of Lessons Learnt from our
initial attempt with Mistral this last couple of years and it looks
like we're setting up for a v2 overhaul that'll get rid of many of the
issues we found. Exciting! There was a brief moment of talk about
ripping Mistral out and reimplementing everything in Ansible,
conclusions unclear.
I didn't take good notes during the other sessions and once the venue
closed down (snow!) it became a bit difficult to find people in the
hotel and then actually hear them. Most etherpads with the notes are
linked from the main TripleO etherpad .