Open Stack

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.logan at 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 at lists.openstack.org
> >         >
> >         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >         
> >         _______________________________________________
> >         OpenStack-dev mailing list
> >         OpenStack-dev at 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 at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev