<div dir="ltr">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?</div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Mon, Jun 23, 2014 at 6:03 PM, Doug Wiegley <span dir="ltr"><<a href="mailto:dougw@a10networks.com" target="_blank">dougw@a10networks.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
<div>Put me down for being in favor of option 1.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Doug</div>
<div><br>
</div>
<div><br>
</div>
<span>
<div style="font-family:Calibri;font-size:11pt;text-align:left;color:black;BORDER-BOTTOM:medium none;BORDER-LEFT:medium none;PADDING-BOTTOM:0in;PADDING-LEFT:0in;PADDING-RIGHT:0in;BORDER-TOP:#b5c4df 1pt solid;BORDER-RIGHT:medium none;PADDING-TOP:3pt">
<span style="font-weight:bold">From: </span>Stephen Balukoff <<a href="mailto:sbalukoff@bluebox.net" target="_blank">sbalukoff@bluebox.net</a>><br>
<span style="font-weight:bold">Reply-To: </span>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Date: </span>Monday, June 23, 2014 at 5:25 PM<br>
<span style="font-weight:bold">To: </span>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [openstack-dev] [Neutron][LBaaS] Should TLS settings for listener be set through separate API/model?<br>
</div><div><div class="h5">
<div><br>
</div>
<div>
<div>
<div dir="ltr">Also to add to pros for 2:
<div><br>
</div>
<div>* 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.)<br>
</div>
<div><br>
</div>
<div>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.)</div>
<div><br>
</div>
<div>Stephen</div>
<div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Jun 23, 2014 at 3:38 PM, Brandon Logan <span dir="ltr">
<<a href="mailto:brandon.logan@rackspace.com" target="_blank">brandon.logan@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Whoops, [Neutron][LBaaS] got taken out of the subject line here.<br>
Putting it back in.<br>
<div>
<div><br>
On Mon, 2014-06-23 at 21:10 +0000, Brandon Logan wrote:<br>
> Okay so we've talked a bit about this in IRC and now I'm sending this<br>
> out as an update. Here are the options with pros and cons that have<br>
> come from that discussion.<br>
><br>
> 1) default_certificate_id is an attribute of the Listener object.<br>
><br>
> Pros:<br>
> -No extra entity needed<br>
><br>
> Cons:<br>
> -May bloat Listener object when more attributes are needed for only TLS<br>
> termination. Sounds like TLS version and cipher selection will be<br>
> needed attributes in the future.<br>
><br>
><br>
> 2) A separate TLS Entity is created that is referenced by the Listener<br>
> object. This entity at first may only contain a certificate_id that<br>
> references barbican. Name and description can be allowed as well.<br>
><br>
> Pros:<br>
> -TLS domain specific attributes contained in its own entity<br>
> -Future attributes would just be added to this entity and not bloat the<br>
> Listener object.<br>
><br>
> Cons:<br>
> -It's another entity<br>
><br>
> In IRC we (sbalukoff, myself) seemed to agree option 2 is right way to<br>
> go. Anyone agree or disagree?<br>
><br>
> Thanks,<br>
> Brandon<br>
><br>
> On Mon, 2014-06-23 at 12:15 -0700, Stephen Balukoff wrote:<br>
> > The separate entity makes sense for certificates participating in an<br>
> > SNI configuration, but probably not so much for the 'default'<br>
> > certificate used when TLS is being terminated.<br>
> ><br>
> ><br>
> > Vijay: You're also right that other TLS-related attributes will<br>
> > probably get added to the Listener object. This probably makes sense<br>
> > if they apply to the Listener object as a whole. (This includes things<br>
> > like TLS version and cipher selection.)<br>
> ><br>
> ><br>
> > I don't see much of a point in creating a separate object to contain<br>
> > these fields, since it would have a 1:1 relationship with the<br>
> > Listener. It's true that for non-TLS-terminated Listeners, these<br>
> > fields wouldn't be used, but isn't that already the case in many other<br>
> > objects (not just in the Neutron LBaaS sub project)?<br>
> ><br>
> ><br>
> > Thanks,<br>
> > Stephen<br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > On Mon, Jun 23, 2014 at 9:54 AM, Brandon Logan<br>
> > <<a href="mailto:brandon.logan@rackspace.com" target="_blank">brandon.logan@rackspace.com</a>> wrote:<br>
> > Vijay,<br>
> > I think the separate entity is still going to happen. I don't<br>
> > think it<br>
> > has remvoed. Or that is may just be my assumption.<br>
> ><br>
> > Thanks,<br>
> > Brandon<br>
> ><br>
> > On Mon, 2014-06-23 at 15:59 +0000, Vijay Venkatachalam wrote:<br>
> > > Hi:<br>
> > ><br>
> > ><br>
> > > In the “LBaaS TLS termination capability specification”<br>
> > proposal<br>
> > ><br>
> > > <a href="https://review.openstack.org/#/c/98640/" target="_blank">https://review.openstack.org/#/c/98640/</a><br>
> > ><br>
> > > TLS settings like default certificate container id and SNI<br>
> > cert list are part of the listener properties.<br>
> > ><br>
> > > I think it is better to have this as a separate entity so<br>
> > that the listener properties are clean and is not “corrupted”<br>
> > with TLS settings.<br>
> > ><br>
> > > I liked the original SSL proposal better where TLS settings<br>
> > was a separate entity.<br>
> > ><br>
> > > It is just 2 properties now but in future the TLS settings<br>
> > would grow and if we are going to introduce a TLS<br>
> > profile/params/settings entity later, it is better to do it<br>
> > now (albeit with min properties).<br>
> > ><br>
> > > Thanks,<br>
> > > Vijay V.<br>
> ><br>
> > > _______________________________________________<br>
> > > OpenStack-dev mailing list<br>
> > > <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
> > ><br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> ><br>
> > _______________________________________________<br>
> > OpenStack-dev mailing list<br>
> > <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > --<br>
> > Stephen Balukoff<br>
> > Blue Box Group, LLC<br>
> > <a href="tel:%28800%29613-4305%20x807" value="+18006134305" target="_blank">(800)613-4305 x807</a><br>
> > _______________________________________________<br>
> > OpenStack-dev mailing list<br>
> > <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<span></span>Stephen Balukoff <br>
Blue Box Group, LLC <br>
<a href="tel:%28800%29613-4305%20x807" value="+18006134305" target="_blank">(800)613-4305 x807</a> </div>
</div>
</div>
</div>
</div>
</div></div></span>
</div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><span></span>Stephen Balukoff
<br>Blue Box Group, LLC
<br>(800)613-4305 x807
</div>