Thanks for your valuable feedback Murali. Here are my comments.
IMO,
its better we introduce new api's say
registerCertifcateToLoadbalancer/deregisterCertifcateToLoadbalancer than
force fit existing API's for associate/dis-associate certificates.
Personally, I was going to do it this way. But I am not sure how good
of an idea it is to add a new api just for this feature as I can see
assignToLoadbalancer is semantically similar. But if everyone agrees I
have no problem with it.
On second thought may be an CloudStack usage event on assigning
certificate seems good enough to me.
So what I got from your earlier post was that when adding a network
offering the provider can choose to enable SSL Termination or not as it
is a value added service. I was thinking of adding "SSL termination"
under supportedservices for the createNetworkOffering API call. And
when someone calls the API to assign a cert to LB we can check if this
network offering has SSL termination enabled. Does this make sense?
Also when you say usage event, what does this imply? I am sorry I am
not familiar with that term. Can you please elaborate.
Thanks
-Syed
On Fri 11 Oct 2013 09:03:45 AM EDT, Murali Reddy wrote:
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.
- 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.
