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

Stephen Balukoff sbalukoff at bluebox.net
Sat Jun 28 00:59:19 UTC 2014


Hi Evgeny,

Is there any reason we wouldn't want a better name for the class? Why not
simply SNIList or SNIPolicy? Or maybe something more descriptive of its
contents like SNICertificate. I don't think there's a need to mention the
listener in the class name since there is no other object in this model to
which it makes sense to attach an SNI certificate.

Is there a naming convention for referencing objects which are outside of
the current software's code base entirely (as the barbican containers are)?

Anyway, this is mostly nit-picking at this point. I hate the name, but I
don't want to delay development of this feature over this.

Stephen


On Thu, Jun 26, 2014 at 3:44 AM, Evgeny Fedoruk <EvgenyF at radware.com> wrote:

> Hi guys,
>
> Stephen, I understand your concerns regarding misleading names.
> Here are my thoughts:
> default_tls_container_id
>         This name is the same for API and database model and I think this
> name explains its meaning well.
> sni_container_ids(for API)  and listenersniassociations (for database
> table)
>         These two comes to specify the same thing - TLS container ids list
> for listener's SNI function,
>         Still there is a difference: in API it's just a list of IDs
> contained in listener's API call,
>         while in database it becomes to specify association between
> listener ID and TLS container ID in separate database table.
>         As Brandon posted, database table names in Neutron are derived
> from data model class names defining them.
>         Listenersniassociations table name is actually comes from
> ListenerSNIAssociation class that defines the table.
>         I understand there is no table for SNI object in neutron schema
> but I did not think of a better name for this association table name.
>         It could be named ListenerContainerAssociation but  this name does
> not clarify that this is for SNI and there is no Containers table in
> Neutron's schema neither)
>         Calling it ListenerSNIContainerAssociation may be too long..
>
> These are my thoughts but I may miss something, please propose alternative
> names you think of
>
> Thanks,
> Evg
>
>
>
> -----Original Message-----
> From: Brandon Logan [mailto:brandon.logan at RACKSPACE.COM]
> Sent: Wednesday, June 25, 2014 11:00 PM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [Neutron][LBaaS] Should TLS settings for
> listener be set through separate API/model?
>
> 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
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140627/69bd2130/attachment-0001.html>


More information about the OpenStack-dev mailing list