Open Stack

Well, I can actually say with confidence that the replacement would be stable by essex release.  In fact, I expect the first commit to be a completely working solution that solves a number of problems with the original implementation.  I don't think there's any issue getting something committed by the 15th if there's not much bickering on the review.  The code is dead simple (currently a 500 line diff) and requires almost no modification of nova core.  The only modifications to nova core are:

Specify a different compute API class to use
Modify rpc code to allow some kwargs to Connection __init__ so you can specify a specific rabbit server to use to send a message to a zone
Add 2 new rpc methods:   cast_to_zone and call_to_zone (which use the above change)
Add a few zone_api.update_instance() calls in some places in compute so that we can push instance updates to top level zone.
Migration for zones DB table to add rpc credential information.

Besides that, the rest of the code is standalone.  There's absolutely no concern that it'll make non-zones less stable.  The few zone_api.update_instance() type calls would be no-ops when zones is turned off.

As far as meeting a 2/15 date, here's what I have left: 

1) clean up some things in my compute API subclass
2) finish writing tests

(Vish: I was joking when I asked if you meant 15th of March ;)

After what I would plan to push for the first commit, there's some refactoring desired to better share functionality between the zone scheduler and the host scheduler, but it'd be nothing required for Essex if we want to wait on that.  And there's a desire to fold this new 'zones' nova service I'm creating into the current scheduler as potentially just a different scheduler driver.

There's 1 thing that would be lost in what I'd propose:  zone scheduling would initially be random zone selection.

Either way, I think I'll throw something up for review by mid next week to see what thoughts are.  I'd like to at least share what this looks like at the moment.  If we still decide to wait for F1, cool.

- Chris

On Feb 2, 2012, at 1:27 AM, Vishvananda Ishaya wrote:

> I talked with chris a bit offline, and I'm a little concerned that we will be pushing too hard to try and get this into a working state by Essex.  I think even if we to slam it in we will be faced with bugs that will make the essex version potentially as broken as the current zones code is. It is probably much more reasonable to target F1 as a delivery date for this feature.  Alejandro, is your team ok with deploying milestone releases? I know it would take a lot of pressure off of Chris, Sandy, et. al. since they are trying to meet some pretty hard delivery dates as it is.
> 
> Vish
> On Feb 1, 2012, at 3:44 PM, Alejandro Comisario wrote:
> 
>> Sounds pretty good Vish.
>> 
>> Since we are mostly deployers, and the ones who are gonna try the new code from day zero, whats good for Sandy, its good for us.
>> 
>> Alejandro.
>> 
>> On 02/01/2012 06:57 PM, Vishvananda Ishaya wrote:
>>> Thanks for the feedback. It is good to get input from one of the largest openstack installs! So it sounds like the existing code is pretty broken. Based on this feedback I would like to propose the following:
>>> 
>>> 1) cut out zones code
>>>   (meaning merge the existing branch)
>>> 
>>> 2) grant an FFe for the new rpc based zone code as long is it can be merged without heavily modifying core.
>>> 
>>> This means:
>>> a) it should be deployable with the feature disabled
>>> b) it should only include minor modifications to core components
>>> c) if a major change is needed to distributed_scheduler (for example), consider leaving the existing version in, and copying the code to a new file (distributed_scheduler_v2) and doing the modifications there.  That way we can minimize chances of breakage
>>> d) it needs to be merged by the 15th
>>> 
>>> 
>>> Does that seem reasonable?
>>> 
>>> Vish
>>> 
>>> On Feb 1, 2012, at 1:42 PM, Alejandro Comisario wrote:
>>> 
>>>> Hi guys.
>>>> Its true that we are trying to make multizones work, actually we did, but we get into an instance were listing all vms from the parent zone ( where is has to go thru all the child zones ) is buggy ( if not impossible by now ).
>>>> So, if there is a new zone architecture that actually works ( we want to stop using our own deployer to do that ) or has a chance to be fully working when 2012-1 is out, (we would prefer not to wait till Folsom) we are totally into it ! since by now, we were actually waiting for this new Zones code to come out to try again.
>>>> 
>>>> Alejandro.
>>>> 
>>>> On 02/01/2012 06:17 PM, Nathanael Burton wrote:
>>>>> +1
>>>>> 
>>>>> On Feb 1, 2012 4:13 PM, "Vishvananda Ishaya" <vishvananda at gmail.com> wrote:
>>>>> I would prefer that if it can be done super-super fast. :)
>>>>> 
>>>>> Vish
>>>>> 
>>>>> On Feb 1, 2012, at 1:04 PM, Chris Behrens wrote:
>>>>> 
>>>>> > I wonder if we can use some of the architecture of the new code and move the current implementation to that model.  It'd preserve the existing functionality, set us up for the new implementation, and fits in with 'cleanup' for E4, etc.
>>>>> >
>>>>> > On Feb 1, 2012, at 2:41 PM, Vishvananda Ishaya <vishvananda at gmail.com> wrote:
>>>>> >
>>>>> >> I am all for pulling this out, but I'm a bit concerned with the fact that we have nothing to replace it with. There are some groups still trying to use it. MercadoLibre is trying to use it for example. I know you guys are trying to replace this with something better, but it would be nice not to break people for 7+ months
>>>>> >>
>>>>> >>
>>>>> >> So I guess I have some questions:
>>>>> >> 1.a) is the current implementation completely broken?
>>>>> >>
>>>>> >> 1.b) if yes, is it fixable
>>>>> >>
>>>>> >> 2) If we do remove this, what can we tell people that need something like zones between now and the Folsom release?
>>>>> >>
>>>>> >> Vish
>>>>> >> On Feb 1, 2012, at 12:16 PM, Sandy Walsh wrote:
>>>>> >>
>>>>> >>> As part of the new (and optional) Zones code coming down the pipe, part of this is to remove the old Zones implementation.
>>>>> >>>
>>>>> >>> More info in the merge prop:
>>>>> >>> https://review.openstack.org/#change,3629
>>>>> >>>
>>>>> >>> So, can I? can I? Huh?
>>>>> >>> _______________________________________________
>>>>> >>> Mailing list: https://launchpad.net/~openstack
>>>>> >>> Post to     : openstack at lists.launchpad.net
>>>>> >>> Unsubscribe : https://launchpad.net/~openstack
>>>>> >>> More help   : https://help.launchpad.net/ListHelp
>>>>> >>
>>>>> >>
>>>>> >> _______________________________________________
>>>>> >> Mailing list: https://launchpad.net/~openstack
>>>>> >> Post to     : openstack at lists.launchpad.net
>>>>> >> Unsubscribe : https://launchpad.net/~openstack
>>>>> >> More help   : https://help.launchpad.net/ListHelp
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Mailing list: https://launchpad.net/~openstack
>>>>> Post to     : openstack at lists.launchpad.net
>>>>> Unsubscribe : https://launchpad.net/~openstack
>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Mailing list: 
>>>>> https://launchpad.net/~openstack
>>>>> 
>>>>> Post to     : 
>>>>> openstack at lists.launchpad.net
>>>>> 
>>>>> Unsubscribe : 
>>>>> https://launchpad.net/~openstack
>>>>> 
>>>>> More help   : 
>>>>> https://help.launchpad.net/ListHelp
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~openstack
>>>> Post to     : openstack at lists.launchpad.net
>>>> Unsubscribe : https://launchpad.net/~openstack
>>>> More help   : https://help.launchpad.net/ListHelp
>>> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp