<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Jan 24, 2015 at 7:00 AM, Zane Bitter <span dir="ltr"><<a href="mailto:zbitter@redhat.com" target="_blank">zbitter@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I've mentioned this in passing a few times, but I want to lay it out here in a bit more detail for comment. Basically we're implementing convergence at a time when we still have a lot of 'unit' tests that are really integration tests, and we don't want to have to rewrite them to anticipate this new architecture, nor wait until they have all been converted into functional tests. And of course it goes without saying that we have to land all of these changes without breaking anything for users.<br>
<br>
To those ends, my proposal is that we (temporarily) support two code paths: the existing, legacy in-memory path and the new, distributed convergence path. Stacks will contain a field indicating which code path they were created with, and each stack will be operated on only by that same code path throughout its lifecycle (i.e. a stack created in legacy mode will always use the legacy code). We'll add a config option, off by default, to enable the new code path. That way users can switch over at a time of their choosing. When we're satisfied that it's stable enough we can flip the default (note: IMHO this would have to happen before kilo-3 in order to make it for the Kilo release).<br></blockquote><div><br>+1<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Based on this plan, I had a go at breaking the work down into discrete tasks, and because it turned out to be really long I put it in an etherpad rather than include it here:<br>
<br>
<a href="https://etherpad.openstack.org/p/heat-convergence-tasks" target="_blank">https://etherpad.openstack.<u></u>org/p/heat-convergence-tasks</a><br>
<br></blockquote><div><br></div><div>Thanks Zane, this looks great.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If anyone has additions/changes then I suggest adding them to that etherpad and replying to this message to flag your changes.<br>
<br>
To be clear, it's unlikely I will have time to do the implementation work on any of these tasks myself (although I will be trying to review as many of them as possible). So the goal here is to get as many contributors involved in doing stuff in parallel as we can.<br>
<br>
There are obviously dependencies between many of these tasks, so my plan is to raise each one as a blueprint so we can see the magic picture that Launchpad shows. I want to get feedback first though, because there are 18 of them so far, and rejigging everything in response to feedback would be a bit of a pain.<br>
<br>
I'm also prepared to propose specs for all of these _if_ people think that would be helpful. I see three options here:<br>
 - Propose 18 fairly minimal specs (maybe in a single review?)<br></blockquote><div><br></div><div>This sounds fine, but if possible group them a bit 18 sounds like a lot and many of these look like small jobs.<br></div><div>I am also open to using bugs for smaller items. Basically this is just the red tape, so what ever is the least effort<br>and makes things easier to divide the work up.<br><br></div><div>-Angus<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 - Propose 1 large spec (essentially the contents of that etherpad)<br>
 - Just discuss in the etherpad rather than Gerrit <br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Obviously that's in decreasing order of the amount of work required, but I'll do whatever folks think best for discussion.<br>
<br>
cheers,<br>
Zane.<br>
<br>
______________________________<u></u>______________________________<u></u>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.<u></u>openstack.org?subject:<u></u>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote></div><br></div></div>