On 24 January 2015 at 00:00, Zane Bitter <zbit...@redhat.com> wrote: > 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. > > 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). > > 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: > > https://etherpad.openstack.org/p/heat-convergence-tasks > > If anyone has additions/changes then I suggest adding them to that > etherpad and replying to this message to flag your changes. >
I do not want to be assertive and greedy, so I toke several task, which IMO are not required a lot of time for implementation and deep understanding tricky things :) (Marked them on etherpad) Also I don't want to steal work from guys who designed whole staff with you. I think, that we could take more tasks later, when other volunteers will be satisfied. I believe, that work will be enough for everyone. :) > > 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. > > 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. > > I'm also prepared to propose specs for all of these _if_ people think that > would be helpful. I see three options here: > - Propose 18 fairly minimal specs (maybe in a single review?) > - Propose 1 large spec (essentially the contents of that etherpad) > - Just discuss in the etherpad rather than Gerrit > > I tend to choose etherpad, because it makes review and discussion faster. (i.e. all in one place is easier for reading and referencing). > Obviously that's in decreasing order of the amount of work required, but > I'll do whatever folks think best for discussion. > > cheers, > Zane. > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > Regards, Sergey.
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev