Open Stack

On 12/2/13 5:33 PM, "Monty Taylor" <mordred at 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 at 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