Open Stack

Hi Everyone,

TripleO held a midcycle meetup from February 18th-20th in Seattle. Thanks to HP
for hosting the event! I wanted to send out a summary of what went on. We also
captured some notes on an etherpad[0].

The first order of business was that I volunteered to serve as PTL of TripleO
for the remainder of the Kilo cycle after Clint Byrum announced that he was
stepping down due to a change in focus. Thanks Clint for serving as PTL so far
throughout Kilo!

We moved on to talking about the state of TripleO in general. An immediate
topic of discussion was CI stability, especially as all of our jobs were
currently failing at the time. It appeared that most agreed that our actual CI
stability was pretty good overall and that most of the failures continue to be
caused by finding bugs in our own code and regressions in other projects that
end up breaking TripleO. There was a lot of agreement that the TripleO CI was
very useful and continues to find real breakages in OpenStack that are otherwise
missed.

We talked a bit about streamlining the CI jobs that are run by getting rid of
the undercloud jobs entirely or using the jenkins worker as the seed itself.

As it typically tends to do, the discussion around improving our CI drifted
into the topic of QuintupleO. Everyone seems to continue to agree that
QuintupleO would be really helpful to CI and development environments, but that
no one has time to work on it. The idea of skipping the Ironic PXE/iscsi
deployment process entirely and just nova boot'ing our instances as regular vm
images was brought up as a potential way to get QuintupleO off the ground
initially. You'd lose out on the coverage around Ironic, but it could still be
very valuable for testing all the other stuff such as large HA deployments
using Heat, template changes, devtest, etc.

We moved onto talking about diskimage-builder. Due to some shifts in focus,
there were some questions about any needed changes to the core team
of diskimage-builder. In the end, it was more or less decided that any such
changes would just be disruptive at this point, and that we could instead be
reactive to any changes that might be needed in the future.

There were lots of good ideas about how to improve functional testing of
diskimage-builder and giving it a proper testsuite outside of TripleO CI.
Functional and unit testing of the individual elements and hook scripts is also
desired. While there was half a session devoted to the unit testing aspect at
the Paris summit, we haven't yet made a huge amount of progress in this area,
but it sounds like that might soon change.

The tripleo-heat-templates was the next topic of discussion. With having
multiple implementations in tree, we agreed it was time to deprecate the
merge.py templates[1]. This will also free up some CI capacity for new jobs
after the removal of those templates.

We talked about backwards compatibility as well. The desire here was around
maintaining the ability to deploy stable versions of OpenStack for the
Overcloud with the TripleO tooling. Also, it was pointed out that the new
features that have been rolling out to the TripleO templates are for the
Overcloud only, so we're not breaking any ability to upgrade the Undercloud.

Dan Prince gave a detailed overview of the Puppet and TripleO integration
that's been ongoing since a little before Paris. A lot of progress has been
made very quickly and there is now a CI job in place exercising a deployment
via Puppet using the stackforge puppet modules. I don't think I need to go into
too much more detail here, because Dan already summarized it previously on
list[2].

The Puppet talk led into a discussion around the Heat breakpoints feature and
how that might be used to provide some aspect of workflow while doing a
deployment. There were some concerns raised that using breakpoints in that way
was odd, especially since they're not represented in the templates at all. In
the end, I think most agreed that there was an opportunity here to drive
further features in Heat to meet the use cases that are trying to be solved
around Overcloud deployments using breakpoints.

One theme that resurfaced a few times throughout the midcycle was ways that
TripleO could better define it's interfaces to make different parts pluggable,
even if that's just documentation initially. Doing so would allow TripleO to
integrate more easily with existing solutions that are already in use.

Thanks again to everyone who was able to participate in the midcycle, and as
well to those who stayed home and did actual work...such as fixing CI.

For other folks who attended, feel free to add some details, fill in
any gaps, or
disagree with my recollection of events :-).

[0] https://etherpad.openstack.org/p/kilo-tripleo-midcycle-meetup
[1] https://review.openstack.org/#/c/158410/
[2] http://lists.openstack.org/pipermail/openstack-dev/2015-February/056618.html


-- 
-- James Slagle
--