Evgeny-- Two minor nits:
* Your spec lists the new SNI related settings 'sni_list' (and it contains more than just IDs, so calling it 'sni_container_ids_list' is misleading). Please be precise in the terms you use, and don't switch them mid discussion. :) * Also, I personally really hate long table names when they're unnecessary. "vipsniassociations" isn't mentioned in your spec anywhere, and frankly, is a lot worse than "sni_list." I personally prefer "SNIPolicies", but I'm also OK with a short name like "sni_list". Otherwise I agree with you on all points. Stephen On Tue, Jun 24, 2014 at 3:26 AM, Evgeny Fedoruk <evge...@radware.com> wrote: > Vijay, there is no intension for a new TLS settings API. > > Creation of a listener with TLS offloading will be one-step. > > > > When tenant creates listener with TERMINATED-HTTPS protocol he must supply > default_tls_container_id for offloading. > > Not supplying default TLS container id for offloading for TERMINATED-HTTPS > listener will raise an error. > > SNI list may or may not be supplied by the tenant. Default value for SNI > certificates list is an empty list. > > > > So listener resource will have another two attributes: > default_tls_container_id and sni_container_ids_list. These are relevant for > TERMINATED-HTTPS protocol listeners only. In other cases its default value > are ‘None’ and empty list. > > In schema, Default_tls_container_id will be added to listener object as > another column. > > Sni_container_ids_list wil be managed by new table “vipsniassociations” > which has listener_id, container_id, and position (for ordering) columns > > > > Does it make sense? > > > > Thanks, > > Evg > > > > > > > > > > *From:* Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com] > *Sent:* Tuesday, June 24, 2014 12:31 PM > > *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? > > > > > > To clarify, the request is for a new TLS settings API with > “default_tls_container_id” & “sni_list”. > > > > If there is a new API, then we would have an object model reflecting this > as a separate entity. > > > > The tenant would do the following > > > > 1. Create a listener with TERMINATED_HTTPS > > 2. Set the TLS settings for the listener using > /v2.0/listener/<listenerid>/tlssettings (if at all we are having some > default values this can be reflected here) > > > > The only good thing is the separation of the TLS settings out of the > listener API. > > > > But, I can see 2 downsides > > 1. The loadbalancer creation is a 2 step procedure > > 2. We cannot enforce certificate attachment as part of the create > of listener. > > > > If the new API itself has “-1”s then I am perfectly OK with the current > object model with default_tls_container_id in listener table. > > > > Thanks, > > Vijay V. > > > > > > *From:* Evgeny Fedoruk [mailto:evge...@radware.com <evge...@radware.com>] > *Sent:* Tuesday, June 24, 2014 2:19 PM > *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? > > > > Vipsniassociations table: Line 147 in last patch of the document > > > > *From:* Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com > <vijay.venkatacha...@citrix.com>] > *Sent:* Tuesday, June 24, 2014 10:17 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? > > > > > > >>SNI list is managed by separate entity > > What is this entity? > > > > *From:* Evgeny Fedoruk [mailto:evge...@radware.com <evge...@radware.com>] > *Sent:* Tuesday, June 24, 2014 12:25 PM > *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? > > > > +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:sbaluk...@bluebox.net > <sbaluk...@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 <do...@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 <sbaluk...@bluebox.net> > *Reply-To: *"OpenStack Development Mailing List (not for usage > questions)" <openstack-dev@lists.openstack.org> > *Date: *Monday, June 23, 2014 at 5:25 PM > *To: *"OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@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.lo...@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.lo...@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@lists.openstack.org > > > > > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > _______________________________________________ > > > OpenStack-dev mailing list > > > OpenStack-dev@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@lists.openstack.org > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@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@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@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev