<div dir="ltr">Actually, I should say: The only thing I care about on this is that we not delay getting TLS implemented over what are really minor details like this. (I know we're likely going to be delayed by changes that need to happen on the barbican side since they're pretty extensive. But it seems silly to spend much energy on something so minor right now.)</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 23, 2014 at 6:25 PM, Stephen Balukoff <span dir="ltr"><<a href="mailto:sbalukoff@bluebox.net" target="_blank">sbalukoff@bluebox.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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="HOEnZb"><div class="h5"><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>
<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" 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></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></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>