Open Stack

On Sat, Jan 24, 2015 at 7:00 AM, Zane Bitter <zbitter at 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).
>

+1


>
> 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
>
>
Thanks Zane, this looks great.


> If anyone has additions/changes then I suggest adding them to that
> etherpad and replying to this message to flag your changes.
>
> 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?)
>

This sounds fine, but if possible group them a bit 18 sounds like a lot and
many of these look like small jobs.
I am also open to using bugs for smaller items. Basically this is just the
red tape, so what ever is the least effort
and makes things easier to divide the work up.

-Angus


>  - Propose 1 large spec (essentially the contents of that etherpad)
>  - Just discuss in the etherpad rather than Gerrit
>

> 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150127/a1104983/attachment-0001.html>