[openstack-dev] [Nova][Schduler] Volunteers wanted for a modest proposal for an external scheduler in our lifetime

Monty Taylor mordred at inaugust.com
Mon Dec 2 15:33:43 UTC 2013



On 12/02/2013 09:13 AM, Russell Bryant wrote:
> 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.

Just because I'd like to argue - if what we do here is an actual
forklift, do we really need a cycle of deprecation?

The reason I ask is that this is, on first stab, not intended to be a
service that has user-facing API differences. It's a reorganization of
code from one repo into a different one. It's very strongly designed to
not be different. It's not even adding a new service like conductor was
- it's simply moving the repo where the existing service is held.

Why would we need/want to deprecate? I say that if we get the code
ectomied and working before nova feature freeze, that we elevate the new
nova repo and delete the code from nova. Process for process sake here
I'm not sure gets us anywhere.

Monty



More information about the OpenStack-dev mailing list