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<mailto:sbaluk...@bluebox.net>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto: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<mailto: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<mailto: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<mailto: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<mailto:OpenStack-dev@lists.openstack.org> > > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > > OpenStack-dev mailing list > > > > OpenStack-dev@lists.openstack.org<mailto: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<tel:%28800%29613-4305%20x807> > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto: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