Open Stack

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