Open Stack

On 12/02/2013 10:39 AM, Russell Bryant 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 think those are excellent questions. I'd hope that at this point, what
we'd do is make sure that new scheduler can be CD-upgraded from old
scheduler with no downtime.

The own database is an interesting question - and probably the trickiest
from a no-downtime upgrade path. But if we can't figure out the no-pain
way, then putting in a deprecation cycle is just delaying the pain.