<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 class=""><div class="h5"><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">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">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">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">(800)613-4305 x807</a><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>
> _______________________________________________<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>
_______________________________________________<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>
</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></div></div>