[openstack-dev] [Neutron][LBaaS] Should TLS settings for listener be set through separate API/model?

Brandon Logan brandon.logan at RACKSPACE.COM
Wed Jun 25 20:00:12 UTC 2014


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 <EvgenyF at radware.com>
> 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:Vijay.Venkatachalam at citrix.com] 
>         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:sbalukoff at bluebox.net] 
>         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
>         <EvgenyF at 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.Venkatachalam at 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:EvgenyF at 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.Venkatachalam at 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:EvgenyF at 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: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> 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>
>                 Reply-To: "OpenStack Development Mailing List (not for
>                 usage questions)" <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>
>                 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> 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> 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
>                 
>                 _______________________________________________
>                 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
>                 
>                 
>                 
>                 
>                  
>                 
>                 
>                 -- 
>                 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
>                 
>         
>         
>          
>         
>         
>         -- 
>         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
>         
> 
> 
> 
> 
> -- 
> 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



More information about the OpenStack-dev mailing list