Ok, so we've got opinions on both sides of the argument here. I'm actually pretty ambivalent about it. Do others have strong opinions on this?
On Mon, Jun 23, 2014 at 6:03 PM, Doug Wiegley <do...@a10networks.com> wrote: > Put me down for being in favor of option 1. > > A single attribute in a 1:1 relationship? Putting that in a new table > sounds like premature optimization to me; design the database change for > the future feature when you can see the spec for it. > > Thanks, > Doug > > > From: Stephen Balukoff <sbaluk...@bluebox.net> > Reply-To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Date: Monday, June 23, 2014 at 5:25 PM > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [Neutron][LBaaS] Should TLS settings for > listener be set through separate API/model? > > Also to add to pros for 2: > > * Keeping the TLS stuff contained to its own objects means we can have > separate development resources on each and not worry as much about > overlapping domains. (TLS-related knowledge and knowledge of dealing with > TCP / UDP listeners are separate knowledge domains. Or at least, the former > is a more specialized subset of the latter.) > > Note that what we're proposing means there's essentially a 1:0-1 > relationship between Listener and this new yet-to-be-named object. (0 in > case the Listener is not terminating TLS.) > > Stephen > > On Mon, Jun 23, 2014 at 3:38 PM, Brandon Logan < > brandon.lo...@rackspace.com> wrote: > >> Whoops, [Neutron][LBaaS] got taken out of the subject line here. >> Putting it back in. >> >> On Mon, 2014-06-23 at 21:10 +0000, Brandon Logan wrote: >> > Okay so we've talked a bit about this in IRC and now I'm sending this >> > out as an update. Here are the options with pros and cons that have >> > come from that discussion. >> > >> > 1) default_certificate_id is an attribute of the Listener object. >> > >> > Pros: >> > -No extra entity needed >> > >> > Cons: >> > -May bloat Listener object when more attributes are needed for only TLS >> > termination. Sounds like TLS version and cipher selection will be >> > needed attributes in the future. >> > >> > >> > 2) A separate TLS Entity is created that is referenced by the Listener >> > object. This entity at first may only contain a certificate_id that >> > references barbican. Name and description can be allowed as well. >> > >> > Pros: >> > -TLS domain specific attributes contained in its own entity >> > -Future attributes would just be added to this entity and not bloat the >> > Listener object. >> > >> > Cons: >> > -It's another entity >> > >> > In IRC we (sbalukoff, myself) seemed to agree option 2 is right way to >> > go. Anyone agree or disagree? >> > >> > Thanks, >> > Brandon >> > >> > On Mon, 2014-06-23 at 12:15 -0700, Stephen Balukoff wrote: >> > > The separate entity makes sense for certificates participating in an >> > > SNI configuration, but probably not so much for the 'default' >> > > certificate used when TLS is being terminated. >> > > >> > > >> > > Vijay: You're also right that other TLS-related attributes will >> > > probably get added to the Listener object. This probably makes sense >> > > if they apply to the Listener object as a whole. (This includes things >> > > like TLS version and cipher selection.) >> > > >> > > >> > > I don't see much of a point in creating a separate object to contain >> > > these fields, since it would have a 1:1 relationship with the >> > > Listener. It's true that for non-TLS-terminated Listeners, these >> > > fields wouldn't be used, but isn't that already the case in many other >> > > objects (not just in the Neutron LBaaS sub project)? >> > > >> > > >> > > Thanks, >> > > Stephen >> > > >> > > >> > > >> > > >> > > >> > > >> > > On Mon, Jun 23, 2014 at 9:54 AM, Brandon Logan >> > > <brandon.lo...@rackspace.com> wrote: >> > > Vijay, >> > > I think the separate entity is still going to happen. I don't >> > > think it >> > > has remvoed. Or that is may just be my assumption. >> > > >> > > Thanks, >> > > Brandon >> > > >> > > On Mon, 2014-06-23 at 15:59 +0000, Vijay Venkatachalam wrote: >> > > > Hi: >> > > > >> > > > >> > > > In the “LBaaS TLS termination capability specification” >> > > proposal >> > > > >> > > > https://review.openstack.org/#/c/98640/ >> > > > >> > > > TLS settings like default certificate container id and SNI >> > > cert list are part of the listener properties. >> > > > >> > > > I think it is better to have this as a separate entity so >> > > that the listener properties are clean and is not “corrupted” >> > > with TLS settings. >> > > > >> > > > I liked the original SSL proposal better where TLS settings >> > > was a separate entity. >> > > > >> > > > It is just 2 properties now but in future the TLS settings >> > > would grow and if we are going to introduce a TLS >> > > profile/params/settings entity later, it is better to do it >> > > now (albeit with min properties). >> > > > >> > > > Thanks, >> > > > Vijay V. >> > > >> > > > _______________________________________________ >> > > > 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 >> > > >> > > >> > > >> > > >> > > -- >> > > Stephen Balukoff >> > > Blue Box Group, LLC >> > > (800)613-4305 x807 >> > > _______________________________________________ >> > > 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 >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > > -- > Stephen Balukoff > Blue Box Group, LLC > (800)613-4305 x807 > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
