[openstack-dev] [Heat] Heat Juno Mid-cycle Meetup report
Zane Bitter
zbitter at redhat.com
Fri Aug 22 19:39:24 UTC 2014
We held the inaugural Heat mid-cycle meetup in Raleigh, North Carolina
this week. There were a dozen folks in attendance, and I think everyone
agreed that it was a very successful event. Notes from the meetup are on
the Etherpad here:
https://etherpad.openstack.org/p/heat-juno-midcycle-meetup
Here are a few of the conclusions:
* Everyone wishes the Design Summit worked like this.
The meetup seemed a lot more productive than the design summit ever is.
It's really nice to be in a room small enough that you can talk normally
and hear everyone, instead of in a room designed for 150 people. It's
really nice to be able to discuss stuff that isn't related to a
particular feature - we had a long discussion about how to get through
the review backlog, for example. It's really nice to not have fixed time
slots for discussions - because everyone was in the room the whole time,
we could dip in and out of different topics at will. Often we came back
to one that we'd previously discussed because we had discovered new
information. Finally, it's critical to be in a room covered in
full-sized whiteboards that everyone can see. A single tiny flip chart
doesn't cut it.
* 3 days seems to be about the right length.
Not a lot got done on day 3, and people started to drift out at various
times to catch flights, but the fact that everyone was there for _all_
of day 1 and 2 was essential (the critical Convergence plan was
finalised around 7.30pm on Tuesday).
* There was a lot more discussion than hacking.
The main value of the meet-up was more in the discussions you'd hope to
be able to have at the design summit than in working collaboratively on
code.
* Marconi is now called Zaqar.
Who knew?
* Marc^W Zaqar is critical to pretty much every major non-Convergence
feature on the roadmap.
We knew that we wanted to use it for notifications, but we also want to
make those a replacement for events, and a conduit for warnings and
debugging information to the user. This is becoming so important that
we're going to push ahead with an implementation now without waiting to
see when Zaqar will graduate. Zaqar would also be a good candidate for
pushing metadata changes to servers, to resolve the performance issues
currently caused by polling.
* We are on track to meet the immediate requirements of TripleO.
Obviously it would be nice to have Convergence now, but failing that the
most critical bugs are under control. In the immediate future, we need
to work on finding a consensus on running with multiple worker by
default, split trees of nested stacks so that each nested stack runs in
a separate engine, and find a way to push metadata out from Heat instead
of having servers poll us for it.
* We have a plan for what Convergence will look like.
Here's some horrific photos of a whiteboard:
https://www.dropbox.com/sh/tamoc8dhhckb81w/AAA6xp2be9xv20P7SWx-xnZba?dl=0
Clint is, I believe, working on turning that into something more
consumable. This was definitely the biggest success of the meet-up.
Before this I had no idea what convergence would look like; now I have a
fair idea how it will work and where the tricky bits might be. I doubt
this could have happened at a design summit.
* We probably don't need TaskFlow.
After coming up with the Convergence plan we realised that, while
TaskFlow would be useful/essential if we were planning a more modest
refactoring of Heat, the architecture of Convergence should actually
eliminate the need for it. All we think we need is a bunch of work
queues that can be provided by oslo.messaging. TaskFlow seems great for
the problem it solves, but we have the opportunity to not create that
problem for ourselves in the first place.
* Convergence probably won't buy us much in the short term.
I think we all hoped that our incremental work on Convergence would
render incremental benefits for Heat. After figuring out the rough
outline of how Convergence could work, we realised that the incremental
steps along the way (like implementing the observer process) will
actually not have a big impact. So while, of course, we'll continue to
work incrementally, we don't expect to see major benefits until nearer
the end of the process.
Thanks to everyone who made the trip, and of course also to everyone who
contributed input via IRC and generally held down the fort while we were
meeting. If I misstated or just plain missed anything above, please feel
free to weigh in.
cheers,
Zane.
More information about the OpenStack-dev
mailing list