Open Stack

On 11/29/2013 10:01 AM, Thierry Carrez wrote:
> Robert Collins wrote:
>> https://etherpad.openstack.org/p/icehouse-external-scheduler
> 
> Just looked into it with release management / TC hat on and I have a
> (possibly minor) concern on the deprecation path/timing.
> 
> Assuming everything goes well, the separate scheduler will be
> fast-tracked through incubation in I, graduate at the end of the I cycle
> to be made a fully-integrated project in the J release.
> 
> Your deprecation path description mentions that the internal scheduler
> will be deprecated in I, although there is no "released" (or
> security-supported) alternative to switch to at that point. It's not
> until the J release that such an alternative will be made available.
> 
> So IMHO for the release/security-oriented users, the switch point is
> when they start upgrading to J, and not the final step of their upgrade
> to I (as suggested by the "deploy the external scheduler and switch over
> before you consider your migration to I complete" wording in the
> Etherpad). As the first step towards *switching to J* you would install
> the new scheduler before upgrading Nova itself. That works whether
> you're a CD user (and start deploying pre-J stuff just after the I
> release), or a release user (and wait until J final release to switch to
> it).
> 
> Maybe we are talking about the same thing (the migration to the separate
> scheduler must happen after the I release and, at the latest, when you
> switch to the J release) -- but I wanted to make sure we were on the
> same page.

Sounds good to me.

> I also assume that all the other "scheduler-consuming" projects would
> develop the capability to talk to the external scheduler during the J
> cycle, so that their own schedulers would be deprecated in J release and
> removed at the start of H. That would be, to me, the condition to
> considering the external scheduler as "integrated" with (even if not
> mandatory for) the rest of the common release components.
> 
> Does that work for you ?

I would change "all the other" to "at least one other" here.  I think
once we prove that a second project can be integrated into it, the
project is ready to be integrated.  Adding support for even more
projects is something that will continue to happen over a longer period
of time, I suspect, especially since new projects are coming in every cycle.

-- 
Russell Bryant