Re: [openstack-dev] [Neutron][LBaaS] Object Model discussion
Hi, I think we mix different aspects of operations. And try to solve a non problem. From APIs/Operations we are mixing the following models: 1. Logical model (which as far as I understand is the topic of this discussion) - tenants define what they need logically vip--default_pool, l7 association, ssl, etc. 2. Physical model - operator / vendor install and specify how backend gets implemented. 3. Deploying 1 on 2 - this is currently the driver's responsibility. We can consider making it better but this should not impact the logical model. Another problem, which all the new proposals are trying to solve, is placing a pools which can be a root/default for a vip pool relationship also as part association with l7 policy of another vippool that is configured in another backend. I think this is not a problem. In a logical model a pool which is part of L7 policy is a logical object which could be placed at any backend and any existing vippool and accordingly configure the backend that those vippool are deployed on. If the same pool that was part of a l7 association will also be connected to a vip as a default pool, than by all means this new vippool pair can be instantiated into some back end. The proposal to not allow this (ex: only allow pools that are connected to the same lb-instance to be used for l7 association), brings the physical model into the logical model. I think that the current logical model is fine with the exception that the two way reference between vip and pool (vippool) should be modified with only vip pointing to a pool (vip--pool) which allows reusing the pool with multiple vips. This also means that all those vips will be placed on the same place as the pool they are pointing to as their default pool. Regards, -Sam. From: Eugene Nikanorov [mailto:enikano...@mirantis.com] Sent: Tuesday, February 18, 2014 9:35 PM To: OpenStack Development Mailing List Cc: Youcef Laribi; Samuel Bercovici; sbaluk...@bluebox.net; Mark McClain; Salvatore Orlando Subject: [Neutron][LBaaS] Object Model discussion Hi folks, Recently we were discussing LBaaS object model with Mark McClain in order to address several problems that we faced while approaching L7 rules and multiple vips per pool. To cut long story short: with existing workflow and model it's impossible to use L7 rules, because each pool being created is 'instance' object in itself, it defines another logical configuration and can't be attached to other existing configuration. To address this problem, plus create a base for multiple vips per pool, the 'loadbalancer' object was introduced (see https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance ). However this approach raised a concern of whether we want to let user to care about 'instance' object. My personal opinion is that letting user to work with 'loadbalancer' entity is no big deal (and might be even useful for terminological clarity; Libra and AWS APIs have that) especially if existing simple workflow is preserved, so the 'loadbalancer' entity is only required when working with L7 or multiple vips per pool. The alternative solution proposed by Mark is described here under #3: https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion In (3) the root object of the configuration is VIP, where all kinds of bindings are made (such as provider, agent, device, router). To address 'multiple vips' case another entity 'Listener' is introduced, which receives most attributes of former 'VIP' (attribute sets are not finalized on those pictures, so don't pay much attention) If you take closer look at #2 and #3 proposals, you'll see that they are essentially similar, where in #3 the VIP object takes instance/loadbalancer role from #2. Both #2 and #3 proposals make sense to me because they address both problems with L7 and multiple vips (or listeners) My concern about #3 is that it redefines lots of workflow and API aspects and even if we manage to make transition to #3 in backward-compatible way, it will be more complex in terms of code/testing, then #2 (which is on review already and works). The whole thing is important design decision, so please share your thoughts everyone. Thanks, Eugene. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] L7 - Update L7Policy
Hi, It matters, as someone might need to debug the backend setup and the name, if exists, can add details. This obviously a vendor's choice if they wish to push this back to backend but the API should not remove this as a choice. -Sam. From: Eugene Nikanorov [mailto:enikano...@mirantis.com] Sent: Monday, February 17, 2014 12:24 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] L7 - Update L7Policy Folks, I wonder why using names on the backend could be needed? For the code there is no much difference between name and the id. Thanks, Eugene. On Mon, Feb 17, 2014 at 1:57 PM, Samuel Bercovici samu...@radware.commailto:samu...@radware.com wrote: Hi, My concern is that if from some reason the driver implementer would like to reflect the name also in the backend device, than an update should also be calling the driver. Using readable names also makes sense on the back-end device. -Sam. From: Oleg Bondarev [mailto:obonda...@mirantis.commailto:obonda...@mirantis.com] Sent: Monday, February 17, 2014 11:30 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] L7 - Update L7Policy Hi, On Mon, Feb 17, 2014 at 1:23 PM, Eugene Nikanorov enikano...@mirantis.commailto:enikano...@mirantis.com wrote: Hi Avishay, 1) I think name might be useful. Consider user forms a list of rules which route requests to a pool with static images or static pages, it may make sense to give those policy a name 'static-iamges', 'static-pages', rather then operate on ids. +1 2) I think updating the name is useful as well, but just on DB level, so there is no point in calling the driver and communicating with the backend. +1 Thanks, Eugene. On Mon, Feb 17, 2014 at 12:58 PM, Avishay Balderman avish...@radware.commailto:avish...@radware.com wrote: Hi L7Policy holds a list of L7rules plus 1 attribute: name . Questions: 1) Do we need to have this name attribute? 2) Do we want to allow update operation of the name attribute? Do we need to invoke the driver when such update occurred? Thanks Avishay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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] L7 - Update L7Policy
Hi, My concern is that if from some reason the driver implementer would like to reflect the name also in the backend device, than an update should also be calling the driver. Using readable names also makes sense on the back-end device. -Sam. From: Oleg Bondarev [mailto:obonda...@mirantis.com] Sent: Monday, February 17, 2014 11:30 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] L7 - Update L7Policy Hi, On Mon, Feb 17, 2014 at 1:23 PM, Eugene Nikanorov enikano...@mirantis.commailto:enikano...@mirantis.com wrote: Hi Avishay, 1) I think name might be useful. Consider user forms a list of rules which route requests to a pool with static images or static pages, it may make sense to give those policy a name 'static-iamges', 'static-pages', rather then operate on ids. +1 2) I think updating the name is useful as well, but just on DB level, so there is no point in calling the driver and communicating with the backend. +1 Thanks, Eugene. On Mon, Feb 17, 2014 at 12:58 PM, Avishay Balderman avish...@radware.commailto:avish...@radware.com wrote: Hi L7Policy holds a list of L7rules plus 1 attribute: name . Questions: 1) Do we need to have this name attribute? 2) Do we want to allow update operation of the name attribute? Do we need to invoke the driver when such update occurred? Thanks Avishay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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] Proposal for model change - Logging configuration
Have modified the document access, let me know if you still have issues. From: Stephen Balukoff [mailto:sbaluk...@bluebox.net] Sent: Thursday, February 13, 2014 4:02 AM To: Samuel Bercovici Cc: OpenStack Development Mailing List (not for usage questions); rw3...@att.com; David Patterson; Eugene Nikanorov (enikano...@mirantis.com) Subject: Re: [openstack-dev] [Neutron][LBaaS] Proposal for model change - Logging configuration Hi Roger and Sam! Sam-- Could you please alter the permissions on that google doc so that people can add comments (at least)? Right now, it appears I have a read-only view. Roger: What you're describing seems to me like it isn't something that would apply to ceilometer integration so much as log offloading (and specifically, error log offloading). (Ceilometer is more about real-time stats than logs.) This isn't one of the features I had fleshed out on my model yet, as in our environment we dump the logs to local files (via syslog-ng) and any troubleshooting we do thereafter is done by looking at these log files on our software appliances directly (on behalf of our customers, in most cases). But I can see that having the ability to ship logs off the load balancers is going to be important. I see two possible ways of doing this: 1. Periodic archiving logs off-server. In practical terms for a software appliance, this would mean haproxy continues to log to disk as usual, then a cron job periodically rsyncs logs off the appliance to some user-defined destination. I see mostly disadvantages with this approach: * Shipping the logs can consume a lot of bandwidth when it's happening, so care would be needed in scheduling this so as not to affect production traffic going to the load balancer. * We'll have to deal with credentials for logging into the remote log archive server (and communicating and storing those credentials in a secure manner.) * Logs are not immediately available, which makes real-time troubleshooting of problems...er... problematic. * If the load balancer dies before shipping the logs off, the logs are lost. * A very busy load balancer needs to worry about disk space (and log rotation) at lot more. 2. Real-time shipping of the logs via syslog-ng. In this case, haproxy would be configured to pass its logs to syslog-ng, which is in turn configured to pass them in real time to a logging host somewhere on the network. The main advantages of this approach are: * No bandwidth-hogging periodic rsync process to deal with. * Real-time troubleshooting is now possible. * If the load balancer dies, we still get to see its last gasps just before it died. * Log rotation, etc. are not a concern. Neither is disk space on the load balancer. The main disadvantages to this approach are: * DOSing the load balancer is easier, as requests now generate extra traffic for the load balancer (to the logging host) * If the load balancer gets DOSed, the logging host might be getting DOSed as well. Given the above I'm favoring the second approach. But does anyone else have ideas with regard to how to handle this? Other attributes we might want to consider for the logging object: * Verbosity * Log format Anything else? In any case, any kind of 'logging' resource (with its various attributes) probably makes the most sense to attach in a 1:N relationship with the listener in my model (ie. one 'logging' object can be associated with many listeners.) Thanks, Stephen On Wed, Feb 12, 2014 at 1:58 AM, Samuel Bercovici samu...@radware.commailto:samu...@radware.com wrote: Hi, We plan to address LBaaS in ceilometer for Juno. A blue print was registered https://blueprints.launchpad.net/neutron/+spec/lbaas-ceilometer-integration Please use the following google document to add include requirements and thoughts at: https://docs.google.com/document/d/1mrrn6DEQkiySwx4eTaKijr0IJkJpUT3WX277aC12YFg/edit?usp=sharing Regards, -Sam. -Original Message- From: WICKES, ROGER [mailto:rw3...@att.commailto:rw3...@att.com] Sent: Tuesday, February 11, 2014 7:35 PM To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] Proposal for model [Roger] Hi Stephen! Great job! Obviously your experience is both awesome and essential here. I would ask that we add a historical archive (physically implemented as a log file, probably) object to your model. When you mentioned sending data off to Ceilometer, that triggered me to think about one problem I have had to deal with is what packet went where? in diagnosing errors usually related to having a bug on 1 out of 5 load-balanced servers, usually because of a deployed version mismatch, but could also be due to virus. When our customer sees hey every now and then this image is broken on a web page that points us to an inconsistent farm, and having the ability to trace or see which server got
Re: [openstack-dev] [Neutron][LBaaS] Proposal for model
Hi, We plan to address LBaaS in ceilometer for Juno. A blue print was registered https://blueprints.launchpad.net/neutron/+spec/lbaas-ceilometer-integration Please use the following google document to add include requirements and thoughts at: https://docs.google.com/document/d/1mrrn6DEQkiySwx4eTaKijr0IJkJpUT3WX277aC12YFg/edit?usp=sharing Regards, -Sam. -Original Message- From: WICKES, ROGER [mailto:rw3...@att.com] Sent: Tuesday, February 11, 2014 7:35 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] Proposal for model [Roger] Hi Stephen! Great job! Obviously your experience is both awesome and essential here. I would ask that we add a historical archive (physically implemented as a log file, probably) object to your model. When you mentioned sending data off to Ceilometer, that triggered me to think about one problem I have had to deal with is what packet went where? in diagnosing errors usually related to having a bug on 1 out of 5 load-balanced servers, usually because of a deployed version mismatch, but could also be due to virus. When our customer sees hey every now and then this image is broken on a web page that points us to an inconsistent farm, and having the ability to trace or see which server got that customer's packet (routed to by the LB) would really help in pinpointing the errant server. Benefits of a new model If we were to adopt either of these data models, this would enable us to eventually support the following feature sets, in the following ways (for example): Automated scaling of load-balancer services [Roger] Would the Heat module be called on to add more LB's to the farm? I talked about horizontal scaling of load balancers above under High Availability, but, at least in the case of a software appliance, vertical scaling should also be possible in an active-standby cluster_model by ** ___ 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] Proposal for model change - Layer 7 support
syntax checking without choosing one particular configuration format in which rules can be specified (in our case, haproxy). I suppose we could invent our own pseudo rule language-- but why bother when haproxy has already done this, eh? I'll take a look at the SSL stuff next, then the LoadBalancerInstance stuff... Thanks, Stephen On Tue, Feb 11, 2014 at 5:26 AM, Samuel Bercovici samu...@radware.commailto:samu...@radware.com wrote: Please review the current work in progress and comment is something is missing there. The logical load balancer API which is already addressed: • Multiple pools per VIP (ie. “layer 7” support) - https://blueprints.launchpad.net/neutron/+spec/lbaas-l7-rules. -- 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
Re: [openstack-dev] [Neutron][LBaaS] Proposal for model change - Layer 7 support
Hi Stephen, See embedded response bellow. Regards, -Sam. From: Stephen Balukoff [mailto:sbaluk...@bluebox.net] Sent: Wednesday, February 12, 2014 8:46 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Proposal for model change - Layer 7 support Howdy, Sam! Thanks also for your speedy response. Comments / additional questions are in-line below: On Wed, Feb 12, 2014 at 2:51 AM, Samuel Bercovici samu...@radware.commailto:samu...@radware.com wrote: Sam We have reviewed this based on capabilities that we belive could be supported by HA proxy and all commercial vendors. Sam What is missing? Nothing major that I could see-- I was mostly curious where the discussion took place and whether it was documented anywhere. (Again, I'm still in the process of catching up with the goings on of this project, and understand LBaaS features of Neutron have been under development for a couple years now. Doing forensics to find out this sort of thing is often tedious and fruitless-- it's usually quicker just to ask.) * Since the L7Rule object contains a position indicator, I assume, therefore, that a given L7Rule object cannot exist in more than one L7Policy, correct? Also, I assume that the first L7Rule added to an L7Policy becomes the rule at position 0 and that subsequent rules are added with incrementing positions. This is unless the position is specified, in which case, the rule is inserted into the policy list at the position specified, and all subsequent rule position indicators get incremented. Correct? Sam Correct. * Shouldn't the L7Rule object also have a l7PolicyID attribute? Sam It does. Excellent! I've updated the wiki page to reflect this. :) I shall also be endeavoring to produce an updated diagram, since I think a picture can save a lot of words here, eh. :) * It is unclear from the proposal whether a given VIP can have multiple L7VipPolicyAssociation objects associated with it. If not, then we've not really solved the problem of multiple back-end pools per VIP. If so, then the L7VipPolicyAssociation object is missing its own 'position' attribute (because order matters here, too!). Sam Correct the L7VIPPollicyassociation should have a “position” attribute. The way to implement is under consideration. Cool. Are the solutions being considered: 1. Make it at additional integer attribute of the L7VIPPolicyAssociation object. (The side effect of this is that any given L7VIPPolicyAssociation object can only be associated with one VIP.) Sam We are looking to use an integer attribute so that the combination of vip-id + ordinal number governs the order per vip. Alternatively we might just add a float column so that you can control the ordering by specifying some arbitrary floating number and the sort order will be vip + ordinal column. 2. Create an additional association object to associate the L7VIPPolicyAssociation with a VIP (ie. a join table of some kind), which carries this position attribute and would allow a given L7VIPPolicyAssociation to be associated with multiple VIPs. FWIW, I think of the above, only number 1 really makes sense. The point of the L7VIPPolicyAssociation is to associate a VIP and Pool, using the rules in a L7Policy. All that L7VIPPolicyAssociation is missing is a position attribute. As an aside, when you say, under consideration, exactly how / where is it being considered? (Again, sorry for my newbishness-- just trying to figure out how this body makes these kinds of decisions.) Sam see response above. * I assume any given pool can have multiple L7VipPolicyAssociations. If this is not the case, then a given single pool can only be associated with one VIP. Sam nope this any to any. Pools can be associated with multiple VIPs Thanks for the clarification! * There is currently no way to set a 'default' back-end pool in this proposal. Perhaps this could be solved by: * Make 'DEFAULT' one of the actions possible for a L7VipPolicyAssociation * Any L7VipPolicyAssociation with an action of 'DEFAULT' would have a null position and null L7PolicyId. * We would need to enforce having only one L7VipPolicyAssociation object with a 'DEFAULT' action per VIP. Sam the “default” behavior is governed by the current VIP -- Pool relationship. This is the canonical approach that could also be addressed by LBaaS drivers that do not support L7 content switching. Sam We will fix the VIPPool limitation (for Juno) by removing the Pool--VIP reference al only leaving the VIP -- Pool reference thus allowing the Pool to be used by multiple VIPs. This was originally planned for icehouse but will be handle for Juno. Aah-- Ok, I thought that based on recent discussions in the IRC meetings that the L7 features of LBaaS were very unlikely to make it into Icehouse, and therefore any discussion of them was essentially a discussion about
Re: [openstack-dev] [Neutron][LBaaS] Vote required for certificate as first-class citizen - SSL Termination (Revised)
Hi Stephen, To make sure I understand, which model is fine Basic/Simple or New. Thanks, -Sam. -Original Message- From: Stephen Gran [mailto:stephen.g...@theguardian.com] Sent: Thursday, December 05, 2013 8:22 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] Vote required for certificate as first-class citizen - SSL Termination (Revised) Hi, I would be happy with this model. Yes, longer term it might be nice to have an independent certificate store so that when you need to be able to validate ssl you can, but this is a good intermediate step. Cheers, On 02/12/13 09:16, Vijay Venkatachalam wrote: LBaaS enthusiasts: Your vote on the revised model for SSL Termination? Here is a comparison between the original and revised model for SSL Termination: *** Original Basic Model that was proposed in summit *** * Certificate parameters introduced as part of VIP resource. * This model is for basic config and there will be a model introduced in future for detailed use case. * Each certificate is created for one and only one VIP. * Certificate params not stored in DB and sent directly to loadbalancer. * In case of failures, there is no way to restart the operation from details stored in DB. *** Revised New Model *** * Certificate parameters will be part of an independent certificate resource. A first-class citizen handled by LBaaS plugin. * It is a forwarding looking model and aligns with AWS for uploading server certificates. * A certificate can be reused in many VIPs. * Certificate params stored in DB. * In case of failures, parameters stored in DB will be used to restore the system. A more detailed comparison can be viewed in the following link https://docs.google.com/document/d/1fFHbg3beRtmlyiryHiXlpWpRo1oWj8FqVe ZISh07iGs/edit?usp=sharing -- Stephen Gran Senior Systems Integrator - theguardian.com Please consider the environment before printing this email. -- Visit theguardian.com On your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition theguardian.com/iPad Save up to 33% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. Visit subscribe.theguardian.com This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News Media Limited A member of Guardian Media Group plc Registered Office PO Box 68164 Kings Place 90 York Way London N1P 2AP Registered in England Number 908396 -- ___ 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] Vote required for certificate as first-class citizen - SSL Termination (Revised)
Correct. Evgeny will update the WIKI accordingly. We will add a flag in the SSL Certificate to allow specifying that the private key can't be persisted. And in this case, the private key could be passed when associating the cert_id with the VIP. Regards, -Sam. -Original Message- From: Nachi Ueno [mailto:na...@ntti3.com] Sent: Thursday, December 05, 2013 8:21 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Vote required for certificate as first-class citizen - SSL Termination (Revised) Hi folks OK, It looks like we get consensus on separate resource way. Best Nachi 2013/12/5 Eugene Nikanorov enikano...@mirantis.com: Hi, My vote is for separate resource (e.g. 'New Model'). Also I'd like to see certificate handling as a separate extension/db mixing(in fact, persistence driver) similar to service_type extension. Thanks, Eugene. On Thu, Dec 5, 2013 at 2:13 PM, Stephen Gran stephen.g...@theguardian.com wrote: Hi, Right, sorry, I see that wasn't clear - I blame lack of coffee :) I would prefer the Revised New Model. I much prefer the ability to restore a loadbalancer from config in the event of node failure, and the ability to do basic sharing of certificates between VIPs. I think that a longer term plan may involve putting the certificates in a smarter system if we decide we want to do things like evaluate trust models, but just storing them locally for now will do most of what I think people want to do with SSL termination. Cheers, On 05/12/13 09:57, Samuel Bercovici wrote: Hi Stephen, To make sure I understand, which model is fine Basic/Simple or New. Thanks, -Sam. -Original Message- From: Stephen Gran [mailto:stephen.g...@theguardian.com] Sent: Thursday, December 05, 2013 8:22 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] Vote required for certificate as first-class citizen - SSL Termination (Revised) Hi, I would be happy with this model. Yes, longer term it might be nice to have an independent certificate store so that when you need to be able to validate ssl you can, but this is a good intermediate step. Cheers, On 02/12/13 09:16, Vijay Venkatachalam wrote: LBaaS enthusiasts: Your vote on the revised model for SSL Termination? Here is a comparison between the original and revised model for SSL Termination: *** Original Basic Model that was proposed in summit *** * Certificate parameters introduced as part of VIP resource. * This model is for basic config and there will be a model introduced in future for detailed use case. * Each certificate is created for one and only one VIP. * Certificate params not stored in DB and sent directly to loadbalancer. * In case of failures, there is no way to restart the operation from details stored in DB. *** Revised New Model *** * Certificate parameters will be part of an independent certificate resource. A first-class citizen handled by LBaaS plugin. * It is a forwarding looking model and aligns with AWS for uploading server certificates. * A certificate can be reused in many VIPs. * Certificate params stored in DB. * In case of failures, parameters stored in DB will be used to restore the system. A more detailed comparison can be viewed in the following link https://docs.google.com/document/d/1fFHbg3beRtmlyiryHiXlpWpRo1oWj8F qVe ZISh07iGs/edit?usp=sharing -- Stephen Gran Senior Systems Integrator - theguardian.com Please consider the environment before printing this email. -- Visit theguardian.com On your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition theguardian.com/iPad Save up to 33% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. Visit subscribe.theguardian.com This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News Media Limited A member of Guardian Media Group plc Registered Office PO Box 68164 Kings Place 90 York Way London N1P 2AP Registered in England Number 908396 - - ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [openstack-dev] [Neutron][LBaaS] Vendor feedback needed
Hi Eugene, We currently support out-of-the-box VIP and Nodes on the same network. The VIP can be associated with a floating IP if need to access from the external network. We are considering other options but will address as we get to this. Regards, -Sam. From: Eugene Nikanorov [mailto:enikano...@mirantis.com] Sent: Wednesday, December 04, 2013 1:14 PM To: OpenStack Development Mailing List Subject: [openstack-dev] [Neutron][LBaaS] Vendor feedback needed Hi load balancing vendors! I have specific question: how drivers for your solutions (devices/vms/processes) are going to wire a VIP with external and tenant networks? As we're working on creating a suite for third-party testing, we would like to make sure that scenarios that we create fits usage pattern of all providers, if it is possible at all. If it is not possible, we need to think of more comprehensive LBaaS API and tests. Thanks, Eugene. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Vote required for certificate as first-class citizen - SSL Termination (Revised)
Hi, The primary reason for the simple proposal is due to the difficult to reach consensus on how SSL certificates can be stored in OpenStack. As there is currently no trusted storage in OpenStack, the simple proposal overcomes this by pushing the SSL certificates into the load balancers which are considered trusted. If there is an agreement that storing the SSL certificates and similar information in the OpenStack database is fine, than having the feature modeled with SSL certificates and SSL policies as 1st level citizens is preferable. As Vijay mentioned, both options will support well the common use cases. Hopefully, we can get other people to vote on this and drive a decision. Regards, -Sam. -Original Message- From: Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com] Sent: Monday, December 02, 2013 11:16 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Vote required for certificate as first-class citizen - SSL Termination (Revised) LBaaS enthusiasts: Your vote on the revised model for SSL Termination? Here is a comparison between the original and revised model for SSL Termination: *** Original Basic Model that was proposed in summit *** * Certificate parameters introduced as part of VIP resource. * This model is for basic config and there will be a model introduced in future for detailed use case. * Each certificate is created for one and only one VIP. * Certificate params not stored in DB and sent directly to loadbalancer. * In case of failures, there is no way to restart the operation from details stored in DB. *** Revised New Model *** * Certificate parameters will be part of an independent certificate resource. A first-class citizen handled by LBaaS plugin. * It is a forwarding looking model and aligns with AWS for uploading server certificates. * A certificate can be reused in many VIPs. * Certificate params stored in DB. * In case of failures, parameters stored in DB will be used to restore the system. A more detailed comparison can be viewed in the following link https://docs.google.com/document/d/1fFHbg3beRtmlyiryHiXlpWpRo1oWj8FqVeZISh07iGs/edit?usp=sharing Thanks, Vijay V. -Original Message- From: Vijay Venkatachalam Sent: Friday, November 29, 2013 2:18 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Neutron][LBaaS] Vote required for certificate as first level citizen - SSL Termination To summarize: Certificate will be a first level citizen which can be reused and For certificate management nothing sophisticated is required. Can you please Vote (+1, -1)? We can move on if there is consensus around this. -Original Message- From: Stephen Gran [mailto:stephen.g...@guardian.co.uk] Sent: Wednesday, November 20, 2013 3:01 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up Hi, On Wed, 2013-11-20 at 08:24 +, Samuel Bercovici wrote: Hi, Evgeny has outlined the wiki for the proposed change at: https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL which is in line with what was discussed during the summit. The https://docs.google.com/document/d/1tFOrIa10lKr0xQyLVGsVfXr29NQBq2n YTvMkMJ_inbo/edit discuss in addition Certificate Chains. What would be the benefit of having a certificate that must be connected to VIP vs. embedding it in the VIP? You could reuse the same certificate for multiple loadbalancer VIPs. This is a fairly common pattern - we have a dev wildcard cert that is self- signed, and is used for lots of VIPs. When we get a system that can store certificates (ex: Barbican), we will add support to it in the LBaaS model. It probably doesn't need anything that complicated, does it? Cheers, -- Stephen Gran Senior Systems Integrator - The Guardian Please consider the environment before printing this email. -- Visit theguardian.com On your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition theguardian.com/iPad Save up to 33% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. Visit subscribe.theguardian.com This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e- mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should
Re: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up
Hi, Evgeny has outlined the wiki for the proposed change at: https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL which is in line with what was discussed during the summit. The https://docs.google.com/document/d/1tFOrIa10lKr0xQyLVGsVfXr29NQBq2nYTvMkMJ_inbo/edit discuss in addition Certificate Chains. What would be the benefit of having a certificate that must be connected to VIP vs. embedding it in the VIP? When we get a system that can store certificates (ex: Barbican), we will add support to it in the LBaaS model. -Sam. From: Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com] Sent: Wednesday, November 20, 2013 8:06 AM To: Eugene Nikanorov Cc: Samuel Bercovici; Avishay Balderman; openstack-dev@lists.openstack.org Subject: RE: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up Hi Eugene, The proposal is simple, create a separate resource called certificate (which will also be handled by Neutron+LBaaS plugin) rather than having them in the VIP. It will maintain the original thought of security, the certificate confidential parameters will be transient and the certificate will be directly sent to the device/driver and will not be stored. This is done by having VIP as a property in certificate. Thanks, Vijay V. From: Eugene Nikanorov [mailto:enikano...@mirantis.com] Sent: Wednesday, November 20, 2013 1:59 AM To: Vijay Venkatachalam Cc: Samuel Bercovici; Avishay Balderman; openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up Hi Vijay, Thanks for working on this. As was discussed at the summit, immediate solution seems to be passing certificates via transient fields in Vip object, which will avoid the need for certificate management (incl. storing them). If certificate management is concerned then I agree that it needs to be a separate specialized service. My thought was to have independent certificate resource with VIP uuid as one of the properties. VIP is already created and will help to identify the driver/device. The VIP property can be depreciated in the long term. I think it's a little bit forward looking at this moment, also I think that certificates are not specific for load balancing. Transient fields could help here too: client could pass certificate Id and driver of corresponding device will communicate with external service fetching corresponding certificate. Thanks, Eugene. On Tue, Nov 19, 2013 at 5:48 PM, Vijay Venkatachalam vijay.venkatacha...@citrix.commailto:vijay.venkatacha...@citrix.com wrote: Hi Sam, Eugene, Avishay, etal, Today I spent some time to create a write-up for SSL Termination not exactly design doc. Please share your comments! https://docs.google.com/document/d/1tFOrIa10lKr0xQyLVGsVfXr29NQBq2nYTvMkMJ_inbo/edit Would like comments/discussion especially on the following note: SSL Termination requires certificate management. The ideal way is to handle this via an independent IAM service. This would take time to implement so the thought was to add the certificate details in VIP resource and send them directly to device. Basically don't store the certificate key in the DB there by avoiding security concerns of maintaining certificates in controller. I would expect the certificates to become an independent resource in future thereby causing backward compatibility issues. Any ideas how to achieve this? My thought was to have independent certificate resource with VIP uuid as one of the properties. VIP is already created and will help to identify the driver/device. The VIP property can be depreciated in the long term. Thanks, Vijay V. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up
Hi Stephen, When this was discussed in the past, customer were not happy about storing their SSL certificates in the OpenStack database as plain fields as they felt that this is not secured enough. Do you say, that you are OK with storing SSL certificates in the OpenStack database? -Sam. -Original Message- From: Stephen Gran [mailto:stephen.g...@theguardian.com] Sent: Wednesday, November 20, 2013 10:15 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up On 19/11/13 16:33, Clint Byrum wrote: Excerpts from Vijay Venkatachalam's message of 2013-11-19 05:48:43 -0800: Hi Sam, Eugene, Avishay, etal, Today I spent some time to create a write-up for SSL Termination not exactly design doc. Please share your comments! https://docs.google.com/document/d/1tFOrIa10lKr0xQyLVGsVfXr29NQBq2nYT vMkMJ_inbo/edit Would like comments/discussion especially on the following note: SSL Termination requires certificate management. The ideal way is to handle this via an independent IAM service. This would take time to implement so the thought was to add the certificate details in VIP resource and send them directly to device. Basically don't store the certificate key in the DB there by avoiding security concerns of maintaining certificates in controller. I don't see why it does. Nothing in openstack needs to trust user-uploaded certs. Just storing them as independent certificate objects that can be referenced by N VIPs makes sense to me. If the backend is SSL, I would think you could do one of: a) upload client certs b) upload CA that has signed backend certs c) opt to disable cert checking for backends With the default being c). Cheers, -- Stephen Gran Senior Systems Integrator - theguardian.com Please consider the environment before printing this email. -- Visit theguardian.com On your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition theguardian.com/iPad Save up to 33% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. Visit subscribe.theguardian.com This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News Media Limited A member of Guardian Media Group plc Registered Office PO Box 68164 Kings Place 90 York Way London N1P 2AP Registered in England Number 908396 -- ___ 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] SSL Termination write-up
HI, Besides a forward looking model do you see other differences? -Sam. -Original Message- From: Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com] Sent: Wednesday, November 20, 2013 1:22 PM To: stephen.g...@guardian.co.uk; OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up -Original Message- From: Stephen Gran [mailto:stephen.g...@guardian.co.uk] Sent: Wednesday, November 20, 2013 3:01 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up Hi, On Wed, 2013-11-20 at 08:24 +, Samuel Bercovici wrote: Hi, Evgeny has outlined the wiki for the proposed change at: https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL which is in line with what was discussed during the summit. The https://docs.google.com/document/d/1tFOrIa10lKr0xQyLVGsVfXr29NQBq2n YTvMkMJ_inbo/edit discuss in addition Certificate Chains. What would be the benefit of having a certificate that must be connected to VIP vs. embedding it in the VIP? You could reuse the same certificate for multiple loadbalancer VIPs. This is a fairly common pattern - we have a dev wildcard cert that is self- signed, and is used for lots of VIPs. If certificates can be totally independent and can be reused, it will be awesome. But even otherwise, certificate connected to VIP is just better modeling and provides an easier migration path towards an independent certificate resource. When we get a system that can store certificates (ex: Barbican), we will add support to it in the LBaaS model. It probably doesn't need anything that complicated, does it? Cheers, -- Stephen Gran Senior Systems Integrator - The Guardian Please consider the environment before printing this email. -- Visit theguardian.com On your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition theguardian.com/iPad Save up to 33% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. Visit subscribe.theguardian.com This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e- mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News Media Limited A member of Guardian Media Group plc Registered Office PO Box 68164 Kings Place 90 York Way London N1P 2AP Registered in England Number 908396 -- ___ 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] Loadbalancer instance design.
Eugene and Mark, We get interest in the current OpenStack LBaaS solution. Backward compatibility should be considered as part of any feature we add for icehouse. I think that the any such BP should first address the best way to implement the feature (as Eugene did) but then also solve the backward compatibility issue as well. Thanks, -Sam. From: Eugene Nikanorov [mailto:enikano...@mirantis.com] Sent: Monday, November 18, 2013 6:52 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Loadbalancer instance design. How do you plan to handle API compatibility? The new API is not compatible and i think there was a consensus that such change is needed and incompatibility is justified. Is an extension for each (eg. add router_id to a loadblancer resource) necessary ? Basically, yes, there should be an extension for each kind of binding with the exception that binding to providers is a part of lbaas API. Thanks, Eugene. On Mon, Nov 18, 2013 at 7:26 AM, Itsuro ODA o...@valinux.co.jpmailto:o...@valinux.co.jp wrote: Hi, 2. Loadbalancer can be used to bind configuration to a provider, device, agent (host), router What's the plan about this ? Is an extension for each (eg. add router_id to a loadblancer resource) necessary ? Thanks. Itsuro Oda On Fri, 15 Nov 2013 17:14:47 +0400 Eugene Nikanorov enikano...@mirantis.commailto:enikano...@mirantis.com wrote: Hi folks, I've created a brief description of this feature. You can find it here: https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstancehttps://blueprints.launchpad.net/neutron/+spec/lbaas-service-instance I would appreciate any comments/ideas about this. Thanks, Eugene. -- Itsuro ODA o...@valinux.co.jpmailto:o...@valinux.co.jp ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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] Loadbalancer instance design.
Hi, I think that in the Atlas/Libra model loadbalancer is used in a similar way as the VIP object in Neutron/LBaaS. Regards, -Sam. -Original Message- From: Andrew Hutchings [mailto:and...@linuxjedi.co.uk] Sent: Monday, November 18, 2013 5:23 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] Loadbalancer instance design. -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey Monty, On 18/11/13 15:17, Monty Taylor wrote: On 11/18/2013 07:14 AM, Andrew Hutchings wrote: Hi, On 15/11/13 13:14, Eugene Nikanorov wrote: I've created a brief description of this feature. You can find it here: https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance https://blueprints.launchpad.net/neutron/+spec/lbaas-service-instance I would appreciate any comments/ideas about this. This does seem very similar to what Stackforge/Libra already does. If they are similar, is there any chance the libra work can be leveraged? Very likely. I'm in the process of planning an open Libra LBaaS meeting in Seattle next month. I'm more than happy to help collaborate on ideas for that. Kind Regards - -- Andrew Hutchings - LinuxJedi - http://www.linuxjedi.co.uk/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSijDcAAoJEJfFW8uxApB2Z/QIAJE8Pb5bipN2ShRYVrSSzPlk h6DpEKjHGJTo6869Zr0f4RmVRutyNZoEWHuu8glfUm1Dnl3bmXpeQ2brBlAyIEPS F2vv3VsRK6mirXrRRVS/xYxHebOmHeltXFEmebPSPi+mYxte4r+NOh5hNHn3vBts qEPr1hT1FW6AQxAw+P1sVaHeiAh648nH1FJFFe2Pw5KmBtJwYJHZy+C7l/4bGzQt Ur1ZTZLPrvHusPQp1+jkhlW/1zK5i8dyOpwMBho9TBfbhQxL7rmgukG453aj2Cf6 1462tQOJA2LzKHOV+lVeeqEzNbvPejEJyknHW3GgYl+CwysCSqXo/AAsfIiGdgU= =wivP -END PGP SIGNATURE- ___ 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] LBaaS subteam meeting Thursday, 14, at 14-00 UTC
Hi, I will not be able to join the meeting this time. For item 1. We are starting to work on SSL termination and L7 based routing. Regards, -Sam. On Nov 12, 2013, at 9:30 PM, Eugene Nikanorov enikano...@mirantis.commailto:enikano...@mirantis.com wrote: Hi folks, LBaaS subteam meeting will be held on Thursday, 14 at 14-00 UTC on #openstack-meeting irc channel on freenode, as specified in https://wiki.openstack.org/wiki/Meetings#LBaaS_meeting The agenda is the following: 1. Blueprint list to be proposed for the icehouse-1 2. QA third-party testing 3. dev resources evaluation 4. Additional features requested by users. Thanks, Eugene. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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] Object status and admin_state_up
Hi, I think that the current implementation is fine. This are two different aspects. The status describes whether the last a-sync activity is active or whether it is not. The admin status describes what the user wishes for the object status to be. Follows an example: If I update the VIP with admin status down, the status should be moved to PENDING_UPDATE, when the driver implements this than the status with be back to being ACTIVE. The Term ACTIVE, might be wrong in that it might be renamed to something like APPLIED. Regards, -Sam. From: Eugene Nikanorov [mailto:enikano...@mirantis.com] Sent: Tuesday, October 29, 2013 11:19 AM To: OpenStack Development Mailing List Subject: [openstack-dev] [Neutron][LBaaS] Object status and admin_state_up Hi folks, Currently there are two attributes of vips/pools/members that represent a status: 'status' and 'admin_state_up'. The first one is used to represent deployment status and can be PENDING_CREATE, ACTIVE, PENDING_DELETE, ERROR. We also have admin_state_up which could be True or False. I'd like to know your opinion on how to change 'status' attribute based on admin_state_up changes. For instance. If admin_state_up is updated to be False, how do you think 'status' should change? Also, speaking of reference implementation (HAProxy), changing vip or pool admin_state_up to False effectively destroys the balancer (undeploys it), while the objects remain in ACTIVE state. There are two options to fix this discrepancy: 1) Change status of vip/pool to PENDING_CREATE if admin_state_up changes to False 2) Don't destroy the loadbalancer and use HAProxy capability to disable frontend and backend while leave vip/pool in ACTIVE state Please share your opinion. Thanks, Eugene. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Thursday meeting follow-up
Hi, I have created two document to discuss SSL termination and L7 Rules at: SSL termination : https://docs.google.com/document/d/1qnoJLD1txY5wnjx4k480AtEGCOEtkPMvTzxPo3_DPcs/edit?usp=sharing SSL BP: https://blueprints.launchpad.net/neutron/+spec/lbaas-ssl-termination L7 Rules: https://docs.google.com/document/d/1Dm6fWxHmsgO6gXFWaYf-Ce36vYpMB0L13ASrB_BZ0Bc/edit?usp=sharing L7 BP: https://blueprints.launchpad.net/neutron/+spec/lbaas-l7-rules Please feel free to comment on the documents. We can also discuss at the summit. Regards, -Sam. From: Eugene Nikanorov [mailto:enikano...@mirantis.com] Sent: Friday, October 25, 2013 6:09 PM To: OpenStack Development Mailing List Subject: [openstack-dev] [Neutron][LBaaS] Thursday meeting follow-up Hi folks, Thanks to everyone who joined the meeting on Thursday. We've discussed desired features and changes in LBaaS service and identified dependencies between them. You can find them on etherpad: https://etherpad.openstack.org/p/neutron-icehouse-lbaas Most of the features are also captured in the document shared by Sam: https://docs.google.com/document/d/1Vjm57lh7PnXDelOy-VxsJkzc8QRiNN368sS11ePs_vA/edit?pli=1#https://docs.google.com/document/d/1Vjm57lh7PnXDelOy-VxsJkzc8QRiNN368sS11ePs_vA/edit?pli=1 IRC meeting logs: http://paste.openstack.org/show/49561/ Thanks, Eugene. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] LBaaS plans for Icehouse
Hi, Please find a summary of talks and discussion related to LBaaS for the summit at: https://docs.google.com/document/d/1Vjm57lh7PnXDelOy-VxsJkzc8QRiNN368sS11ePs_vA/edit?pli=1#heading=h.6doqijxd389j I have also added the list bellow to it. We can review in the meeting today. Regards, -Sam. -Original Message- From: Itsuro ODA [mailto:o...@valinux.co.jp] Sent: Thursday, October 24, 2013 9:53 AM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [Neutron][LBaaS] LBaaS plans for Icehouse Hi, We have submitted the following LBaaS related BPs: https://blueprints.launchpad.net/neutron/+spec/lbaas-support-routed-service-insertion https://blueprints.launchpad.net/neutron/+spec/lbaas-lvs-driver https://blueprints.launchpad.net/neutron/+spec/lbaas-lvs-extra-features I can't attend the meeting but I will check the meeting log later. Thanks. Itsuro Oda On Wed, 23 Oct 2013 21:57:13 +0400 Eugene Nikanorov enikano...@mirantis.com wrote: So currently it moves to 10AM PDT Thanks, Eugene. -- Itsuro ODA o...@valinux.co.jp ___ 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] LBaaS plans for Icehouse
Hi, I assume you are proposing 8:00AM and not 8:00PM PDT. I will not be able to attend on this time. Better time for me is between 10:00AM PDT - 12:00AM PDT Thanks, -Sam. From: Eugene Nikanorov [mailto:enikano...@mirantis.com] Sent: Wednesday, October 23, 2013 11:51 AM To: OpenStack Development Mailing List Subject: [openstack-dev] [Neutron][LBaaS] LBaaS plans for Icehouse Hi Neutron folks! We're going to have an IRC meeting where we will discuss development plans for LBaaS in Icehouse. Currently I'm proposing to meet on Thursday, 24 at 8:00 PDT on freenode #neutron-lbaas channel. Agenda for the meeting: 1. New features for lbaas in Icehouse Pretty much everything vendors expect to be impl in Icehouse should be briefly covered. 2. Feature ordering/dependencies 3. Dev resources evaluation If the time is not convenient for you, please suggest another time. (It's better to have it this week) Thanks, Eugene. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] PTL Candidacy
Hi, Although not a voting member, I would like to thank Mark for a phenomenal job on Neutron and LBaaS and would like to see him continue to lead Neutron forward. Regards, -Sam. -Original Message- From: Mark McClain [mailto:mark.mccl...@dreamhost.com] Sent: Friday, September 20, 2013 11:44 PM To: OpenStack Development Mailing List Subject: [openstack-dev] [Neutron] PTL Candidacy Hi- I writing to announce my candidacy for the OpenStack Networking (Neutron) PTL. I am the current Neutron PTL. Our team continued to grow during the Havana cycle and both existing and new contributors worked to deliver double the number of blueprints than the previous release. Our vibrant ecosystem makes me excited for the future of Neutron and I would love to continue as the PTL. Qualifications --- I am a Neutron core developer with 13 years of commercial Python development experience. During my career, I have developed and deployed network applications based on the same underlying libraries used throughout Neutron. I started contributing to Neutron project during the Essex development cycle. In Folsom, I was promoted to core and was the primary developer of the DHCP implementation and Neutron's network namespace library. During Grizzly, I worked on the metadata service, database migrations, and LBaaS reference implementation. Havana Accomplishments During the Havana cycle, I worked as a developer, core team member, and a technical lead. - Planned and implemented the Quantum to Neutron name change. - Most active reviewer on the Neutron team (http://russellbryant.net/openstack-stats/neutron-reviewers-180.txt) - Organized the Networking track at the Havana Design Summit. - Led bug triaging and sub-team assignment. - Interfaced with vendors new to Neutron and helped in the integration of their plugins. - Assisted members of the community to further their understanding of Neutron and improve Python development best practices. - Promoted Neutron by delivering presentations at conferences and regional meet ups worldwide. Icehouse - During the Icehouse development cycle, I'd like to see the team focus on: - Continuing to grow the community of contributors and code reviewers. - Improving documentation for both deployers and developers. - Build upon the services added in Havana to extend and improve load balancing, firewalling, and VPN. - Integrating plugins from vendors new to the community including FWaaS, LBaaS, ML2, VPNaaS plugins/drivers. - More efficient Neutron system testing and gating including full Tempest testing. - Further work to ease deploying at scale. - Refactoring the API layer to leverage a common WSGI framework as other OpenStack projects. - Improving database resource modeling and extension management. - Unified network service management framework. - Continued support of the Horizon team to assist with Neutron integration. - Defined migration path from nova-network to Quantum. I'd love the opportunity to continue as the PTL and work with the Neutron team to fill in the gaps during the design summit in Hong Kong. Thanks, mark ___ 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] [Nova]Connecting a VM from one tenant to a non-shared network in another tenant
Hi,
The bug opened in Nova https://bugs.launchpad.net/nova/+bug/1221320 has a fix
pending core nova developer approval.
The 2nd bug opened for Neutron is fixed and approved.
As we need this quite urgently to complete our testing in time for Havana, I
would appreciate if another core reviewer will review
https://review.openstack.org/#/c/45691/ and hopefully will approve.
Regards,
-Sam.
From: Avishay Balderman
Sent: Sunday, September 08, 2013 11:15 AM
To: OpenStack Development Mailing List; gong...@unitedstack.com
Subject: Re: [openstack-dev] [Neutron]Connecting a VM from one tenant to a
non-shared network in another tenant
Hi
I have opened two bugs that are related to the topic below:
https://bugs.launchpad.net/neutron/+bug/1221315
https://bugs.launchpad.net/nova/+bug/1221320
Thanks
Avishay
From: Samuel Bercovici
Sent: Wednesday, August 07, 2013 1:05 PM
To: OpenStack Development Mailing List;
gong...@unitedstack.commailto:gong...@unitedstack.com
Subject: Re: [openstack-dev] [Neutron]Connecting a VM from one tenant to a
non-shared network in another tenant
Hi Yong,
Garry has recommended that I will you the following:
In: /opt/stack/nova/nova/network/neutronv2/api.py
In the def _get_available_networks function, the developer has added a specific
line of code filtering networks by the tenant_id.
Around line 123: search_opts = {tenant_id: project_id, 'shared': False}
As far as I understand, Neutron already filters non-shared networks by the
tenant ID, so why do we need this explicit filter, even more, I think that the
behavior of neutron will also return the shared network in addition to the
private ones by default so instead of the code doing two calls it could only do
one call to Neutron with if needed filtering by net_ids.
Do you see a reason why the code should remain as is?
Thanks,
-Sam.
From: Samuel Bercovici
Sent: Thursday, August 01, 2013 10:58 AM
To: OpenStack Development Mailing List;
sorla...@nicira.commailto:sorla...@nicira.com
Subject: Re: [openstack-dev] [Neutron]Connecting a VM from one tenant to a
non-shared network in another tenant
There was another patch needed:
In: /opt/stack/nova/nova/network/neutronv2/api.py
In the def _get_available_networks function, the developer has added a specific
line of code filtering networks by the tenant_id.
In general as far as I understand, this might be unneeded as quantum will
already filter the networks based on the tenant_id in the context while if
is_admin, will elevate and return all networks which I belive is the behavior
we want.
Do you think this can somehow be solved only on neutron side or must it also be
done by rmoving the tenant_id filter in the nova side?
When removing the filter of tenant_id + the pathc bellow, I get the behavior
that as admin, I can createVMs connected to another tenants private network but
as non-admin I am not able to do so.
Regards,
-Sam.
From: Samuel Bercovici
Sent: Wednesday, July 31, 2013 7:32 PM
To: OpenStack Development Mailing List;
sorla...@nicira.commailto:sorla...@nicira.com
Subject: Re: [openstack-dev] [Neutron]Connecting a VM from one tenant to a
non-shared network in another tenant
Hi Slavatore,
I thought that creating a qport would be enough but it looks like I still
missing something else.
I have commented in /opt/stack/quantum/neutron/api/v2/base.py in the create
function the ._validate_network_tenant_ownership call.
I can now as an Admin user, can create a qport from tenant-a that is mapped to
a private network in tenant-b.
The following still fails with ERROR: The resource could not be found. (HTTP
404) ...
nova boot --flavor 1 --image image-id --nic port-id=port-id
Where port-id is the one I got from the port-create
Any ideas where I should look next?
Regards,
-Sam.
From: Salvatore Orlando [mailto:sorla...@nicira.com]
Sent: Wednesday, July 31, 2013 5:42 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Neutron]Connecting a VM from one tenant to a
non-shared network in another tenant
Hi Sam,
is what you're trying to do tantamount to creating a port on a network whose
tenant_id is different from the network's tenant_id?
We have at the moment a fairly strict ownership check - which does not allow
even admin users to do this operation.
I do not have a strong opinion against relaxing the check, and allowing admin
users to create ports on any network - I don't think this would constitute a
potential vulnerability, as in neutron is someone's manages to impersonate an
admin user, he/she can make much more damage.
Salvatore
On 31 July 2013 16:11, Samuel Bercovici
samu...@radware.commailto:samu...@radware.com wrote:
Hi All,
We are providing load balancing services via virtual machines running under an
admin tenant that needs to be connected to VMs attached to a non-shared/private
tenant network.
The virtual machine fails to be provisioned connected to the private
Re: [openstack-dev] [Neutron]Connecting a VM from one tenant to a non-shared network in another tenant
There was another patch needed: In: /opt/stack/nova/nova/network/neutronv2/api.py In the def _get_available_networks function, the developer has added a specific line of code filtering networks by the tenant_id. In general as far as I understand, this might be unneeded as quantum will already filter the networks based on the tenant_id in the context while if is_admin, will elevate and return all networks which I belive is the behavior we want. Do you think this can somehow be solved only on neutron side or must it also be done by rmoving the tenant_id filter in the nova side? When removing the filter of tenant_id + the pathc bellow, I get the behavior that as admin, I can createVMs connected to another tenants private network but as non-admin I am not able to do so. Regards, -Sam. From: Samuel Bercovici Sent: Wednesday, July 31, 2013 7:32 PM To: OpenStack Development Mailing List; sorla...@nicira.com Subject: Re: [openstack-dev] [Neutron]Connecting a VM from one tenant to a non-shared network in another tenant Hi Slavatore, I thought that creating a qport would be enough but it looks like I still missing something else. I have commented in /opt/stack/quantum/neutron/api/v2/base.py in the create function the ._validate_network_tenant_ownership call. I can now as an Admin user, can create a qport from tenant-a that is mapped to a private network in tenant-b. The following still fails with ERROR: The resource could not be found. (HTTP 404) ... nova boot --flavor 1 --image image-id --nic port-id=port-id Where port-id is the one I got from the port-create Any ideas where I should look next? Regards, -Sam. From: Salvatore Orlando [mailto:sorla...@nicira.com] Sent: Wednesday, July 31, 2013 5:42 PM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [Neutron]Connecting a VM from one tenant to a non-shared network in another tenant Hi Sam, is what you're trying to do tantamount to creating a port on a network whose tenant_id is different from the network's tenant_id? We have at the moment a fairly strict ownership check - which does not allow even admin users to do this operation. I do not have a strong opinion against relaxing the check, and allowing admin users to create ports on any network - I don't think this would constitute a potential vulnerability, as in neutron is someone's manages to impersonate an admin user, he/she can make much more damage. Salvatore On 31 July 2013 16:11, Samuel Bercovici samu...@radware.commailto:samu...@radware.com wrote: Hi All, We are providing load balancing services via virtual machines running under an admin tenant that needs to be connected to VMs attached to a non-shared/private tenant network. The virtual machine fails to be provisioned connected to the private tenant network event if it is provisioned using the admin user which has admin role on both tenants. Please advise? Best Regards, -Sam. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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]Connecting a VM from one tenant to a non-shared network in another tenant
Hi Slavatore, I thought that creating a qport would be enough but it looks like I still missing something else. I have commented in /opt/stack/quantum/neutron/api/v2/base.py in the create function the ._validate_network_tenant_ownership call. I can now as an Admin user, can create a qport from tenant-a that is mapped to a private network in tenant-b. The following still fails with ERROR: The resource could not be found. (HTTP 404) ... nova boot --flavor 1 --image image-id --nic port-id=port-id Where port-id is the one I got from the port-create Any ideas where I should look next? Regards, -Sam. From: Salvatore Orlando [mailto:sorla...@nicira.com] Sent: Wednesday, July 31, 2013 5:42 PM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [Neutron]Connecting a VM from one tenant to a non-shared network in another tenant Hi Sam, is what you're trying to do tantamount to creating a port on a network whose tenant_id is different from the network's tenant_id? We have at the moment a fairly strict ownership check - which does not allow even admin users to do this operation. I do not have a strong opinion against relaxing the check, and allowing admin users to create ports on any network - I don't think this would constitute a potential vulnerability, as in neutron is someone's manages to impersonate an admin user, he/she can make much more damage. Salvatore On 31 July 2013 16:11, Samuel Bercovici samu...@radware.commailto:samu...@radware.com wrote: Hi All, We are providing load balancing services via virtual machines running under an admin tenant that needs to be connected to VMs attached to a non-shared/private tenant network. The virtual machine fails to be provisioned connected to the private tenant network event if it is provisioned using the admin user which has admin role on both tenants. Please advise? Best Regards, -Sam. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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] Chalenges with highly available service VMs - port adn security group options.
Hi, I had to patch the security groups to add the following rule, otherwise broadcast is blocked: -m pkttype --pkt-type multicast -j RETURN Ex: In /opt/stack/quantum/quantum/agent/linux/iptables_firewall.py def _allow_multicats_rule(self, iptables_rules): iptables_rules += ['-m pkttype --pkt-type multicast -j RETURN'] return iptables_rules def _convert_sgr_to_iptables_rules(self, security_group_rules): iptables_rules = [] self._drop_invalid_packets(iptables_rules) self._allow_established(iptables_rules) self._allow_multicats_rule(iptables_rules) From: Aaron Rosen [mailto:aro...@nicira.com] Sent: Wednesday, July 24, 2013 11:58 PM To: Samuel Bercovici Cc: OpenStack Development Mailing List; sorla...@nicira.com; Avishay Balderman; gary.kot...@gmail.com Subject: Re: [openstack-dev] [Neutron] Chalenges with highly available service VMs - port adn security group options. On Wed, Jul 24, 2013 at 12:42 AM, Samuel Bercovici samu...@radware.commailto:samu...@radware.com wrote: Hi, This might be apparent but not to me. Can you point to how broadcast can be turned on a network/port? There is currently no way to prevent it so it's on by default. As for the https://github.com/openstack/neutron/blob/master/neutron/extensions/portsecurity.py, in NVP, does this totally disable port security on a port/network or it just disable the MAC/IP checks and still allows the user defined port security to take effect? Port security is currently obtained from the fixed_ips and mac_address field on the port. This removes the filtering done on fixed_ips and mac_address fields when disabled. This looks like an extension only implemented by NVP, do you know if there are similar implementations for other plugins? No, the other plugins do not currently have a way to disable spoofing dynamically (only globally disabled). Regards, -Sam. From: Aaron Rosen [mailto:aro...@nicira.commailto:aro...@nicira.com] Sent: Tuesday, July 23, 2013 10:52 PM To: Samuel Bercovici Cc: OpenStack Development Mailing List; sorla...@nicira.commailto:sorla...@nicira.com; Avishay Balderman; gary.kot...@gmail.commailto:gary.kot...@gmail.com Subject: Re: [openstack-dev] [Neutron] Chalenges with highly available service VMs - port adn security group options. I agree too. I've posted a work in progress of this here if you want to start looking at it: https://review.openstack.org/#/c/38230/ Thanks, Aaron On Tue, Jul 23, 2013 at 4:21 AM, Samuel Bercovici samu...@radware.commailto:samu...@radware.com wrote: Hi, I agree that the AutZ should be separated and the service provider should be able to control this based on their model. For Service VMs who might be serving ~100-~1000 IPs and might use multiple MACs per port, it would be better to turn this off altogether that to have an IPTABLE rules with thousands of entries. This why I prefer to be able to turn-off IP spoofing and turn-off MAC spoofing altogether. Still from a logical model / declarative reasons an IP that can migrate between different ports should be declared as such and maybe also from MAC perspective. Regards, -Sam. From: Salvatore Orlando [mailto:sorla...@nicira.commailto:sorla...@nicira.com] Sent: Sunday, July 21, 2013 9:56 PM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [Neutron] Chalenges with highly available service VMs - port adn security group options. On 19 July 2013 13:14, Aaron Rosen aro...@nicira.commailto:aro...@nicira.com wrote: On Fri, Jul 19, 2013 at 1:55 AM, Samuel Bercovici samu...@radware.commailto:samu...@radware.com wrote: Hi, I have completely missed this discussion as it does not have quantum/Neutron in the subject (modify it now) I think that the security group is the right place to control this. I think that this might be only allowed to admins. I think this shouldn't be admin only since tenant's have control of their own networks they should be allowed to do this. I reiterate my point that the authZ model for a feature should always be completely separated by the business logic of the feature itself. In my opinion there are grounds both for scoping it as admin only and for allowing tenants to use it; it might be better if we just let the policy engine deal with this. Let me explain what we need which is more than just disable spoofing. 1. Be able to allow MACs which are not defined on the port level to transmit packets (for example VRRP MACs)== turn off MAC spoofing For this it seems you would need to implement the port security extension which allows one to enable/disable port spoofing on a port. This would be one way of doing it. The other would probably be adding a list of allowed VRRP MACs, which should be possible with the blueprint pointed by Aaron. 2. Be able to allow IPs which are not defined on the port level to transmit packets (for example, IP used for HA service
Re: [openstack-dev] [Neutron] Chalenges with highly available service VMs - port adn security group options.
Hi, I have completely missed this discussion as it does not have quantum/Neutron in the subject (modify it now) I think that the security group is the right place to control this. I think that this might be only allowed to admins. Let me explain what we need which is more than just disable spoofing. 1. Be able to allow MACs which are not defined on the port level to transmit packets (for example VRRP MACs)== turn off MAC spoofing 2. Be able to allow IPs which are not defined on the port level to transmit packets (for example, IP used for HA service that moves between an HA pair) == turn off IP spoofing 3. Be able to allow broadcast message on the port (for example for VRRP broadcast) == allow broadcast. Regards, -Sam. From: Aaron Rosen [mailto:aro...@nicira.com] Sent: Friday, July 19, 2013 3:26 AM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] Chalenges with highly available service VMs Yup: I'm definitely happy to review and give hints. Blueprint: https://docs.google.com/document/d/18trYtq3wb0eJK2CapktN415FRIVasr7UkTpWn9mLq5M/edit https://review.openstack.org/#/c/19279/ patch that merged the feature; Aaron On Thu, Jul 18, 2013 at 5:15 PM, Ian Wells ijw.ubu...@cack.org.ukmailto:ijw.ubu...@cack.org.uk wrote: On 18 July 2013 19:48, Aaron Rosen aro...@nicira.commailto:aro...@nicira.com wrote: Is there something this is missing that could be added to cover your use case? I'd be curious to hear where this doesn't work for your case. One would need to implement the port_security extension if they want to completely allow all ips/macs to pass and they could state which ones are explicitly allowed with the allowed-address-pair extension (at least that is my current thought). Yes - have you got docs on the port security extension? All I've found so far are http://docs.openstack.org/developer/quantum/api/quantum.extensions.portsecurity.html and the fact that it's only the Nicira plugin that implements it. I could implement it for something else, but not without a few hints... -- Ian. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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] Chalenges with highly available service VMs - port adn security group options.
Adding the original people conversing on this subject to this mail. Regards, -Sam. On Jul 19, 2013, at 11:57 AM, Samuel Bercovici samu...@radware.commailto:samu...@radware.com wrote: Hi, I have completely missed this discussion as it does not have quantum/Neutron in the subject (modify it now) I think that the security group is the right place to control this. I think that this might be only allowed to admins. Let me explain what we need which is more than just disable spoofing. 1. Be able to allow MACs which are not defined on the port level to transmit packets (for example VRRP MACs)== turn off MAC spoofing 2. Be able to allow IPs which are not defined on the port level to transmit packets (for example, IP used for HA service that moves between an HA pair) == turn off IP spoofing 3. Be able to allow broadcast message on the port (for example for VRRP broadcast) == allow broadcast. Regards, -Sam. From: Aaron Rosen [mailto:aro...@nicira.com] Sent: Friday, July 19, 2013 3:26 AM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] Chalenges with highly available service VMs Yup: I'm definitely happy to review and give hints. Blueprint: https://docs.google.com/document/d/18trYtq3wb0eJK2CapktN415FRIVasr7UkTpWn9mLq5M/edit https://review.openstack.org/#/c/19279/ patch that merged the feature; Aaron On Thu, Jul 18, 2013 at 5:15 PM, Ian Wells ijw.ubu...@cack.org.ukmailto:ijw.ubu...@cack.org.uk wrote: On 18 July 2013 19:48, Aaron Rosen aro...@nicira.commailto:aro...@nicira.com wrote: Is there something this is missing that could be added to cover your use case? I'd be curious to hear where this doesn't work for your case. One would need to implement the port_security extension if they want to completely allow all ips/macs to pass and they could state which ones are explicitly allowed with the allowed-address-pair extension (at least that is my current thought). Yes - have you got docs on the port security extension? All I've found so far are http://docs.openstack.org/developer/quantum/api/quantum.extensions.portsecurity.html and the fact that it's only the Nicira plugin that implements it. I could implement it for something else, but not without a few hints... -- Ian. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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] [Quantum][LBaaS] Feedback needed: Healthmonitor workflow.
Hi, I agree with this. We are facing challenges when the global health pool is changed to atomically modify all the groups that are linked to this health check as the groups might be configured in different devices. So if one of the group modification fails it is very difficult to revert the change back. -Sam. From: Eugene Nikanorov [mailto:enikano...@mirantis.com] Sent: Thursday, June 20, 2013 3:10 PM To: OpenStack Development Mailing List Cc: Avishay Balderman; Samuel Bercovici Subject: [Quantum][LBaaS] Feedback needed: Healthmonitor workflow. Hi community, Here's a question. Currently Health monitors in Loadbalancer service are made in such way that health monitor itself is a global shared database object. If user wants to add health monitor to a pool, it adds association between pool and health monitor. In order to update existing health monitor (change url, for example) service will need to go over existing pool-health monitor associations notifying devices of this change. I think it could be changed to the following workflow: Instead of adding pool-healthmonitor association, use health monitor object as a template (probably renaming is needed) and add 'private' health monitor to the pool. So all further operations would result in changing health monitor on one device only. What do you think? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
