Darren, Murali Can you review the final patch and if acceptable merge into master. Syed the deadline is hard. I will cut the branch on 11/08 late night or early morning next day
Animesh > -----Original Message----- > From: Syed Ahmed [mailto:sah...@cloudops.com] > Sent: Wednesday, November 06, 2013 8:26 AM > To: dev@cloudstack.apache.org > Cc: Murali Reddy; Darren Shepherd > Subject: Re: [New Feature FS] SSL Offload Support for Cloudstack > > Hi All, > > Many thanks to Darren and Murali for reviewing my code. I feel that the > code is in a good condition to be merged into the master. I see that the > code freeze is at the end of this week. Is it possible for my patch to > be merged by then? Is it a hard deadline? > > Thanks, > -Syed > > On Mon 04 Nov 2013 11:45:15 AM EST, Syed Ahmed wrote: > > Hi All, > > > > I would like to get this code into 4.3. Is it possible for this to be > > reviewed? Is there anything needed from my side? I would be glad to > > provide more information. > > > > Thanks, > > -Syed > > > > On Wed 30 Oct 2013 03:25:12 PM EDT, Syed Ahmed wrote: > >> Hi All, > >> > >> I have the patch for adding SSL termination support at > >> https://reviews.apache.org/r/14976/ . It would be great if this can > >> be reviewed. > >> > >> Thanks, > >> -Syed > >> > >> On 13-10-15 03:01 AM, Murali Reddy wrote: > >>> On 11/10/13 9:31 PM, "Syed Ahmed" <sah...@cloudops.com> wrote: > >>> > >>>> Thanks for your valuable feedback Murali. Here are my comments. > >>>> > >>>>> IMO, > >>>>> its better we introduce new api's say > >>>>> registerCertifcateToLoadbalancer/deregisterCertifcateToLoadbalance > >>>>> r > >>>>> 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. > >>> CloudStack already has distinct API's for each of the LB > >>> sub-functionality (health check, stickiness etc) [1]. We are not > >>> adding any redundant API, so resulting API are much cleaner just > >>> managing SSL termination for a LB rule. > >>> > >>>>> 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? > >>> So there is notion of network service and network service capability > >>> [2]. > >>> I would attribute 'SSL termination' as capability of LB service. > >>> createNetworkOffering API take a capability list. It does make sense > >>> to check if the network offering has SSL termination enabled when > >>> API to assign a cert to LB is called. Also note that, 'Network > Elements' > >>> declare > >>> their capabilities for the supported services. So it can verified > >>> that service provider for LB actually supports 'SSL termination' > >>> capability while creating network offering. > >>> > >>> > >>>> Also when you say usage event, what does this imply? I am sorry I > >>>> am not familiar with that term. Can you please elaborate. > >>> Its an event generated and persisted in the DB for every resource > >>> consumption and release. These events are used for billing etc. > >>> Please check publishUsageEvent calls in the code. > >>> > >>> [1] http://cloudstack.apache.org/docs/api/apidocs-4.2/TOC_User.html > >>> [2] api/src/com/cloud/network/Network.java > >>> > >> > > > > >
