Hi Stephen, The <entity><entity>associations table name is consistent with the rest of neutron's table names, as is not breaking the table name words up by an underscore. I think this stems from the sqlalchemy models getting the table name for free because of inheriting from a base model that derives the table name based on the model's class name.
However, with markmcclain's blessing the new loadbalancing tables will be prefixed with lbaas_, but the model names will be LoadBalancer, Listener, etc. I would agree though that since sni will not be a separate table then that will be a bit odd to have an association table's name implying a join of a table that doesn't exist. Thanks, Brandon On Wed, 2014-06-25 at 09:55 -0700, Stephen Balukoff wrote: > What's the point of putting off a potential name change to the actual > code (where you're going to see more friction because names in the > code do not match names in the spec, and this becomes a point where > confusion can happen). I understand the idea that code may not exactly > match the spec, but when it's obvious that it should, why use the > wrong name in the spec? > > > Isn't it more confusing when the API does not match database object > names when it's clear the API is specifically meant to manipulate > those database objects? > > > Is that naming convention actually documented anywhere? And why are > you calling it a 'listenersniassociations'? There is no "SNI" object > in the database. (IMO, this is a terrible name that needs to be > re-read three times just to pick out where the word breaks should be! > As written it looks like "Listeners NI Associations" what the heck is > an 'NI'?) > > > They say that there are two hard problems in Computer Science: > * Cache invalidation > * Naming things > * Off-by-one errors > > > And far be it from me to pick nits about a name (OK, I guess it's > isn't that far fetched for me to pick nits. :P ), but it's hard for me > to imagine a worse name than 'listenersniassocaitions' being > considered. :P > > > Stephen > > > > > On Wed, Jun 25, 2014 at 2:05 AM, Evgeny Fedoruk <[email protected]> > wrote: > Hi folks > > > > Regarding names, there are two types of them: new API > attributes for REST call, and new column name and table name > for the database. > > When creating listener, 2 new attributes will be added to the > REST call API: > > 1. default_tls_container_id - Barbican TLS container uuid > > 2. sni_container_ids (I removed the “_list” part to make > it shorter) – ordered list of Barbican TLS container uuids > > For the database, these will be translated to: > > 1. default_tls_container_id- new column for listeners > table > > 2. listenersniassociations (changed it from > vipsniassociations which is a mistake) – new associations > table, holding: id(generated), listener_id, TLS_container_id, > and position(for ordering) > > This kind of a name comes to comply current neutron’s table > name convention, like pollmonitorassociation or > providerresourceassociation > > > > I think names may always be an issue for the actual code > review, the document is just a functional specification > > Since new objects model code is not landed yet, naming > conventions may be changed while implementing this spec. > > I will commit the document with all comments addressed and > mentioned above names. > > Please review it and give your feedback, I think we are close > to complete this one ) > > > > Thanks, > > Evg > > > > > > > > From: Vijay Venkatachalam > [mailto:[email protected]] > Sent: Wednesday, June 25, 2014 8:34 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? > > > Thanks for the details Evg! > > > > I understand there was no TLS settings API originally planned. > > > > From: Stephen Balukoff [mailto:[email protected]] > Sent: Wednesday, June 25, 2014 5:46 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? > > > > > 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 > <[email protected]> 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:[email protected]] > 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:[email protected]] > 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:[email protected]] > 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:[email protected]] > 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:[email protected]] > 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 > <[email protected]> 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 <[email protected]> > Reply-To: "OpenStack Development Mailing List (not for > usage questions)" <[email protected]> > Date: Monday, June 23, 2014 at 5:25 PM > To: "OpenStack Development Mailing List (not for usage > questions)" <[email protected]> > 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 > <[email protected]> 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 > > > <[email protected]> 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 > > > > [email protected] > > > > > > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > _______________________________________________ > > > OpenStack-dev mailing list > > > [email protected] > > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > > > > > > > > -- > > > Stephen Balukoff > > > Blue Box Group, LLC > > > (800)613-4305 x807 > > > _______________________________________________ > > > OpenStack-dev mailing list > > > [email protected] > > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > > OpenStack-dev mailing list > > [email protected] > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > -- > Stephen Balukoff > Blue Box Group, LLC > (800)613-4305 x807 > > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > -- > Stephen Balukoff > Blue Box Group, LLC > (800)613-4305 x807 > > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > -- > Stephen Balukoff > Blue Box Group, LLC > (800)613-4305 x807 > > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > -- > Stephen Balukoff > Blue Box Group, LLC > (800)613-4305 x807 > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
