Re: [openstack-dev] [Neutron][LBaaS] Should TLS settings for listener be set through separate API/model?
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.lo...@rackspace.com] Sent: Wednesday, June 25, 2014 11:00 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] Should TLS settings for listener be set through separate API/model? Hi Stephen, The entityentityassociations 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 evge...@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
Re: [openstack-dev] [Neutron][LBaaS] Should TLS settings for listener be set through separate API/model?
Hi Stephen, The entityentityassociations 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 evge...@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.venkatacha...@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:sbaluk...@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
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:sbaluk...@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 do...@a10networks.commailto:do...@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 sbaluk...@bluebox.netmailto:sbaluk...@bluebox.net Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Monday, June 23, 2014 at 5:25 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@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.lo...@rackspace.commailto:brandon.lo...@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 +, 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.lo...@rackspace.commailto:brandon.lo...@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 +, 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
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.venkatacha...@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:evge...@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:sbaluk...@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 do...@a10networks.commailto:do...@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 sbaluk...@bluebox.netmailto:sbaluk...@bluebox.net Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Monday, June 23, 2014 at 5:25 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@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.lo...@rackspace.commailto:brandon.lo...@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 +, 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
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 evge...@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.venkatacha...@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:evge...@radware.com evge...@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.venkatacha...@citrix.com vijay.venkatacha...@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:evge...@radware.com evge...@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:sbaluk...@bluebox.net sbaluk...@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 do...@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
[openstack-dev] [Neutron][LBaaS]Should TLS settings for listener be set through separate API/model?
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. PS: Adding with the right subject ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Should TLS settings for listener be set through separate API/model?
Whoops, [Neutron][LBaaS] got taken out of the subject line here. Putting it back in. On Mon, 2014-06-23 at 21:10 +, 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.lo...@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 +, 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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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.lo...@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 +, 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.lo...@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 +, 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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list
Re: [openstack-dev] [Neutron][LBaaS] Should TLS settings for listener be set through separate API/model?
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 sbaluk...@bluebox.netmailto:sbaluk...@bluebox.net Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Monday, June 23, 2014 at 5:25 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@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.lo...@rackspace.commailto:brandon.lo...@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 +, 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.lo...@rackspace.commailto:brandon.lo...@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 +, 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@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http
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 do...@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 sbaluk...@bluebox.net Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Monday, June 23, 2014 at 5:25 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@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.lo...@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 +, 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.lo...@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 +, 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
Re: [openstack-dev] [Neutron][LBaaS] Should TLS settings for listener be set through separate API/model?
Actually, I should say: The only thing I care about on this is that we not delay getting TLS implemented over what are really minor details like this. (I know we're likely going to be delayed by changes that need to happen on the barbican side since they're pretty extensive. But it seems silly to spend much energy on something so minor right now.) On Mon, Jun 23, 2014 at 6:25 PM, Stephen Balukoff sbaluk...@bluebox.net wrote: 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 do...@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 sbaluk...@bluebox.net Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Monday, June 23, 2014 at 5:25 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@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.lo...@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 +, 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.lo...@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 +, 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
Re: [openstack-dev] [Neutron][LBaaS] Should TLS settings for listener be set through separate API/model?
Even though it might look like an over kill now, the model should pave way for the future. So, +1 for Option 2. From: Doug Wiegley [mailto:do...@a10networks.com] Sent: Tuesday, June 24, 2014 6:33 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? 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 sbaluk...@bluebox.netmailto:sbaluk...@bluebox.net Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Monday, June 23, 2014 at 5:25 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@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.lo...@rackspace.commailto:brandon.lo...@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 +, 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.lo...@rackspace.commailto:brandon.lo...@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 +, 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
