On 12/2/13 5:33 PM, "Monty Taylor" <mord...@inaugust.com> 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://urldefense.proofpoint.com/v1/url?u=https://etherpad.openstack.o >>>>rg/p/icehouse-external-scheduler&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r= >>>>eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=nlm44OzEwIEFTzGCf >>>>k6Dx1Lc0g7KHrY0h78JGykLd0s%3D%0A&s=0b234ac4dbe29b80b61b0d53be18362c3743 >>>>299f908abc97941bfdb6f4c0c9da >>> >>> 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. I think that this is certainly different. It is something that we we want and need a user facing API. Examples: - aggregates - per host scheduling - instance groups Etc. That is just taking the nova options into account and not the other modules. How doul one configure that we would like to have storage proximity for a VM? This is where things start to get very interesting and enable the cross service scheduling (which is the goal of this no?). Thanks Gary > >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. > >Monty > >_______________________________________________ >OpenStack-dev mailing list >OpenStack-dev@lists.openstack.org >https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi- >bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=e >H0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=nlm44OzEwIEFTzGCfk6Dx >1Lc0g7KHrY0h78JGykLd0s%3D%0A&s=e39dbfa0d3ca06da0fe8785a05a337a7c046c1634b3 >7b24f9822e686596e4265 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
