[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