[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