Open Stack

+1 for option 1. SNI list is managed by separate entity, default TLS container is part of a listener object. It will have None value when listener does not offloads TLS.
Managing another entity for 1:0-1 relationship just for future use seems not right to me. Breaking TLS settings apart from listener can be done when needed, if needed.

Thanks,
Evg


From: Stephen Balukoff [mailto:sbalukoff at bluebox.net]
Sent: Tuesday, June 24, 2014 4:26 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Should TLS settings for listener be set through separate API/model?

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?

On Mon, Jun 23, 2014 at 6:03 PM, Doug Wiegley <dougw at a10networks.com<mailto:dougw at a10networks.com>> wrote:
Put me down for being in favor of option 1.

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.

Thanks,
Doug


From: Stephen Balukoff <sbalukoff at bluebox.net<mailto:sbalukoff at bluebox.net>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Monday, June 23, 2014 at 5:25 PM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron][LBaaS] Should TLS settings for listener be set through separate API/model?

Also to add to pros for 2:

* 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.)

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.)

Stephen

On Mon, Jun 23, 2014 at 3:38 PM, Brandon Logan <brandon.logan at rackspace.com<mailto:brandon.logan at rackspace.com>> wrote:
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<mailto: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<mailto: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<mailto: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<tel:%28800%29613-4305%20x807>
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org<mailto: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<mailto: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<mailto: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<tel:%28800%29613-4305%20x807>

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140624/0be96680/attachment.html>