On 13-11-06 12:18 PM, Murali Reddy wrote:
On 06/11/13 12:40 AM, "Syed Ahmed" <sah...@cloudops.com> wrote:
On Nov. 5, 2013, 9:43 a.m., Murali Reddy wrote:
api/src/com/cloud/network/lb/LoadBalancingRule.java, lines 42-43
<https://reviews.apache.org/r/14976/diff/3/?file=374393#file374393line42>
can you please add new constructors which takes ssl cert and
protocol. If we extend same constructor then its resulting unnecessary
changes in internal lb, elastic lb code as well.
I have added an new constructor and removed all reverted all the
invocations in internal lb and elastic lb code. I am sorry but I am not
aware of the difference between different LB types in cloudstack. Is
there some place where I can find more info on this ?
On Nov. 5, 2013, 9:43 a.m., Syed Ahmed wrote:
- i dont see certificate details in the load balancer response
obtained from listLoadBalancerRules.Does it make sense to give the
certificate details if there is a cert assigined to load balancer rule?
- i dont see code to add a network offering with
'SslTermination'capability. Also list network offering, should show if
LB service with SSL termination is supported by the offering.
- Please add Apache license header to all files.
1) I was looking at the listLoadBalancerRules API and it does not list
other things bound to the lb rule like stickiness policy or health check
policy so I assumed that SSL certs being something like health check will
not be in the response. If it makes sense to add them, I will gladly do
so.
Yes, you are right. I was assuming that in load balancer response, there
should be details of associated stickiness policy etc, but looks like lb
response need to be fixed across the board. If its not too much of a
change please add the certificate details associated with lb rule in the
lb rule response.
I am a but reticent on adding this with this patch as the
createLoadBalancerResponse() in ApiResponseHelper
does not take other parameters and I don't see any use of DAO objects in
that class. I am guessing this is a design decision
and I don't want to mess with the existing practices by polluting
ApiResponseHelper.
I will fix all the LB responses in another patch if that is OK with you.
2) So what you are saying is that Ssltermination will be a service
offering like DNS, DHCP etc? Right now, if you see the
NetscalerElement.java, I have just added the SslTermination capability as
true. Does this suffice?
So there is network service and network service capabilities. I meant
'ssltermination' to be a capability of lb service. When you create network
offering, you can say 'LB' service and service capability
'ssltermination' is enabled by the network offering. So in only networks
created with such network offering, SSL termination functionality can be
available.
Also, there need to be service capability matched against the advertised
capabilities of network service provider. For eg. If one creates network
offering which says LB service with SslCapability enabled with virtual
router providing LB service should fail because VR does not advertise the
capabilities in VirtualRouter Network Element. Same should succeed if
NetScaler is chosen as service provider because NetScaler element
advertised the capability.
Right now SslTermination is a LB capability and is enabled by default in
NetScaler.
We had decided that instead of having enable/disable for this
functionality, we would be
billing based on the events generated when certs are assigned to the LB
rules. This was to
simplify the implementation and not end up with cases like you mentioned
above.
Now the problem here is if I try to assign a certificate to lets say an
F5 loadbalancer. It should error out
saying that Ssl termination is not supported ( yet ). One way I see that
is to check for certificate when calling canHandleRule() in the F5's
element.
But this has to be done for all loadbalancers. Is there a better way of
doing this?
3) Done
