On 12/02/2013 10:53 AM, Gary Kotton wrote: > > > On 12/2/13 5:39 PM, "Russell Bryant" <rbry...@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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev