Re: [openstack-dev] Status of Neutron IPv6 dual stack
Harm, We were not able to enable dual stack with l3 routers in Juno release. You may need to wait for Kilo to see if that can be pushed in. Xu Han — Xu Han Peng (xuhanp) On Sat, Nov 22, 2014 at 3:03 AM, Harm Weites h...@weites.com wrote: Hi, We're running Juno since a few weeks now, is it now possible to go dual stack with l3-routers or are there some pieces missing and should I wait for Kilo? -Harm On 08/19/2014 07:08 PM, Dane Leblanc (leblancd) wrote: Hi Harm: Unfortunately I haven’t had time to complete the changes yet. Even if/when these changes are completed, it’s unlikely that this blueprint will get approved for Juno, but I’ll see what I can do. Thanks, Dane *From:*Harm Weites [mailto:h...@weites.com] *Sent:* Tuesday, August 19, 2014 12:53 PM *To:* openstack-dev@lists.openstack.org *Subject:* Re: [openstack-dev] Status of Neutron IPv6 dual stack Thiago, My old setup was dual-stacked, simply using a flat linuxbridge. It's just that I now realy would like to separate multiple tenants using L3 routers, which should be easy (dual stacked) to achieve once Dane's work is completed. Did you find the time to commit those required changes for that yet Dane? Regards, Harm op 16-08-14 23:33, Martinx - ジェームズ schreef: Guys, Just for the record, I'm using IceHouse in a Dual-Stacked environment (with security groups working) but, Instance's IPv6 address are static (no upstream SLAAC, arrived in Juno-2, I think) and the topology is `VLAN Provider Networks`, no Neutron L3 Router. Where each VLAN have v4/v6 addrs, same upstream router (also dual-stacked - still no radvd enabled). Looking forward to start testing L3 + IPv6 in K... Best, Thiago On 16 August 2014 16:21, Harm Weites h...@weites.com mailto:h...@weites.com wrote: Hi Dane, Thanks, that looks promising. Once support for multiple v6 addresses on gateway ports is added I'll be happy to give this a go. Should it work just fine with an otherwise Icehouse based deployment? Regards, Harm op 16-08-14 20:31, Dane Leblanc (leblancd) schreef: Hi Harm: Can you take a look at the following, which should address this: https://blueprints.launchpad.net/neutron/+spec/multiple-ipv6-prefixes There are some diffs out for review for this blueprint: https://review.openstack.org/#/c/113339/ but the change to support 1 V4 + multiple V6 addresses on a gateway port hasn't been added yet. I should be adding this soon. There was a request for a Juno feature freeze exception for this blueprint, but there's been no response, so this may not get approved until K release. -Dane -Original Message- From: Harm Weites [mailto:h...@weites.com mailto:h...@weites.com] Sent: Saturday, August 16, 2014 2:22 PM To: openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org Subject: [openstack-dev] Status of Neutron IPv6 dual stack Hi, Given the work on [1] has been abandoned, I'm wondering what the current status of going dual stack is. Of course, given Neutron got something like that on it's roadmap. The initial BP [2] aimed for Havana and Icehouse, and I'm unaware of something similar to achieve a dual stack network. What are the options, if any? To my knowledge it all comes down to supporting multiple exterior interfaces (networks) on a l3-agent, which is currently limited to just 1: either IP4 or IP6. [1] https://review.openstack.org/#/c/77471/ [2] https://blueprints.launchpad.net/neutron/+spec/allow-multiple-subnets-on-gateway-port Regards, Harm ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list
Re: [openstack-dev] [QA][Tempest] Proposing Ghanshyam Mann for Tempest Core
+1 On 21 Nov 2014 18:25, Ken1 Ohmichi ken1ohmi...@gmail.com wrote: +1 :-) Sent from my iPod On 2014/11/22, at 7:56, Christopher Yeoh cbky...@gmail.com wrote: +1 Sent from my iPad On 22 Nov 2014, at 4:56 am, Matthew Treinish mtrein...@kortar.org wrote: Hi Everyone, I'd like to propose we add Ghanshyam Mann (gmann) to the tempest core team. Over the past couple of cycles Ghanshyam has been actively engaged in the Tempest community. Ghanshyam has had one of the highest review counts on Tempest for the past cycle, and he has consistently been providing reviews that have been of consistently high quality that show insight into both the project internals and it's future direction. I feel that Ghanshyam will make an excellent addition to the core team. As per the usual, if the current Tempest core team members would please vote +1 or -1(veto) to the nomination when you get a chance. We'll keep the polls open for 5 days or until everyone has voted. Thanks, Matt Treinish References: https://review.openstack.org/#/q/reviewer:%22Ghanshyam+Mann+%253Cghanshyam.mann%2540nectechnologies.in%253E%22,n,z http://stackalytics.com/?user_id=ghanshyammannmetric=marks ___ 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][FWaaS]Firewall Web Services Research Thesis and OpenStack Applicability - UPDATED
Sumit, My thesis is now complete! The entire research, including source code and screen recordings, are included in my deliverable here: https://docs.google.com/uc?id=0B7WyzOL96X9QaF9QMHFBSFhpbFEe xport=download I am now in the process of drafting up a whitepaper based on my thesis research. Please let me know if there are additional resources I can provide. Thank you, -- Mike Grima, RHCE ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][FWaaS]Firewall Web Services Research Thesis and OpenStack Applicability - UPDATED
For whatever reason, this wasn’t linked appropriately to the older post in the list. That post is here: http://lists.openstack.org/pipermail/openstack-dev/2014-August/042981.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] No PROTOCOL_SSLv3 in Python 2.7 in Sid since 3 days
On Nov 22, 2014, at 1:45 AM, Robert Collins robe...@robertcollins.net wrote: On 22 November 2014 08:11, Jeremy Stanley fu...@yuggoth.org wrote: On 2014-11-21 12:31:08 -0500 (-0500), Donald Stufft wrote: Death to SSLv3 IMO. Sure, we should avoid releasing new versions of things which assume SSLv3 support is present in underlying libraries/platforms (it's unclear to me why anyone even thought it was good to make that configurable to this degree in openstack-common, but it probably dates back to before the nova common split). But what we're talking about here is fixing a deployability/usability bug where the software is assuming the presence of something removed from a dependency on some platform. I'd rather not conflate it with knee-jerk SSLv3 Bad rhetoric which risks giving casual readers the impression there's some vulnerability here. Ceasing to assume the presence of SSLv3 support is a safe choice for the software in question. Forcing changes to stable branches for this should be taken on its merits as a normal bug, and not prioritized because of any perceived security impact. Given the persistent risks of downgrade attacks, I think this does actually qualify as a security issue: not that its breaking,but that SSLv3 is advertised and accepted anywhere. The lines two lower: try: _SSL_PROTOCOLS[sslv2] = ssl.PROTOCOL_SSLv2 except AttributeError: pass Are even more concerning! That said, code like: https://github.com/mpaladin/python-amqpclt/blob/master/amqpclt/kombu.py#L101 is truely egregious! :) Yes this. SSLv3 isn’t a “Well as long as you have newer things enabled it’s fine” it’s a “If you have this enabled at all it’s a problem”. As far as I am aware without TLS_FALLBACK_SCSV a MITM who is willing to do active attacks can force the connection over to the lowest protocol that a client and server support. There is no way for the server to verify that the message sent from the client that indicates their highest was not modified in transit. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Alembic 0.7.0 - hitting Pypi potentially Sunday night
On Nov 21, 2014, at 8:07 PM, Mike Bayer mba...@redhat.com wrote: On Nov 21, 2014, at 7:35 PM, Kevin Benton blak...@gmail.com mailto:blak...@gmail.com wrote: This is great! I'm not sure if you have been following some of the discussion about the separation of vendor drivers in Neutron, but one of the things we decided was to leave the vendor data models in the main repo so we have a nice linear migration. It looks like branching support may solve our problem. However, looking through the docs I didn't notice anything about where the migration definitions need to live. Can migrations be sourced from multiple locations easily? that’s another TODO, which is https://bitbucket.org/zzzeek/alembic/issue/124/multiple-versions-directories https://bitbucket.org/zzzeek/alembic/issue/124/multiple-versions-directories. Skip down to the bottom comments as for the longest time I wasn’t really getting how this would work b.c. the multiple branch thing wasn’t in place. OK, sleeping on this I thought more deeply about the “multiple, semi-independent roots” case and thought of a few more glitches, so I got fixes in for those today and I implemented #124 as well. Another new concept, “depends_on”, is added to the system to accommodate the case where independent roots need to refer to each other as dependencies, but not as “merge points”. I think this might work really well, so far it seems that way. As the one-page docs have gotten super-long I’ve broken them out; a revised section that goes into how to use multiple roots and file directories now starts at http://alembic.readthedocs.org/en/latest/branches.html#working-with-multiple-bases http://alembic.readthedocs.org/en/latest/branches.html#working-with-multiple-bases. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] No PROTOCOL_SSLv3 in Python 2.7 in Sid since 3 days
On 2014-11-22 13:37:55 -0500 (-0500), Donald Stufft wrote: Yes this. SSLv3 isn’t a “Well as long as you have newer things enabled it’s fine” it’s a “If you have this enabled at all it’s a problem”. As far as I am aware without TLS_FALLBACK_SCSV a MITM who is willing to do active attacks can force the connection over to the lowest protocol that a client and server support. There is no way for the server to verify that the message sent from the client that indicates their highest was not modified in transit. IETF RFC 2246 disagrees with you on this. Please cite sources (besides interactions with Web browsers that sidestep TLS version negotiation a la POODLE). You're suggesting a vulnerability far worse than e.g. CVE-2014-3511 in OpenSSL, which would definitely be something I haven't seen disclosed to date. It's very easy to fall into the protocol shaming trap, and I don't think it's at all helpful. -- Jeremy Stanley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] No PROTOCOL_SSLv3 in Python 2.7 in Sid since 3 days
I'm in my phone but rfc 2246 says that there are many ways in which an attacker can attempt to make an attacker drop down to the least secure option they both support. It's like the second or third paragraph of that section. On Nov 22, 2014, at 4:00 PM, Jeremy Stanley fu...@yuggoth.org wrote: On 2014-11-22 13:37:55 -0500 (-0500), Donald Stufft wrote: Yes this. SSLv3 isn’t a “Well as long as you have newer things enabled it’s fine” it’s a “If you have this enabled at all it’s a problem”. As far as I am aware without TLS_FALLBACK_SCSV a MITM who is willing to do active attacks can force the connection over to the lowest protocol that a client and server support. There is no way for the server to verify that the message sent from the client that indicates their highest was not modified in transit. IETF RFC 2246 disagrees with you on this. Please cite sources (besides interactions with Web browsers that sidestep TLS version negotiation a la POODLE). You're suggesting a vulnerability far worse than e.g. CVE-2014-3511 in OpenSSL, which would definitely be something I haven't seen disclosed to date. It's very easy to fall into the protocol shaming trap, and I don't think it's at all helpful. -- Jeremy Stanley ___ 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] No PROTOCOL_SSLv3 in Python 2.7 in Sid since 3 days
I refreshed my memory and I was wrong about the specific attack. However the point still stands that both the rfc and respected folks such as Thomas porin state that you should look at the version negotiation as a way to selectively enable new features not as a way to ensure that a connection uses a secure option when both a secure and an insecure option exist. http://crypto.stackexchange.com/a/10496 On Nov 22, 2014, at 4:13 PM, Donald Stufft don...@stufft.io wrote: I'm in my phone but rfc 2246 says that there are many ways in which an attacker can attempt to make an attacker drop down to the least secure option they both support. It's like the second or third paragraph of that section. On Nov 22, 2014, at 4:00 PM, Jeremy Stanley fu...@yuggoth.org wrote: On 2014-11-22 13:37:55 -0500 (-0500), Donald Stufft wrote: Yes this. SSLv3 isn’t a “Well as long as you have newer things enabled it’s fine” it’s a “If you have this enabled at all it’s a problem”. As far as I am aware without TLS_FALLBACK_SCSV a MITM who is willing to do active attacks can force the connection over to the lowest protocol that a client and server support. There is no way for the server to verify that the message sent from the client that indicates their highest was not modified in transit. IETF RFC 2246 disagrees with you on this. Please cite sources (besides interactions with Web browsers that sidestep TLS version negotiation a la POODLE). You're suggesting a vulnerability far worse than e.g. CVE-2014-3511 in OpenSSL, which would definitely be something I haven't seen disclosed to date. It's very easy to fall into the protocol shaming trap, and I don't think it's at all helpful. -- Jeremy Stanley ___ 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] No PROTOCOL_SSLv3 in Python 2.7 in Sid since 3 days
On 2014-11-22 19:45:09 +1300 (+1300), Robert Collins wrote: Given the persistent risks of downgrade attacks, I think this does actually qualify as a security issue: not that its breaking, but that SSLv3 is advertised and accepted anywhere. Which downgrade attacks? Outside of Web browser authors deciding it was a good idea to bypass the normal TLS negotiation mechanism, as long as both ends _support_ TLS then causing a downgrade within TLS version negotiation to SSLv3 or earlier should not be possible. If you're suggesting we strengthen against unknown future attacks, that's a fine idea and is something we call security hardening (not a vulnerability fix). The lines two lower: try: _SSL_PROTOCOLS[sslv2] = ssl.PROTOCOL_SSLv2 except AttributeError: pass Are even more concerning! _SSL_PROTOCOLS is only used in sslutils.validate_ssl_version() which is in turn used by a method in rpc.impl_kombu. Checking *all* current branches of *all* official OpenStack projects in our Gerrit, the only way it's called is when the kombu RPC backend is in use and kombu_ssl_version is set in a configuration file. It will *allow* explicit selection of insecure SSL versions (SSLv3 and SSLv2) by the administrator--this isn't a magically uses insecure protocols without telling you situation--merely providing the option to configure use of a specific insecure protocol. (You can also configure it not to use any encryption at all for that matter.) I'm all for dropping this nonsense completely in master and also backporting a patch to make this not spontaneously vomit when run on platforms where SSLv3 is no longer available (perhaps something similar to the SSLv2 try/except example above), but we shouldn't backport a patch which suddenly breaks someone's cloud because they made a conscious decision to configure it to use SSLv3 for RPC communication. Visibly documenting (in the Security Guide or an OSSN) that you should configure your RPC communication to use TLS instead of SSLv2/3 is of course a great idea too. My point is that suggesting there's a vulnerability here without looking at how the code is used is sort of like shouting fire in a crowded theater. That said, code like: https://github.com/mpaladin/python-amqpclt/blob/master/amqpclt/kombu.py#L101 is truely egregious! Yikes... glad I'm not on _their_ VMT instead! -- Jeremy Stanley signature.asc Description: Digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] L3 agent restructuring notes
Paul, I worked much of this in to my blueprint [1]. Carl [1] https://review.openstack.org/#/c/131535/4/specs/kilo/restructure-l3-agent.rst On Fri, Nov 21, 2014 at 11:48 AM, Paul Michali (pcm) p...@cisco.com wrote: Hi, I talked to Carl today to discuss the L3 agent restructuring and the change set I had published (https://review.openstack.org/#/c/135392/), which was trying to identify/exposing what is needed for the loading of device drivers and the variation therein. I wasn’t sure how we’d do the separation of the agents and wanted to discuss the options and brainstorm on some ideas on how to do this. We had a very good talk and here are some notes of what we were thinking (Carl, chime in, if I missed anything or I’m interpreting them differently): First step could be to create a service abstract class, and then child classes for the various services to use these as “observers/subscribers” to the L3 agent. The base class would have no-operation methods for each action that the L3 agent could notify about, and the child classes could (later) hold service specific logic. The base class would include a “register” method, so that a service can register for notification from the L3 agent (mapping to these methods created). The child classes would do service specific loading of device drivers. Currently, the L3 agent (and VPN agent) load the device drivers for services. What can be done in this first step, is, instead of doing the load, a service object can be created. This object would do the loading and register with the L3 agent for notifications. Second step could be to populate the child services’ notification handlers, for any methods of interest to those services. Involves taking methods that are in the various agent classes and move them into the new service child classes, and adapt as needed. Third step could be to create a abstract factory (or factory method), which the L3 agent would call at startup, instead of it creating the service instances. This factory would determine what services are enabled (one way is to see if service_provider config entry for the service type), and then create the service instance, which in turn would load the device driver and register with the L3 agent. This way, the L3 agent no longer knows about the services. This would imply no longer having separate VPN agent process, and instead, all the service instances would be created by the factory. It would change the way DevStack would start up things (e.g. only starting up the L3 agent process). Fourth step (optional) could be to create new config file entries so that a common device driver loader could be created, instead of service specific loaders. This is more of a post refactor cleanup activity. Some other thoughts: Should strive to keep the config and start-up the same initially (and as much as possible). Initially, the services will get an L3 agent passed in on create, but in the future, a router instance can be provided to the service. Using ABC for observer, so that services only have to implement the desired methods of interest. Thoughts were to do notification handlers (step 2) before factory (step 3), so that service is extracted, before changing startup. Hope that gives an idea of what we were thinking about for this chinese finger puzzle (https://www.youtube.com/watch?v=k8BSiyDs0nw) Regards, PCM (Paul Michali) MAIL …..…. p...@cisco.com IRC ……..… pc_m (irc.freenode.com) TW ………... @pmichali GPG Key … 4525ECC253E31A83 Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83 ___ 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] No PROTOCOL_SSLv3 in Python 2.7 in Sid since 3 days
On 2014-11-22 16:33:52 -0500 (-0500), Donald Stufft wrote: I refreshed my memory and I was wrong about the specific attack. However the point still stands that both the rfc and respected folks such as Thomas porin state that you should look at the version negotiation as a way to selectively enable new features not as a way to ensure that a connection uses a secure option when both a secure and an insecure option exist. [...] I don't disagree with those points, but if you read the source code in question that's not what it's doing anyway. The problem at hand is that we allow you to configure RPC over SSLv3 (that's an attractive nuisance sure), but the way the config validation is written it explodes violently on platforms which have stripped out support for SSLv3 even if you didn't configure your system to use SSLv3 (not a security bug, just a bug bug). TLS negotiation on the other hand is being left entirely up to the system, so its behaviors are determined and managed outside of OpenStack anyway. Unfortunately now too many people are conditioned to fire off panic replies when they see terms like SSLv3 or MD5 or DES or whatever without evaluating the specifics of the situation. That makes it very hard to talk about normal bugs, and causes vulnerability managers to have to spend hours on PR damage control instead. -- Jeremy Stanley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][lbaas] Shared Objects in LBaaS - Use Cases that led us to adopt this.
Hi Stephen, 1. The issue is that if we do 1:1 and allow status/state to proliferate throughout all objects we will then get an issue to fix it later, hence even if we do not do sharing, I would still like to have all objects besides LB be treated as logical. 2. The 3rd use case bellow will not be reasonable without pool sharing between different policies. Specifying different pools which are the same for each policy make it non-started to me. -Sam. From: Stephen Balukoff [mailto:sbaluk...@bluebox.net] Sent: Friday, November 21, 2014 10:26 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron][lbaas] Shared Objects in LBaaS - Use Cases that led us to adopt this. I think the idea was to implement 1:1 initially to reduce the amount of code and operational complexity we'd have to deal with in initial revisions of LBaaS v2. Many to many can be simulated in this scenario, though it does shift the burden of maintenance to the end user. It does greatly simplify the initial code for v2, in any case, though. Did we ever agree to allowing listeners to be shared among load balancers? I think that still might be a N:1 relationship even in our latest models. There's also the difficulty introduced by supporting different flavors: Since flavors are essentially an association between a load balancer object and a driver (with parameters), once flavors are introduced, any sub-objects of a given load balancer objects must necessarily be purely logical until they are associated with a load balancer. I know there was talk of forcing these objects to be sub-objects of a load balancer which can't be accessed independently of the load balancer (which would have much the same effect as what you discuss: State / status only make sense once logical objects have an instantiation somewhere.) However, the currently proposed API treats most objects as root objects, which breaks this paradigm. How we handle status and updates once there's an instantiation of these logical objects is where we start getting into real complexity. It seems to me there's a lot of complexity introduced when we allow a lot of many to many relationships without a whole lot of benefit in real-world deployment scenarios. In most cases, objects are not going to be shared, and in those cases with sufficiently complicated deployments in which shared objects could be used, the user is likely to be sophisticated enough and skilled enough to manage updating what are essentially copies of objects, and would likely have an opinion about how individual failures should be handled which wouldn't necessarily coincide with what we developers of the system would assume. That is to say, allowing too many many to many relationships feels like a solution to a problem that doesn't really exist, and introduces a lot of unnecessary complexity. In any case, though, I feel like we should walk before we run: Implementing 1:1 initially is a good idea to get us rolling. Whether we then implement 1:N or M:N after that is another question entirely. But in any case, it seems like a bad idea to try to start with M:N. Stephen On Thu, Nov 20, 2014 at 4:52 AM, Samuel Bercovici samu...@radware.commailto:samu...@radware.com wrote: Hi, Per discussion I had at OpenStack Summit/Paris with Brandon and Doug, I would like to remind everyone why we choose to follow a model where pools and listeners are shared (many to many relationships). Use Cases: 1. The same application is being exposed via different LB objects. For example: users coming from the internal private organization network, have an LB1(private_VIP) -- Listener1(TLS) --Pool1 and user coming from the internet, have LB2(public_vip)--Listener1(TLS)--Pool1. This may also happen to support ipv4 and ipv6: LB_v4(ipv4_VIP) -- Listener1(TLS) --Pool1 and LB_v6(ipv6_VIP) -- Listener1(TLS) --Pool1 The operator would like to be able to manage the pool membership in cases of updates and error in a single place. 2. The same group of servers is being used via different listeners optionally also connected to different LB objects. For example: users coming from the internal private organization network, have an LB1(private_VIP) -- Listener1(HTTP) --Pool1 and user coming from the internet, have LB2(public_vip)--Listener2(TLS)--Pool1. The LBs may use different flavors as LB2 needs TLS termination and may prefer a different stronger flavor. The operator would like to be able to manage the pool membership in cases of updates and error in a single place. 3. The same group of servers is being used in several different L7_Policies connected to a listener. Such listener may be reused as in use case 1. For example: LB1(VIP1)--Listener_L7(TLS) | +--L7_Policy1(rules..)--Pool1 |
