On 09/10/13 8:08 PM, "Syed Ahmed" <sah...@cloudops.com> wrote:
>Thanks Murali for your response. > >> - any reason why you choose assignTo/RemoveFrom load balancer rule API's > >I thought this made more sense than create/updateLoadbalancerRule as >we would have to call update to delete a cert which I find somewhat >confusing. Also this is semantically similar to attaching instances as >in you have a separate entity which is being bound to different LBs. We will be just overloading the assignTo/RemoveFrom load balancer rule API's for associate/dis-associte certificate with load balancer rule. IMO, its better we introduce new api's say registerCertifcateToLoadbalancer/deregisterCertifcateToLoadbalancer than force fit existing API's for associate/dis-associate certificates. > >> - to me SSL termination is value added service from providers >>perspective, >> So only if network offering permits, SSL termination can be used. > >Got it. This seems the logical way. Good point. On second thought may be an CloudStack usage event on assigning certificate seems good enough to me. > >Would it be a good Idea to add protocol to the createLoadBalancer API. >I think this makes sense in the long run as currently I cannot create >a HTTP loadbalncer for port 8080 from cloudstack. Yes, its good we introduce protocol in the API, and make it optional parameter. Currently CloudStack marks protocol as TCP by default and load balancer implementation layer corresponding to HAProxy, F5, NetScaler we are inferring protocol from the ports. So on upgrade just ensure we don't break backward compatibility of the existing load balancer rules.
