Open Stack

On 12/02/2013 10:53 AM, Gary Kotton wrote:
> 
> 
> On 12/2/13 5:39 PM, "Russell Bryant" <rbryant at redhat.com> wrote:
> 
>> On 12/02/2013 10:33 AM, Monty Taylor wrote:
>>> 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.
>>
>> That makes sense to me, actually.
>>
>> I suppose part of the issue is that we're not positive how much work
>> will happen to the code *after* the forklift.  Will we have other
>> services integrated?  Will it have its own database?  How different is
>> different enough to warrant needing a deprecation cycle?
> 
> I have concerns with the forklift. There are at least 1 or 2 changes a
> week to the scheduling code (and the is is not taking into account new
> features being added). Will these need to be updated in 2 separate code
> bases? How do we ensure that both are in sync for the interim period. I am
> really sorry for playing devils advocate but I really think that there are
> too many issues and we have yet to iron them out. This should not prevent
> us from doing it but lets at least be aware of what is waiting ahead.

This is one of the reasons that I think the forklift is a *good* idea.
It's what will enable us to do it as fast as possible and minimize the
time we're dealing with 2 code bases.  It could be just 1 deprecation
cycle, or just a matter of a few weeks if we settle on what Monty is
suggesting.

What we *don't* want is something like Neutron and nova-network, where
we end up maintaining two implementations of a thing for a long, long time.

-- 
Russell Bryant