Hi, My vote is for separate resource (e.g. 'New Model'). Also I'd like to see certificate handling as a separate extension/db mixing(in fact, persistence driver) similar to service_type extension.
Thanks, Eugene. On Thu, Dec 5, 2013 at 2:13 PM, Stephen Gran <stephen.g...@theguardian.com>wrote: > Hi, > > Right, sorry, I see that wasn't clear - I blame lack of coffee :) > > I would prefer the "Revised New Model". I much prefer the ability to > restore a loadbalancer from config in the event of node failure, and the > ability to do basic sharing of certificates between VIPs. > > I think that a longer term plan may involve putting the certificates in a > smarter system if we decide we want to do things like evaluate trust > models, but just storing them locally for now will do most of what I think > people want to do with SSL termination. > > Cheers, > > > On 05/12/13 09:57, Samuel Bercovici wrote: > >> Hi Stephen, >> >> To make sure I understand, which model is fine "Basic/Simple" or "New". >> >> Thanks, >> -Sam. >> >> >> -----Original Message----- >> From: Stephen Gran [mailto:stephen.g...@theguardian.com] >> Sent: Thursday, December 05, 2013 8:22 AM >> To: openstack-dev@lists.openstack.org >> Subject: Re: [openstack-dev] [Neutron][LBaaS] Vote required for >> certificate as first-class citizen - SSL Termination (Revised) >> >> Hi, >> >> I would be happy with this model. Yes, longer term it might be nice to >> have an independent certificate store so that when you need to be able to >> validate ssl you can, but this is a good intermediate step. >> >> Cheers, >> >> On 02/12/13 09:16, Vijay Venkatachalam wrote: >> >>> >>> LBaaS enthusiasts: Your vote on the revised model for SSL Termination? >>> >>> Here is a comparison between the original and revised model for SSL >>> Termination: >>> >>> *************** >>> Original Basic Model that was proposed in summit >>> *************** >>> * Certificate parameters introduced as part of VIP resource. >>> * This model is for basic config and there will be a model introduced in >>> future for detailed use case. >>> * Each certificate is created for one and only one VIP. >>> * Certificate params not stored in DB and sent directly to loadbalancer. >>> * In case of failures, there is no way to restart the operation from >>> details stored in DB. >>> *************** >>> Revised New Model >>> *************** >>> * Certificate parameters will be part of an independent certificate >>> resource. A first-class citizen handled by LBaaS plugin. >>> * It is a forwarding looking model and aligns with AWS for uploading >>> server certificates. >>> * A certificate can be reused in many VIPs. >>> * Certificate params stored in DB. >>> * In case of failures, parameters stored in DB will be used to restore >>> the system. >>> >>> A more detailed comparison can be viewed in the following link >>> >>> https://docs.google.com/document/d/1fFHbg3beRtmlyiryHiXlpWpRo1oWj8FqVe >>> ZISh07iGs/edit?usp=sharing >>> >> > -- > Stephen Gran > Senior Systems Integrator - theguardian.com > Please consider the environment before printing this email. > ------------------------------------------------------------------ > Visit theguardian.com > On your mobile, download the Guardian iPhone app theguardian.com/iphoneand > our iPad edition > theguardian.com/iPad Save up to 33% by subscribing to the Guardian and > Observer - choose the papers you want and get full digital access. > Visit subscribe.theguardian.com > > This e-mail and all attachments are confidential and may also > be privileged. If you are not the named recipient, please notify > the sender and delete the e-mail and all attachments immediately. > Do not disclose the contents to another person. You may not use > the information for any purpose, or store, or copy, it in any way. > > Guardian News & Media Limited is not liable for any computer > viruses or other material transmitted with or as part of this > e-mail. You should employ virus checking software. > > Guardian News & Media Limited > > A member of Guardian Media Group plc > Registered Office > PO Box 68164 > Kings Place > 90 York Way > London > N1P 2AP > > Registered in England Number 908396 > > -------------------------------------------------------------------------- > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
