| *** yamamoto has quit IRC | 00:34 | |
| *** ramishra has quit IRC | 02:41 | |
| openstackgerrit | zhufl proposed openstack/octavia master: Add missing ws separator between words https://review.openstack.org/619137 | 02:55 |
|---|---|---|
| openstackgerrit | wangxiyuan proposed openstack/octavia master: [WIP] Tags support for lb resources https://review.openstack.org/606006 | 03:35 |
| *** yamamoto has joined #openstack-lbaas | 04:05 | |
| *** numans has quit IRC | 04:18 | |
| *** yamamoto has quit IRC | 05:20 | |
| *** yamamoto has joined #openstack-lbaas | 05:24 | |
| openstackgerrit | Merged openstack/octavia master: Treat null admin_state_up as False https://review.openstack.org/582929 | 05:27 |
| *** yamamoto has quit IRC | 05:47 | |
| *** yamamoto has joined #openstack-lbaas | 05:51 | |
| *** yamamoto has quit IRC | 06:07 | |
| *** annp has joined #openstack-lbaas | 06:17 | |
| *** yamamoto has joined #openstack-lbaas | 06:41 | |
| *** yboaron_ has joined #openstack-lbaas | 06:49 | |
| *** ccamposr has joined #openstack-lbaas | 06:49 | |
| *** rcernin has quit IRC | 07:26 | |
| *** velizarx has joined #openstack-lbaas | 07:51 | |
| *** yboaron_ has quit IRC | 08:10 | |
| *** yamamoto has quit IRC | 08:24 | |
| *** yamamoto has joined #openstack-lbaas | 08:47 | |
| *** sapd1__ has quit IRC | 08:54 | |
| *** sapd1 has joined #openstack-lbaas | 08:55 | |
| *** velizarx has quit IRC | 08:59 | |
| *** yboaron_ has joined #openstack-lbaas | 09:05 | |
| *** velizarx has joined #openstack-lbaas | 09:06 | |
| openstackgerrit | wangxiyuan proposed openstack/octavia master: [WIP] Tags support for lb resources https://review.openstack.org/606006 | 09:14 |
| *** yboaron_ has quit IRC | 09:35 | |
| *** yboaron_ has joined #openstack-lbaas | 09:36 | |
| *** pcaruana has joined #openstack-lbaas | 09:48 | |
| *** yamamoto has quit IRC | 09:55 | |
| *** Emine has joined #openstack-lbaas | 10:10 | |
| openstackgerrit | Antoni Segura Puimedon proposed openstack/octavia master: [WIP] Allow LB creation to specify Access SGs https://review.openstack.org/619193 | 10:11 |
| *** salmankhan has joined #openstack-lbaas | 10:14 | |
| *** yboaron_ has quit IRC | 10:15 | |
| *** yboaron_ has joined #openstack-lbaas | 10:16 | |
| *** salmankhan1 has joined #openstack-lbaas | 10:16 | |
| *** salmankhan has quit IRC | 10:18 | |
| *** salmankhan1 is now known as salmankhan | 10:18 | |
| *** yamamoto has joined #openstack-lbaas | 10:22 | |
| *** yamamoto has quit IRC | 10:28 | |
| *** yamamoto has joined #openstack-lbaas | 10:30 | |
| *** Emine has quit IRC | 10:31 | |
| *** Emine has joined #openstack-lbaas | 10:54 | |
| *** yamamoto has quit IRC | 11:45 | |
| *** mugsie has joined #openstack-lbaas | 11:49 | |
| *** yamamoto has joined #openstack-lbaas | 12:07 | |
| *** yamamoto has quit IRC | 12:36 | |
| *** ramishra has joined #openstack-lbaas | 12:51 | |
| *** yamamoto has joined #openstack-lbaas | 13:06 | |
| *** yamamoto has quit IRC | 13:18 | |
| *** hvhaugwitz has quit IRC | 13:22 | |
| *** hvhaugwitz has joined #openstack-lbaas | 13:29 | |
| *** velizarx has quit IRC | 14:02 | |
| *** velizarx has joined #openstack-lbaas | 14:07 | |
| *** Emine has quit IRC | 15:17 | |
| *** Emine has joined #openstack-lbaas | 15:18 | |
| *** velizarx has quit IRC | 15:21 | |
| *** ramishra has quit IRC | 15:45 | |
| *** ccamposr has quit IRC | 15:58 | |
| *** velizarx has joined #openstack-lbaas | 16:42 | |
| *** yboaron_ has quit IRC | 16:43 | |
| *** ccamposr has joined #openstack-lbaas | 16:50 | |
| *** pcaruana has quit IRC | 16:50 | |
| *** fnaval has joined #openstack-lbaas | 17:03 | |
| *** Emine has quit IRC | 17:05 | |
| *** cgoncalves has quit IRC | 17:12 | |
| *** velizarx has quit IRC | 17:12 | |
| *** cgoncalves has joined #openstack-lbaas | 17:14 | |
| *** yamamoto has joined #openstack-lbaas | 17:16 | |
| *** yamamoto has quit IRC | 17:20 | |
| openstackgerrit | Antoni Segura Puimedon proposed openstack/octavia master: [WIP] Allow LB creation to specify Access SGs https://review.openstack.org/619193 | 17:31 |
| *** cgoncalves has quit IRC | 17:42 | |
| *** cgoncalves has joined #openstack-lbaas | 17:42 | |
| *** salmankhan has quit IRC | 18:11 | |
| rm_work | meeting today? or none due to US holiday week? | 20:00 |
| johnsom | #startmeeting Octavia | 20:00 |
| openstack | Meeting started Wed Nov 21 20:00:52 2018 UTC and is due to finish in 60 minutes. The chair is johnsom. Information about MeetBot at http://wiki.debian.org/MeetBot. | 20:00 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 20:00 |
| rm_work | :P | 20:00 |
| *** openstack changes topic to " (Meeting topic: Octavia)" | 20:00 | |
| rm_work | o/ | 20:00 |
| openstack | The meeting name has been set to 'octavia' | 20:00 |
| cgoncalves | rm_work, only because you asked | 20:01 |
| johnsom | Sorry, was slow on the draw there. | 20:01 |
| nmagnezi | o/ | 20:01 |
| rm_work | lol | 20:01 |
| ltomasbo | o/ | 20:01 |
| johnsom | Trying to research what I know the hot topic is today... | 20:01 |
| johnsom | As we have a LONG history of discussing the solution | 20:01 |
| johnsom | #topic Announcements | 20:01 |
| *** openstack changes topic to "Announcements (Meeting topic: Octavia)" | 20:01 | |
| rm_work | Today is my last working day at GD, will start at Oath on Dec 3 :) | 20:02 |
| johnsom | The summit was last week. It sounds like it went well for us. We had two keynotes mentioning Octavia, so that is great! | 20:02 |
| cgoncalves | rm_work, congratulations!! | 20:02 |
| johnsom | rm_work Congrats! | 20:02 |
| cgoncalves | https://j.apps.cgoncalves.pt/UI/Dashboard | 20:02 |
| cgoncalves | oosp | 20:03 |
| nmagnezi | rm_work, Congrats and good luck! :) | 20:03 |
| rm_work | thanks :) | 20:03 |
| rm_work | I know they are using Octavia there so maybe I will have more time? | 20:03 |
| nmagnezi | cgoncalves, Bad Gateway, Bad! | 20:03 |
| johnsom | Sadly, I guess the conference venue in Berlin didn't have the bandwidth for the videos, so they had to ship hard drives back to the states. They are estimating mid-December for the non-keynote sessions to be posted. | 20:03 |
| rm_work | lol wat | 20:03 |
| nmagnezi | johnsom, that's actually a first. wow. | 20:04 |
| johnsom | cgoncalves nginx/1.14.1 ??? Really..... sigh | 20:04 |
| rm_work | such sneakernet | 20:04 |
| rm_work | aww, cert not trusted? wheres your letsencrypt? | 20:04 |
| cgoncalves | johnsom, wasn't pwd protected yet, so I shut it off immediately | 20:04 |
| johnsom | lol | 20:04 |
| johnsom | Don't want to share your cat videos? | 20:05 |
| cgoncalves | it's letsencrypt'ed | 20:05 |
| cgoncalves | I'm a dog person, sorry | 20:05 |
| johnsom | Still, nginx? | 20:05 |
| rm_work | hmm, wonder if my root certs are crazy old on this machine | 20:05 |
| rm_work | what's wrong with nginx? :P | 20:05 |
| nmagnezi | johnsom, he's secretly coding an Octavia driver for it | 20:06 |
| johnsom | Also, if you weren't aware, the openstack-dev and ops mailing lists are merging and going away. | 20:06 |
| johnsom | Please make sure you are subscribed to the new mailing list (if you are interested). | 20:06 |
| johnsom | #link http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html | 20:06 |
| johnsom | All of the details are at that link | 20:06 |
| rm_work | i wish they had one for nginx... would be nice to really proof out our interface for the amp driver | 20:06 |
| cgoncalves | w00t, I was not aware of this. thank you | 20:07 |
| johnsom | Yeah, but I'm not approving an API so you can load you license key.... | 20:07 |
| johnsom | There is some talk of new [dev] tags, but I didn't get a chance to read up on that. | 20:08 |
| rm_work | the link in that mail seems to go to the wrong place | 20:08 |
| rm_work | it's this one I think? http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss | 20:08 |
| johnsom | Yeah, it's now "discuss" | 20:08 |
| cgoncalves | yeah, subscribed now | 20:08 |
| rm_work | johnsom: i assume that'd be a config variable specific to nginx? :P | 20:08 |
| johnsom | I guess you could add a flavor for it... sigh | 20:09 |
| rm_work | and we'd need to split out config stuff specific to backends into their own sections (ie, haproxy stuff would need to be in [haproxy]) | 20:09 |
| johnsom | Ok, last thing I have: | 20:10 |
| johnsom | Octavia priority review list.... | 20:10 |
| johnsom | #link https://etherpad.openstack.org/p/octavia-priority-reviews | 20:10 |
| johnsom | I have updated the list for Stein | 20:10 |
| johnsom | We are way behind on reviews | 20:11 |
| johnsom | ~56 reviews or so | 20:11 |
| johnsom | Just a reminder. This is a list of patches that *appear* ready for reviews. It is not a list of patches I think should merge. It is roughly ordered in a priority I think makes sense (patches that have children first, impact on the project, etc.) | 20:12 |
| johnsom | If it has a -1 or WIP it is not on this list | 20:12 |
| johnsom | That is by design | 20:12 |
| johnsom | If there are things you think should be on the list, add them to "Awaiting prioritization" so I can order it and be aware of it. | 20:13 |
| johnsom | Hopefully this is useful. At least it highlights the need for reviews on patches and our backlog. | 20:13 |
| johnsom | Feel free to poke me if you think we should re-order, etc. | 20:14 |
| johnsom | Any questions/comments on the review list? | 20:14 |
| johnsom | Any other announcements today? | 20:15 |
| johnsom | #topic Brief progress reports / bugs needing review | 20:15 |
| *** openstack changes topic to "Brief progress reports / bugs needing review (Meeting topic: Octavia)" | 20:15 | |
| cgoncalves | I proposed tagging octavia-tempest-plugin 0.2.0: https://review.openstack.org/#/c/619314/ | 20:15 |
| johnsom | I am on vacation this week, so not a ton of things going on. | 20:15 |
| johnsom | I finished the work for creating octavia-lib and moving the code out to it. | 20:16 |
| johnsom | I also finished the first patch in the flavors work, which adds APIs for managing flavors. Still a lot of work to do there, but a start. | 20:16 |
| nmagnezi | as a followup to what cgoncalves just wrote, we work to promote the RPM for octavia-tempest-plugin for both OSP13 and OSP14 (which is in the works). | 20:16 |
| openstackgerrit | Carlos Goncalves proposed openstack/octavia master: Fix devstack plugin for /var/log/dib-build exists https://review.openstack.org/617838 | 20:17 |
| rm_work | Oh i think this one should be easy (speaking of tempest) https://review.openstack.org/#/c/607382/ | 20:17 |
| johnsom | Cool. | 20:17 |
| nmagnezi | For whomever is interested, that is also going to be the case in RDO | 20:18 |
| johnsom | rm_work FYI, I did include that in the review list | 20:18 |
| rm_work | ah k | 20:18 |
| johnsom | I also spent time creating the list and doing some reviews last week. | 20:19 |
| rm_work | I'm gonna be out until like mid-december prolly for most stuff still, but I REALLY hope I can get back to reviewing at that point | 20:19 |
| johnsom | We hope too! | 20:19 |
| rm_work | one of the first things i'll ask my new team is "so, do you guys want me to run for PTL of this project?" :P | 20:20 |
| johnsom | Any other updates of note? | 20:20 |
| johnsom | Sweet! | 20:20 |
| johnsom | It's time for some new leadership around here... lol | 20:20 |
| rm_work | though I'm secretly hoping cgoncalves wants to do it :P | 20:20 |
| rm_work | I still *hate* paperwork | 20:20 |
| rm_work | with a fiery passion | 20:21 |
| cgoncalves | rm_work, there's no paperwork. we are 100% digital | 20:21 |
| rm_work | (enough that it tends to incinerate any paperwork i come in contact with) | 20:21 |
| rm_work | lol well that's good then | 20:21 |
| nmagnezi | Ok so we're going to vote now? :) | 20:21 |
| johnsom | There is *plenty* of bit-work to do however | 20:21 |
| johnsom | Ok, moving on to the hot topic today...... | 20:22 |
| johnsom | #topic VIP ACLs/SGs | 20:22 |
| *** openstack changes topic to "VIP ACLs/SGs (Meeting topic: Octavia)" | 20:22 | |
| johnsom | So there is a patch posted: | 20:22 |
| rm_work | didn't we discuss this at length at the last PTG? | 20:22 |
| johnsom | #link https://review.openstack.org/#/c/602564/ | 20:22 |
| johnsom | And a patch to immediately deprecate it | 20:23 |
| johnsom | rm_work Yes, we have had lengthy conversations about this at multiple PTGs and IRC meetings. | 20:23 |
| johnsom | However, this patch is not the approach we decided on at those previous meetings. | 20:23 |
| johnsom | #link https://review.openstack.org/#/c/612631/2 | 20:24 |
| johnsom | deprecation patch | 20:24 |
| rm_work | lol k | 20:24 |
| johnsom | I had hoped to pull up the meeting logs and have a list of links for the history, but with vacation I didn't get time. | 20:24 |
| johnsom | Here is my summary of the issue: | 20:24 |
| johnsom | Users want to be able to restrict the source addresses allowed to access the VIP of their load balancers. | 20:25 |
| johnsom | Do we agree on the problem statement? | 20:25 |
| nmagnezi | Yup | 20:25 |
| ltomasbo | johnsom, yep | 20:25 |
| cgoncalves | yes | 20:25 |
| johnsom | Cool! Just want to set a common ground work | 20:25 |
| johnsom | The challenge comes in that Octavia "owns" the VIP and security group today. It will update it as ports are added for listeners, etc. It will also rebuild it should a failover occur and the SG needs to be rebuilt. | 20:27 |
| cgoncalves | also FYI, we have customers requesting this feature in our queens-based product | 20:27 |
| johnsom | Neutron only supports an "OR" operation with SGs on ports. | 20:27 |
| johnsom | This means if we stacked a user SG and the octavia SG on a port, it's which ever is more open wins. | 20:28 |
| johnsom | We did move the VIP port itself into the tenant project to allow floating IP assignment. However this has been proven to be a horrible idea as people are using automation tools to manage their projects which have "delete all" logic, and we (at least us) are seeing a large number of support calls where they have shot themselves in the foot. | 20:29 |
| ltomasbo | johnsom, but in this case the user will not be able to delete the SG if the amphora VM is using it | 20:30 |
| johnsom | So, due to this, and the fact that moving the SG into the tenant means they can open ports/protocols against our managed amphora is not a popular idea for some. | 20:31 |
| ltomasbo | johnsom, which is different to the VIP, as the VIP is not 'attached' to any VM in the amphora driver (just used through allowed address pair) | 20:31 |
| johnsom | ltomasbo Yes you can | 20:31 |
| ltomasbo | johnsom, if the SG is in used by another port (as is the case) you cannot remove it, neutron will reject it | 20:32 |
| johnsom | If the SG is owned by the tenant they can do anything to it. Common is open it wide up, no rules | 20:32 |
| johnsom | ltomasbo They already own the ports | 20:32 |
| ltomasbo | johnsom, how? the SG is attached to the vrrp port | 20:32 |
| ltomasbo | and that is owned by the octavia tennant | 20:33 |
| ltomasbo | so, the SG cannot be removed | 20:33 |
| ltomasbo | plus, the user is able to define listeners opening any port he wants on the octavia created SG, therefore the security concern is not a real one, as the user could to just the same without owning the SG | 20:34 |
| rm_work | what about the thing i was pushing last time -- having a user port and an internal port? It's been so long i actually forgot the details of my own proposal though, unfortunately | 20:34 |
| johnsom | Ah, but they cannot open protocols and any port they open as a listener is configured and has the appropriate haproxy listening on the port. | 20:34 |
| johnsom | openstack security group rule create ec2b4ea4-fe88-41ed-904c-5be2b88d188c | 20:35 |
| johnsom | That is really the worst issue | 20:35 |
| johnsom | That opens everything basically | 20:35 |
| ltomasbo | johnsom, I don't know enogh about octavia, but I though you can specify tcp/udp on the listeners, and create as much as you want | 20:36 |
| ltomasbo | thought | 20:37 |
| johnsom | The approach we eventually agreed upon was adding an ACL API to the listener that allowed users to add the source ACLs they want applied. We can then manage those, and restore those on failover. It is also a very explicit "here are the rules" interface. | 20:37 |
| johnsom | It would be setup similar to adding the ACLs via neutron, but with a limited set of features down to source IP, etc. | 20:37 |
| johnsom | ltomasbo You can, but you can't open protocol 50 for example. | 20:38 |
| johnsom | Or the VRRP protocols | 20:38 |
| ltomasbo | johnsom, that is true | 20:39 |
| johnsom | We looked at accepting a user SG and cloning it, but then the user experience gets horrible as if they change the SG rules, the LB would not get updated. That is unless we added a dependency that we are tied into the neutron event stream and watch for those update events, which gets super ugly quickly. | 20:40 |
| cgoncalves | johnsom, is there a draft somewhere of how that ACL API extension would look like? | 20:40 |
| ltomasbo | but if you allow the user to pass the SG you are in the same situation, and reimplementing the SG API (restricted) on octavia... | 20:40 |
| johnsom | I think there is in a story. | 20:40 |
| johnsom | But adding an ACL API is super simple | 20:41 |
| ltomasbo | johnsom, celebdor1 started a PoC to handle that: https://review.openstack.org/#/c/619193/ | 20:42 |
| cgoncalves | the downside of ACL API is reinventing the wheel, sort of | 20:42 |
| nmagnezi | Also not backportable | 20:42 |
| johnsom | Yeah, we went down that path and decided it was a bad idea. (allowing the passing of an SG in) | 20:42 |
| ltomasbo | cgoncalves, I agree | 20:42 |
| nmagnezi | But I guess most suggestions won't be anyways | 20:43 |
| johnsom | nmagnezi None of these options are backportable | 20:43 |
| cgoncalves | nmagnezi, let's forget about that for a moment. let's focus on the right fix to the problem | 20:43 |
| nmagnezi | Agreed. | 20:43 |
| ltomasbo | johnsom, reimplementing SG API is a bad idea too, it already exists... | 20:43 |
| cgoncalves | johnsom, I cannot find the story for the ACL API, sorry. could you please share? | 20:44 |
| celebdor1 | ltomasbo: and took a long time and man hours to get right and sort out the bugs | 20:44 |
| johnsom | The ACL option has an advantage as well, that the F5 guys liked. It allows us to implement it in different ways. For example, the amphora driver *may* use neutron SGs, or may use the haproxy ACLs. The F5 could opt to use the hardware ACLs. | 20:44 |
| cgoncalves | storyboard is not easy to navigate/search | 20:44 |
| rm_work | it'd be a simplified version of the existing ACL type apis tho right? | 20:44 |
| johnsom | cgoncalves, yeah I would have to dig. The title is not ACL, the comment is.... So their search is useless | 20:45 |
| rm_work | or do we just THINK it'd start that way, but it'd eventually grow to be the same huge mess? | 20:45 |
| celebdor1 | rm_work: I bet for the latter | 20:45 |
| johnsom | I think it would be very simple. We already handle all of the port stuff | 20:45 |
| celebdor1 | unless you really restrict it to just CIDRs | 20:46 |
| johnsom | So there is no real need for anything more complex that the source ACLs | 20:46 |
| celebdor1 | which is not too powerful | 20:46 |
| cgoncalves | on the pro side of ACL API is that we wouldn't be tightly coupled to neutron, which is good for e.g. octavia standalone | 20:46 |
| johnsom | The only downside we came up with is you can't use the transitive trust neutron SGs provide. I.e. if ports on members of the same SG they have full access. However, we felt that was better as this way the access is explicit and not implied. | 20:47 |
| celebdor1 | johnsom: it is not implied in Neutron IIRC | 20:48 |
| johnsom | Right. I think the hadware ACLs is a good case too. Why use slow iptables when you have an ASIC that can do the work | 20:48 |
| celebdor1 | you have a rule allowing from same SG, right ltomasbo? | 20:48 |
| celebdor1 | just that it is always put in the 'default' SG | 20:48 |
| ltomasbo | yep, you can simply allow from other ports having a specific SG, not an specific CIRD | 20:49 |
| ltomasbo | CIDR | 20:49 |
| johnsom | In neutron, two ports can be part of the same SG. That SG may exclude the IP of one port. However, the traffic will pass | 20:49 |
| ltomasbo | johnsom, in neutron everything is block by default, unless you open it | 20:50 |
| ltomasbo | (ingress) | 20:50 |
| johnsom | If you don't share the SG, yes | 20:50 |
| ltomasbo | of course, as everything is deny by default, the policy is that is denied unless you specifically allow it | 20:51 |
| ltomasbo | so, if you add a rule allowing it... it will pass | 20:51 |
| celebdor1 | johnsom: even if you share the SG | 20:51 |
| johnsom | If the ports share an SG, it always passes | 20:52 |
| ltomasbo | johnsom, that is not true, depend on the rule | 20:52 |
| celebdor1 | http://paste.openstack.org/show/735917/ | 20:52 |
| celebdor1 | those two rules that allow all ingress and egress from the same group | 20:52 |
| ltomasbo | johnsom, if they don't have the allow from remote_group_id SG_ID, then it will be blocked | 20:52 |
| celebdor1 | are not special | 20:52 |
| celebdor1 | they can be there | 20:52 |
| johnsom | They would have had to change that recently if that is the case. Plus a bunch of k8s people will get really grumply quickly if that stops working | 20:52 |
| celebdor1 | (and they are for the 'default' group) | 20:53 |
| celebdor1 | but they don't need to be there | 20:53 |
| celebdor1 | this has been the case for as long as I can remember | 20:53 |
| ltomasbo | yep, same here | 20:53 |
| johnsom | Anyhow, I think that is a bit of a side issue, and not that important for this conversation. | 20:53 |
| ltomasbo | that is there since newton at least | 20:53 |
| celebdor1 | johnsom: it was important to point out so if that would affect its usage we'd not be left with the wrong impression of how it works | 20:55 |
| celebdor1 | but it's not the main part of the topic | 20:56 |
| celebdor1 | of course | 20:56 |
| johnsom | What I am talking about is not remote SGs. | 20:56 |
| johnsom | Yeah, the ACL list approach would not be affected by neutron's behavior as the tenant would have access to the SG for other ports. | 20:57 |
| ltomasbo | johnsom, I don't get that | 20:57 |
| johnsom | By adding the ACL API, Octavia would retain ownership of the SG applied to the amphora. A tenant would not be able to add the SG to their other ports. | 20:58 |
| ltomasbo | ahh, by contrast you will be redoing the SG API (and that was not a simple task) | 21:00 |
| johnsom | A very small part of the SG API. Probably could be done in a week or so | 21:00 |
| celebdor1 | johnsom: ltomasbo: I probably missed it before (I was putting the toddler to bed). Why does it matter if they put the SG to other ports if it is one SG that they precreated like in the patch I sent | 21:01 |
| johnsom | If the VIP and other ports share an SG, their are not rules applied. But again, this isn't really the bigger issues. | 21:02 |
| celebdor1 | johnsom: is that small part of the API just a single CIDR for all the listeners in an LB? Or a list of CIDRs? or different CIDRs per listener? | 21:02 |
| celebdor1 | johnsom: I already showed that even if they share the SG unless the SG has explicit rules to allow same SG traffic, the rules apply | 21:03 |
| ltomasbo | celebdor1, and the remote_group_id... | 21:03 |
| johnsom | It would have to be a list. I would assume per listener for flexibility. CIDRs only. | 21:03 |
| celebdor1 | ltomasbo: no, I don't think the ACL proposal Octavia pushes for has remote group | 21:03 |
| celebdor1 | since it can't refer to Neutron stuff if it is a reimplementation | 21:04 |
| johnsom | Dang we are out of time. | 21:04 |
| johnsom | #endmeeting | 21:04 |
| *** openstack changes topic to "Discussions for Octavia | Stein priority review list: https://etherpad.openstack.org/p/octavia-priority-reviews" | 21:04 | |
| openstack | Meeting ended Wed Nov 21 21:04:10 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 21:04 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/octavia/2018/octavia.2018-11-21-20.00.html | 21:04 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/octavia/2018/octavia.2018-11-21-20.00.txt | 21:04 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/octavia/2018/octavia.2018-11-21-20.00.log.html | 21:04 |
| ltomasbo | and what about other octavia drivers... | 21:04 |
| johnsom | Sorry I wasn't watching that | 21:04 |
| johnsom | We can of course keep discussing, we just have a fixed hour for the meeting. | 21:04 |
| celebdor1 | johnsom: I think ltomasbo went for a late dinner | 21:06 |
| johnsom | celebdor1 If you missed the discussion, passing in SGs has a few issues: 1, neutron ORs them; 2. Octavia won't know when they change if we just "clone" the SG and users get confused; 3. it doesn't allow offloading the ACL to the drivers. and probably a few others I am forgetting here. | 21:07 |
| celebdor1 | that's why my patch doesn't clone them | 21:07 |
| celebdor1 | just makes the user take ownership if they pass the SG | 21:08 |
| celebdor1 | they are on their own | 21:08 |
| johnsom | Yeah, but those protect *our* managed resource. I have not looked at your patch yet, but is it just stacking the tenant SG on the port? | 21:09 |
| celebdor1 | johnsom: no, no. It's a very basic patch just proposing adding a param to the lb creation called access_group | 21:10 |
| celebdor1 | that takes an SG uuid | 21:10 |
| celebdor1 | if you pass that, the vrrp ports get this SG | 21:10 |
| celebdor1 | and that's where Octavia work ends | 21:10 |
| johnsom | Oh, so total replacement | 21:10 |
| cgoncalves | yes | 21:10 |
| celebdor1 | the user is on the hook for opening the ports to their listeners and so on | 21:10 |
| johnsom | So not protecting our amps at all | 21:11 |
| celebdor1 | (I prefer that than adding Octavia code that tries to do what the user wants) | 21:11 |
| celebdor1 | johnsom: right, it only protect the amp haproxy namespace as much as the user deems necessary | 21:11 |
| cgoncalves | johnsom, +1. in the likelyhood of penetrating into an amp, an attacker would have access to the whole lb-mgmt-network | 21:12 |
| celebdor1 | cgoncalves: how do you propose it escapes the network namespace? | 21:12 |
| celebdor1 | s/network/haproxy/ | 21:12 |
| johnsom | Well, not the lb-mgmt-net. | 21:12 |
| johnsom | That SG would remain in affect | 21:12 |
| celebdor1 | I thought they are isolated and the communication is with a unix domain socket | 21:13 |
| celebdor1 | so if they want to open whatever on the haproxy namespace | 21:13 |
| celebdor1 | what do we care? | 21:13 |
| johnsom | It removes our control and opens the attack surface greatly against a resource Octavia is supposed to be managing. | 21:14 |
| celebdor1 | how? what network resource is running there? | 21:15 |
| celebdor1 | I thought that it only runs haproxy | 21:15 |
| celebdor1 | which only listens to what you tell it to | 21:15 |
| johnsom | And keepalived. | 21:15 |
| celebdor1 | for both UDP and the VIP | 21:16 |
| celebdor1 | right | 21:16 |
| johnsom | Right now all that is allowed in is TCP and UDP ports. No other IP protocols, etc. | 21:16 |
| celebdor1 | well, you control the amp image | 21:16 |
| celebdor1 | nothing else is listening on other protocols, is it? | 21:16 |
| johnsom | Both of which we know there is something configured to listen on those ports. | 21:16 |
| johnsom | So you would expose an other kernel modules that happen to be loaded that deal with other protocols, you expose the VRRP and haproxy ports to the "outside" should a version come along that opens a new port, or an operator modifies the haproxy template exposing the management ports, etc. | 21:18 |
| johnsom | What we have now is a managed service, that is restricted to just the ports/protocols we support and test. If a user configures a TCP listener on 80, I know the SG is correct to allow that traffic. I don't get support calls because the user forgot to add the SG rule or didn't know someone applied a custom SG. | 21:20 |
| celebdor1 | all I'm hearing is that you are having SGs do the linux network namespace work that belongs by right to iptables | 21:21 |
| *** AlexStaf has joined #openstack-lbaas | 21:21 | |
| johnsom | Well, I will try next week to dig through everything and pull out links to the decisions we made on this before. Just so folks can read through the thought processes that went into this. Then we can decide if we want to go a different direction or stick with what we previously decided. | 21:22 |
| celebdor1 | sorry if that came across as harsh. I meant that the right tool for closing that in an operator provided image is to use iptables on that SG | 21:22 |
| celebdor1 | s/SG/namespace/ | 21:22 |
| johnsom | Adding iptables in the namespace means conntrack, which tanks the throughput and means you need to put more resources into your amphora instances. | 21:23 |
| celebdor1 | johnsom: thanks for that and for taking the time for us amidst your holidays | 21:23 |
| johnsom | That is why we have avoided it. Plus having the ACL outside the amp means if the amp gets compromised, they intruder can't just light up ports, they would have to go change the ACLs too. | 21:24 |
| celebdor1 | well, if you only care about opening the ports, you can probably do without conntrack | 21:25 |
| celebdor1 | (which is already on the default ml2/ovs firewall driver and I agree that better one than two) | 21:25 |
| johnsom | Sure, no problem. This has been a topic for a long time that the team has spent a lot of time discussing. There is hope that FWaaS shared groups would also be a solution to this, which is why the ACL option has been a lower priority, but he FWaaS v2 work has been slow. | 21:26 |
| celebdor1 | fwaas would leave you with the same problem for other octavia providers not being able to do their own impl | 21:27 |
| johnsom | Correct | 21:27 |
| *** yamamoto has joined #openstack-lbaas | 21:50 | |
| *** rcernin has joined #openstack-lbaas | 22:09 | |
| *** fnaval has quit IRC | 22:36 | |
| *** ccamposr has quit IRC | 23:15 | |
| rm_work | hmmm alright ima be out until at least dec 3-4 | 23:27 |
| rm_work | but johnsom and cgoncalves know how to reach me, at least | 23:27 |
| rm_work | if you need emergency reviews :P | 23:27 |
| *** rm_work has quit IRC | 23:33 | |
| *** rm_work has joined #openstack-lbaas | 23:33 | |
| *** celebdor1 has quit IRC | 23:43 | |
| rm_work | johnsom: this still kills me: http://paste.openstack.org/show/720201/ | 23:45 |
| rm_work | "loadbalancers": "654ddf45-b50c-40d8-9603-e2358503df1c", | 23:45 |
| rm_work | plural >_> | 23:45 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!