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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev