Open Stack

Monty Taylor wrote:
> 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.

I don't really care that much about deprecation in that case, but I care
about which release the new project is made part of. Would you make it
part of the Icehouse common release ? That means fast-tracking through
incubation *and* integration in less than one cycle... I'm not sure we
want that.

I agree it's the same code (at least at the beginning), but the idea
behind forcing all projects to undergo a full cycle before being made
part of the release is not really about code stability, it's about
integration with the other projects and all the various programs. We
want them to go through a whole cycle to avoid putting unnecessary
stress on packagers, QA, docs, infrastructure and release management.

So while I agree that we could play tricks around deprecation, I'm not
sure we should go from forklifted to part of the common release in less
than 3 months.

I'm not sure it would buy us anything, either. Having the scheduler
usable by the end of the Icehouse cycle and integrated in the J cycle
lets you have one release where both options are available, remove it
first thing in J and then anyone running J (be it tracking trunk or
using the final release) is using the external scheduler. That makes
more sense to me and technically, you still have the option to use it
with Icehouse.

-- 
Thierry Carrez (ttx)