Open Stack

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.

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 ?

-- 
Thierry Carrez (ttx)