Open Stack

Thanks for the summary.  A couple of comments inline.

On 02/24/2015 08:48 AM, James Slagle wrote:
> 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.

I should note that just nova booting doesn't get you all the way to a
working devtest.  You'll still have networking issues running Neutron
inside of an OpenStack instance.

Also, Devananda pinged me recently about the Ironic IPMI listener
service that would probably let us start using this in CI, even if it
requires patches that wouldn't be available on real public clouds.  As
you noted, I haven't had a chance to followup with him about it though. :-(

> 
> 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.

It's worse than that.  The half session was actually in Atlanta. ;-)

Again, time.  I started implementing some test code and it's even being
used in dib already [1], but I just haven't had time to look into what
other functionality will be required for more complete test coverage.

[1]:
https://github.com/openstack/diskimage-builder/blob/master/diskimage_builder/tests/base.py

> 
> 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
> 
>