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