On Tue, Dec 18, 2012 at 7:36 AM, Murali Reddy <murali.re...@citrix.com> wrote: > > I am splitting up my original proposal [1] so as to discuss each feature > independently. Please refer to the bug description [2] for the EIP > enhancements I am planning to do. As mentioned earlier first I am planning > to do a POC, but couple of issues that I want to bring it up for > discussion. > > -IMU, EIP (elastic IP's) that can be transferred from one zone to another > zone need to be special public IP's for which provider network edge > routers are configured to take /32 router advertisements. I think there is > need to introduce notion of 'elastic IP' pool into CloudStack apart from > the public IP's that can be configured in a zone. Users can acquire and > release elastic IP similar to the way they acquire public IP's today. > > -When cloud admin provisions pool of elastic IP's, should it be treated as > region level resource unlike the public IP's that are provisioned per > zone? When user acquires elastic IP and associates with a instance in a > zone, only then zone should advertise the VIP to upstream router. So IMO, > elastic IP should be region level resource but its association can change > from zone to another zone. > > -On a zone failure, if EIP's were moved to another zone by users, we need > to prevent route advertisements from the failed zone when it comes live. > My thinking is on reconnect, CloudStack should synchronise the state of > EIP provider in the zone to reflect the configuration in the DB. > > Please share your thoughts. > > [1] http://markmail.org/thread/thstz7su6d434ulm > [2] https://issues.apache.org/jira/browse/CLOUDSTACK-652 > > -Murali > >
+1 to the idea. We'll need some really good documentation on how the routers need to behave, specifically in more complex scenarios where the zones are truly isolated fault domains (different DC, ISPs, etc...). There are probably limits to what can be accomplished, so the requirements need to be clearly spelled out. -chip
