| *** celebdor has quit IRC | 00:16 | |
| *** abaindur has joined #openstack-lbaas | 00:17 | |
| *** JudeCross has joined #openstack-lbaas | 00:23 | |
| openstackgerrit | Michael Johnson proposed openstack/octavia-tempest-plugin master: Add v2 two-node scenario test https://review.openstack.org/605163 | 00:50 |
|---|---|---|
| *** JudeCross has quit IRC | 01:05 | |
| *** hongbin has joined #openstack-lbaas | 01:39 | |
| *** ramishra has joined #openstack-lbaas | 03:26 | |
| *** hongbin has quit IRC | 03:59 | |
| *** irenab has quit IRC | 04:01 | |
| openstackgerrit | Merged openstack/octavia master: Pass through DIB_LOCAL_ELEMENTS from localrc https://review.openstack.org/604933 | 04:11 |
| *** pcaruana has joined #openstack-lbaas | 04:14 | |
| *** yamamoto has quit IRC | 04:31 | |
| *** yamamoto has joined #openstack-lbaas | 04:31 | |
| *** pcaruana has quit IRC | 04:38 | |
| *** irenab has joined #openstack-lbaas | 04:39 | |
| openstackgerrit | Merged openstack/octavia-tempest-plugin master: Use the infra mirrors for DIB https://review.openstack.org/601332 | 04:45 |
| *** reedipb has joined #openstack-lbaas | 05:35 | |
| *** pcaruana has joined #openstack-lbaas | 05:43 | |
| *** JudeCross has joined #openstack-lbaas | 06:03 | |
| *** JudeCross has quit IRC | 06:07 | |
| *** blake has joined #openstack-lbaas | 06:08 | |
| *** blake has quit IRC | 06:39 | |
| *** blake has joined #openstack-lbaas | 06:40 | |
| *** blake has quit IRC | 06:45 | |
| *** rcernin has quit IRC | 07:02 | |
| *** velizarx has joined #openstack-lbaas | 07:12 | |
| *** velizarx has quit IRC | 07:31 | |
| *** celebdor has joined #openstack-lbaas | 07:46 | |
| *** JudeCross has joined #openstack-lbaas | 07:55 | |
| *** rcernin has joined #openstack-lbaas | 07:56 | |
| *** velizarx has joined #openstack-lbaas | 08:07 | |
| *** celebdor has quit IRC | 08:12 | |
| *** Emine has joined #openstack-lbaas | 08:17 | |
| *** velizarx has quit IRC | 08:24 | |
| *** velizarx has joined #openstack-lbaas | 08:28 | |
| *** abaindur has quit IRC | 08:30 | |
| openstackgerrit | Merged openstack/octavia master: Fix the API list performance regression https://review.openstack.org/603242 | 08:32 |
| *** abaindur has joined #openstack-lbaas | 08:48 | |
| *** rcernin has quit IRC | 09:16 | |
| *** salmankhan has joined #openstack-lbaas | 09:17 | |
| *** JudeCross has quit IRC | 09:27 | |
| openstackgerrit | Evgeny Fedoruk proposed openstack/octavia master: Fix fot utils LB DM transaction function https://review.openstack.org/605376 | 09:28 |
| openstackgerrit | Evgeny Fedoruk proposed openstack/octavia master: Fix for utils LB DM transformation function https://review.openstack.org/605376 | 09:37 |
| openstackgerrit | Evgeny Fedoruk proposed openstack/octavia master: Fix for utils LB DM transformation function https://review.openstack.org/605376 | 09:39 |
| openstackgerrit | Evgeny Fedoruk proposed openstack/octavia master: Fixing data model to_dict() recursive function https://review.openstack.org/605382 | 09:53 |
| *** celebdor has joined #openstack-lbaas | 09:56 | |
| velizarx | Hi folks! I have some strange question. I'm creating the table of relations (https://ibb.co/eQdxXU) between listener.protocol and pool.protocol to understand which protocols work with. And I see what listener.protocol = HTTPS it's "mode tcp" in haproxy configuration as well as pool.protocol = HTTPS it's "mode tcp". What the difference between protocol HTTPS and protocol TCP in this case? Why Octavia provides HTTPS like alias for TCP? | 09:59 |
| *** velizarx has quit IRC | 10:01 | |
| *** velizarx has joined #openstack-lbaas | 10:02 | |
| sapd1 | velizarx: I think to clear with end user. Somebody do not know use TCP if they want to setup HTTPS Load Balancer ( I mean frontend tcp, backend tcp and server backend use HTTPS). | 10:09 |
| *** reedipb has quit IRC | 10:11 | |
| velizarx | sapd1, Hm, I think for the end user it adds confusion. Let's wait johnsom | 10:15 |
| *** abaindur has quit IRC | 10:26 | |
| *** abaindur has joined #openstack-lbaas | 10:27 | |
| rm_work | They should use HTTPS if they want HTTPS backend members? | 10:27 |
| *** yamamoto has quit IRC | 10:35 | |
| velizarx | rm_work, In the haproxy configuration HTTPS looks the same TCP (see configs examples: https://pastebin.com/2g4htALU), and pool.protocol == TCP works fine. And it's the main reason why I asked question:) | 10:42 |
| sapd1 | velizarx: To clear for end user :D | 10:43 |
| *** yamamoto has joined #openstack-lbaas | 11:00 | |
| *** pcaruana has quit IRC | 11:15 | |
| *** irenab has quit IRC | 11:34 | |
| *** oanson has quit IRC | 11:35 | |
| *** savvas has joined #openstack-lbaas | 11:55 | |
| *** velizarx has quit IRC | 12:12 | |
| *** velizarx has joined #openstack-lbaas | 12:28 | |
| *** aojea_ has joined #openstack-lbaas | 12:29 | |
| *** yamamoto has quit IRC | 12:35 | |
| *** blake has joined #openstack-lbaas | 12:42 | |
| *** blake has quit IRC | 12:47 | |
| *** yamamoto has joined #openstack-lbaas | 13:13 | |
| *** yamamoto has quit IRC | 13:21 | |
| *** yamamoto has joined #openstack-lbaas | 13:21 | |
| *** yamamoto has quit IRC | 14:03 | |
| *** yamamoto has joined #openstack-lbaas | 14:04 | |
| *** yamamoto has quit IRC | 14:09 | |
| *** yamamoto has joined #openstack-lbaas | 14:52 | |
| *** pcaruana has joined #openstack-lbaas | 15:01 | |
| *** velizarx has quit IRC | 15:01 | |
| *** velizarx has joined #openstack-lbaas | 15:06 | |
| johnsom | The HTTPS protocol is for HTTPS pass-through use. | 15:16 |
| velizarx | johnsom, Thx for your answer. AFAIU difference between TCP and HTTPS pass-through it's monitoring options, but LB doesn't see L7 traffic. And why HTTP pass-through the best? | 15:22 |
| *** celebdor has quit IRC | 15:31 | |
| johnsom | HTTPS pass through is not necessary best as we can’t make good load balancing decisions with it. | 15:32 |
| johnsom | That said, we envisioned using the TLS session ID in HTTPS pass through to do session persistence. Though I am not sure that ever got implemented. | 15:33 |
| johnsom | That differentiates HTTPS from just TCP | 15:34 |
| *** savvas has quit IRC | 15:37 | |
| *** celebdor has joined #openstack-lbaas | 15:39 | |
| *** numans has joined #openstack-lbaas | 15:46 | |
| openstackgerrit | boden proposed openstack/neutron-lbaas master: add local tox targets for pep8 and py3 https://review.openstack.org/605466 | 15:53 |
| *** aojea_ has quit IRC | 15:55 | |
| *** amuller has joined #openstack-lbaas | 15:56 | |
| *** aojea has joined #openstack-lbaas | 15:56 | |
| openstackgerrit | boden proposed openstack/neutron-lbaas master: use common rpc and exceptions from neutron-lib https://review.openstack.org/605470 | 16:02 |
| *** ramishra has quit IRC | 16:09 | |
| *** blake has joined #openstack-lbaas | 16:09 | |
| *** celebdor has quit IRC | 16:12 | |
| *** Emine has quit IRC | 16:16 | |
| openstackgerrit | Michael Johnson proposed openstack/octavia-tempest-plugin master: DNM: Testing bionic nodes https://review.openstack.org/600539 | 16:22 |
| *** blake has quit IRC | 16:28 | |
| *** blake has joined #openstack-lbaas | 16:28 | |
| *** blake has quit IRC | 16:29 | |
| *** velizarx has quit IRC | 16:32 | |
| openstackgerrit | Michael Johnson proposed openstack/octavia-tempest-plugin master: Add v2 two-node scenario test https://review.openstack.org/605163 | 16:33 |
| *** velizarx has joined #openstack-lbaas | 16:35 | |
| *** velizarx has quit IRC | 16:55 | |
| *** salmankhan has quit IRC | 17:06 | |
| KeithMnemonic | Question on act/stdby in pike. I deploy an LB, and if I delete one of the amphoras, it creates a new amphor expected. However when I go to delete the LB, I get an message about immutable and the LB goes to ERROR and cannot be removed by the CLI. Has anyone seen this before? | 17:35 |
| xgerman_ | Yes, I have seen that. Mosy of my problems stem from ports not being cleaned up properly - there is a patch in a later versions to aggressively delete ports when lb delete. | 17:36 |
| KeithMnemonic | is that an easy backport to pike? | 17:37 |
| xgerman_ | no | 17:37 |
| KeithMnemonic | darn | 17:37 |
| johnsom | I have not seen that. Can you give us more information? | 17:38 |
| KeithMnemonic | sure, what do you want | 17:38 |
| johnsom | Details from the controller worker log file | 17:38 |
| KeithMnemonic | ok let me go repoduce it again now | 17:38 |
| johnsom | There should be some kind of error message of why it happened. | 17:39 |
| KeithMnemonic | so my steps, create an lb, once it is active, do a nova delete on one amp, wait for the new amp to spawn,connect,,,, and then delete the lb | 17:39 |
| johnsom | Yeah, that should work just fine | 17:40 |
| *** abaindur has quit IRC | 17:49 | |
| KeithMnemonic | ok almost ready to test the delete, i noticed that even though i have an ssh amp key, for some reason it is not working on the recovered amphora | 17:49 |
| KeithMnemonic | only on the originals | 17:49 |
| johnsom | That should not happen either | 17:50 |
| KeithMnemonic | the console show diff keys | 17:53 |
| johnsom | Host keys, but it should be the same nova keypair key. Are you sure all of your controllers have the same configuration files? | 17:53 |
| KeithMnemonic | so it may not happen, but it does. let me go verfiy they should | 17:54 |
| KeithMnemonic | i have the key name in worker.conf under controller_worker | 17:54 |
| KeithMnemonic | that setting is identical | 17:56 |
| KeithMnemonic | since this is being spawned by the health manager, does the key name need to be other places as well? | 17:56 |
| johnsom | No it shares that config setting and the key is stored in nova, so should pull the same key. We don't actually load that, nova does. | 17:58 |
| KeithMnemonic | ok one fish at a time ;-) | 18:00 |
| KeithMnemonic | let me do the delete | 18:00 |
| KeithMnemonic | this time it worked, maybe i was doing the delete too fast | 18:01 |
| johnsom | Well, it locks the objects to you can't really do it too fast, it should stop you. | 18:02 |
| *** celebdor has joined #openstack-lbaas | 18:05 | |
| KeithMnemonic | ok so on the ssh thing, it does not find the key | 18:10 |
| KeithMnemonic | that means i need that entry in another conf file or section? | 18:11 |
| johnsom | It is the exact same configuration setting, but it needs to be in the config files for CW, HM, and HK processes. I don't know if you are running separate config files for each process or not, but that is one of the shared settings. | 18:14 |
| KeithMnemonic | i bet that is my issue, sep conf files, fixing that now | 18:15 |
| *** evgenyf has joined #openstack-lbaas | 18:18 | |
| *** pcaruana has quit IRC | 18:24 | |
| *** yamamoto has quit IRC | 18:26 | |
| *** yamamoto has joined #openstack-lbaas | 18:26 | |
| *** maciejjozefczyk has joined #openstack-lbaas | 18:33 | |
| *** celebdor has quit IRC | 18:36 | |
| KeithMnemonic | ok conf file fixed the ssh issue and now i cannot get the imuutable message | 18:39 |
| KeithMnemonic | let me try one mor test | 18:39 |
| *** abaindur has joined #openstack-lbaas | 18:40 | |
| *** rtjure has quit IRC | 19:05 | |
| baffle | Running octavia:rocky with liberty nova and kilo neutron without native allowed-address-pairs support suprisingly works after some ugly modifications... | 19:07 |
| *** JudeCross has joined #openstack-lbaas | 19:07 | |
| *** rtjure has joined #openstack-lbaas | 19:08 | |
| *** salmankhan has joined #openstack-lbaas | 19:17 | |
| *** salmankhan has quit IRC | 19:22 | |
| *** Emine has joined #openstack-lbaas | 19:26 | |
| xgerman_ | baffle: tell us more… maybe a patch? | 19:30 |
| *** yboaron_ has joined #openstack-lbaas | 19:35 | |
| rm_work | hah yes I run octavia:master with liberty openstack and it works great :P though I have AAP | 19:38 |
| rm_work | buuuut i also use a totally different network driver, so :P | 19:38 |
| abaindur | is there any reason the flavor ID is fixed via config? | 19:50 |
| abaindur | rather than being allowed to be specified in the loadbalancer create call? | 19:50 |
| abaindur | A one size fits all loadbalancer solution really isnt ideal... we'd like to scale them up or down as needed individually | 19:50 |
| *** maciejjozefczyk has quit IRC | 19:54 | |
| johnsom | abaindur That is coming with flavors | 20:00 |
| johnsom | #startmeeting Octavia | 20:00 |
| openstack | Meeting started Wed Sep 26 20:00:12 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 |
| *** openstack changes topic to " (Meeting topic: Octavia)" | 20:00 | |
| openstack | The meeting name has been set to 'octavia' | 20:00 |
| johnsom | Hi folks | 20:00 |
| ltomasbo | o/ | 20:00 |
| xgerman_ | o/ | 20:00 |
| nmagnezi | o/ | 20:01 |
| johnsom | Pretty light agenda today | 20:01 |
| johnsom | #topic Announcements | 20:01 |
| *** openstack changes topic to "Announcements (Meeting topic: Octavia)" | 20:01 | |
| *** abaindur has quit IRC | 20:01 | |
| johnsom | We are in the last few days to vote for the TC, so if you have not already please check your e-mail and vote for our future TC members. | 20:02 |
| johnsom | I have also started the process to create octavia-lib as we discussed at the PTG. | 20:03 |
| johnsom | The intent of octavia-lib is to support the provider drivers with a "library" style release. | 20:03 |
| johnsom | Other than that, I don't think I have any announcements. Anyone else? | 20:03 |
| evgenyf | hi | 20:03 |
| rm_work | o/ | 20:03 |
| *** abaindur has joined #openstack-lbaas | 20:03 | |
| johnsom | #topic Brief progress reports / bugs needing review | 20:04 |
| *** openstack changes topic to "Brief progress reports / bugs needing review (Meeting topic: Octavia)" | 20:04 | |
| johnsom | I have mostly been busy with work from the PTG. I have created stories for the backend re-encryption work, and started a bunch of the gate test cleanup I started at the PTG. | 20:05 |
| evgenyf | I pushed 2 changes for provider driver framework, fixing to bugs | 20:05 |
| xgerman_ | #link https://review.openstack.org/#/c/587505/ | 20:05 |
| evgenyf | #link https://review.openstack.org/#/c/605382/ | 20:06 |
| xgerman_ | I rewrote it to appease my critics so review… | 20:06 |
| evgenyf | #link https://review.openstack.org/#/c/605376/ | 20:06 |
| ltomasbo | I reported on bug on a (seems to be) race on DB access: https://storyboard.openstack.org/#!/story/2003833 | 20:06 |
| johnsom | Right now I am working on getting multi-node working again after the zuul v3 changes. This is a bit of a challenge as most teams are still using the legacy multi-node code. Sorry for the channel noise as I work through getting this stuff to work. | 20:06 |
| xgerman_ | also playing with some refactor of the AAP driver: https://review.openstack.org/#/c/604479/ | 20:06 |
| johnsom | I have also started to backport the HM performance patch. Rocky is posted, Queens and Pike will be later today as those are not clean backports and need some careful work. | 20:07 |
| johnsom | Next up is fixing the Active/Standby topology with IPv6 VIPs, then I plan to focus on flavors. | 20:08 |
| johnsom | Whenever the octavia-lib repo is ready I will also work on moving the driver code out to the octavia-lib. | 20:08 |
| johnsom | Oh, and I hope to announce the neutron-lbaas end of life this week as we agreed at the PTG. | 20:09 |
| *** nmagnezi is now known as nmagnezi_meeting | 20:09 | |
| *** nmagnezi_meeting is now known as nmagnezi | 20:10 | |
| johnsom | Any other updates this week? (Thanks to you all that provided them!) | 20:10 |
| evgenyf | I created a story related to provider driver loading function driver_factory.get_driver(), please review and share your feedback | 20:11 |
| evgenyf | #link https://storyboard.openstack.org/#!/story/2003875 | 20:11 |
| nmagnezi | Both cgoncalves and myself are on a leave this week, so no updates from our side | 20:11 |
| xgerman_ | yeah, about cgoncalves he owes me a +@ | 20:11 |
| evgenyf | johnsom: is there something to review for octavia_lib? | 20:12 |
| johnsom | evgenyf Yeah, the statement that a driver has "state" that isn't stored outside the API process (driver DB or in an appliance) is very worrisome | 20:12 |
| johnsom | It is waiting on governance and infra reviews: | 20:12 |
| johnsom | #link https://review.openstack.org/604890 | 20:12 |
| johnsom | #link https://review.openstack.org/605273 | 20:13 |
| johnsom | #link https://review.openstack.org/604889 | 20:13 |
| johnsom | Those are the first steps, once the repo is created I will setup the cookiecutter, pypi, etc. for it. | 20:13 |
| johnsom | I'm hoping it will be ready to start moving the driver code out by next week. | 20:14 |
| johnsom | #topic Talk about VIP security groups | 20:15 |
| *** openstack changes topic to "Talk about VIP security groups (Meeting topic: Octavia)" | 20:15 | |
| johnsom | Ok, next on the agenda (sorry it was late this week) is the SG discussion we held over from last week. | 20:15 |
| ltomasbo | did anyone investigate other possible solutions for it? | 20:15 |
| johnsom | Does anyone have any research info to share? | 20:15 |
| *** abaindur has quit IRC | 20:16 | |
| johnsom | Yeah, that is my question to the team | 20:16 |
| ltomasbo | I did (a week ago) test applying the SG to the VIP, and that is not working on ml2/ovs driver, as the VIP port is just attached to the amphora as an allowed_address_pair | 20:16 |
| *** abaindur has joined #openstack-lbaas | 20:17 | |
| ltomasbo | and the SG applied is the one on the amphora port instead | 20:17 |
| xgerman_ | mmh, so we would need to handle the applying ourselves | 20:17 |
| ltomasbo | I, for instance, tested with ovn-octavia driver, and as they used the VIP in a different way, there it is possible to apply it there | 20:18 |
| xgerman_ | well, we like to be uniform among all drivers | 20:18 |
| ltomasbo | yep, actually in ovn-octavia the SG on the VIP port belongs to the tenant actually | 20:19 |
| ltomasbo | as they do not create the VIP port, and therefore it just gets the default one (which seems to be wrong and we opened a bug related to it) | 20:19 |
| johnsom | Yeah, the VIP belongs to the tenant in the reference driver too. | 20:19 |
| xgerman_ | +1 | 20:20 |
| ltomasbo | https://bugs.launchpad.net/networking-ovn/+bug/1794020 | 20:20 |
| openstack | Launchpad bug 1794020 in networking-ovn "Security Group Creation in octavia's OVN Driver" [Undecided,New] - Assigned to Reedip (reedip-banerjee) | 20:20 |
| johnsom | Which was a compromise that is really a problem now | 20:20 |
| xgerman_ | nah, it let the user assign a FIP so good times | 20:20 |
| johnsom | Right, but now users can break that VIP port as they own it. | 20:22 |
| ltomasbo | johnsom, break it as in what sense? | 20:22 |
| xgerman_ | they delete it out of band with their purge script | 20:23 |
| ltomasbo | johnsom, you mean deleting it? | 20:23 |
| xgerman_ | yep | 20:23 |
| xgerman_ | or whatever else comes to their mind. I just had a user who deleted the Octavia VM flavor and was surprised | 20:23 |
| ltomasbo | xD | 20:24 |
| ltomasbo | I didn't know the flavor was visible to the tenant... | 20:24 |
| xgerman_ | it is not but some are admin and do silly things | 20:24 |
| ltomasbo | usually tenants cannot create/modify flavors | 20:24 |
| ltomasbo | ahh, sure, but there is nothing you can do about that! | 20:24 |
| xgerman_ | yep, but they called me in ayway :-( | 20:25 |
| ltomasbo | xD | 20:25 |
| johnsom | Yeah, it is mostly users (non-admin) that are running "apply to all" scripts that end up causing trouble. | 20:25 |
| ltomasbo | johnsom, but there is not much you can do with that port besides deleting it | 20:25 |
| ltomasbo | you can change the SG, but it has no effect whatsoever | 20:26 |
| johnsom | Really we want to remove their visibility to it at all | 20:26 |
| ltomasbo | yep, it will be nice to not have it listed... but it is still consuming an IP from tenant network | 20:26 |
| xgerman_ | I used to be a big fan to give users lot’s of freedom until I met them… | 20:26 |
| xgerman_ | ok, for the VIP we have a plan to create a shadow VIP holding the IP… | 20:27 |
| rm_work | yeah, that was the one i was in favor of | 20:27 |
| rm_work | assuming it works technically | 20:27 |
| rm_work | we already have a VIP table, just include another column for the shadow_vip_id | 20:28 |
| xgerman_ | pretty sure if we make it an AAP ip it *should* be fine | 20:28 |
| rm_work | and create an extra thing, and done | 20:28 |
| xgerman_ | boo, | 20:28 |
| xgerman_ | boom | 20:28 |
| rm_work | well, we need to account for non-AAP drivers I suppose | 20:28 |
| xgerman_ | yep | 20:28 |
| xgerman_ | revert to the old model ;-) | 20:28 |
| johnsom | Yeah, not sure it should be an AAP port as it's not bound, so not sure the win on that | 20:29 |
| rm_work | ah does it not have t be | 20:29 |
| rm_work | to share the IP | 20:29 |
| rm_work | can we create a second port with the same IP that's not AAP enabled, as long as we never bind it? | 20:29 |
| rm_work | i thought just creating it required AAP | 20:29 |
| johnsom | Hmm, not sure if we don't actually use the port | 20:29 |
| rm_work | but maybe not? | 20:29 |
| ltomasbo | yep, it will not always be a AAP port, in fact, in ovn-driver it is not an AAP | 20:29 |
| rm_work | but i mean, we can leave that up to the driver | 20:30 |
| rm_work | we'd be creating it in our normal vip_allocate method | 20:30 |
| rm_work | in the AAP driver | 20:30 |
| rm_work | so really we're just talking about an AAP driver enhancement anyway | 20:30 |
| rm_work | because this doesn't even necessarily apply to others | 20:30 |
| xgerman_ | +1 | 20:30 |
| rm_work | so i think it's not a huge problem | 20:30 |
| xgerman_ | but back to the problem at hand: don’t think we can have a shadow SG | 20:31 |
| ltomasbo | if different drivers can implement octavia resources in different ways, how do you ensure they belong to the admin? that will be driver-dependant, right? | 20:31 |
| xgerman_ | yes, indeed | 20:32 |
| ltomasbo | could we make the driver to select to whom the resources belong? | 20:32 |
| ltomasbo | for instance, VIP could also belong to the admin (on octavia.conf) if the customer does not need to assign floating ips | 20:32 |
| ltomasbo | similarly for the SG | 20:32 |
| xgerman_ | yes, that sounds interesting — might even be a flavor thing | 20:33 |
| johnsom | Well, there should be some consistency. Especially around the API. | 20:33 |
| rm_work | yes, in my FLIP driver, i do not give the VIP to the tenant | 20:33 |
| johnsom | For example, we are talking about adding the ability for a user to specify a security group via the API | 20:33 |
| rm_work | for example :) | 20:33 |
| ltomasbo | johnsom, I agree that is the perfect solution! | 20:34 |
| ltomasbo | johnsom, but it is not there yet... :/ | 20:34 |
| ltomasbo | johnsom, do you think applying the sg via API could be completed in this cycle? | 20:35 |
| johnsom | What we were supposed to be researching is how to handle that security group. Ideally we would add that to the port, it would AND with our existing SG and we are in good shape. But the question is, in neutron ports, is that how multiple security groups work? | 20:35 |
| ltomasbo | johnsom, and could we do something about previous releases (as API changes are not really backportable) | 20:35 |
| ltomasbo | johnsom, if there is a rule accepting it, it goes through | 20:36 |
| ltomasbo | johnsom, everything is denied by default, and then if some rule matches, it goes through | 20:36 |
| johnsom | So, if we have two SGs on a port, A and B. B says "only port 80" and A says "open everything", the resultant is "open everything"? | 20:37 |
| ltomasbo | yep | 20:37 |
| johnsom | Yeah, so that is exactly what we don't want | 20:37 |
| johnsom | What we want is an AND, where the resultant is "only port 80" | 20:37 |
| xgerman_ | we can always strip the group the user provides of all rules… but that’s invasive | 20:38 |
| johnsom | And they can just change it | 20:38 |
| xgerman_ | and not enforcable | 20:38 |
| ltomasbo | another option is update the listener API, with a more similar syntax to SG rule creation | 20:39 |
| johnsom | The idea with the AND is it would allow the user to narrow the scope, but not expand it | 20:39 |
| ltomasbo | so that it allows you to create more fine grain rules | 20:39 |
| ltomasbo | and then, ther will be only one SG, but with several rules | 20:39 |
| johnsom | Yeah, that was the other proposal that was previously agreed to. Add an ACL API to the LB | 20:39 |
| johnsom | The third was using FWaaS, which was planning to support the "AND" option, but I don't think it does yet. Is that correct xgerman_? | 20:40 |
| ltomasbo | plus it adds another dependency | 20:41 |
| xgerman_ | it supports it but it’s not enabled by default | 20:41 |
| johnsom | Yeah, the additional dependency is not ideal either | 20:42 |
| ltomasbo | and that will be T release most probably? | 20:43 |
| xgerman_ | we won’t have an ideal outcome… | 20:43 |
| xgerman_ | well, the peices are there you just need to enable it | 20:43 |
| ltomasbo | yep, that is why I wanted to have this small revert-able fix for steain and previous releases until ACL or similar is in place | 20:43 |
| ltomasbo | *stein | 20:44 |
| *** amuller has quit IRC | 20:44 | |
| xgerman_ | it’s hard to add something and then take it away | 20:44 |
| ltomasbo | but if it is disable by default... and just enable upon need... | 20:45 |
| ltomasbo | you can just disable it once the right solution is enabled | 20:45 |
| ltomasbo | but yep, another bad things is that if there is a solution in place (even if it is not good) there is less urgent for the proper fix | 20:46 |
| johnsom | Does anyone know how "remote_group_id" works? | 20:49 |
| johnsom | In a security group rule? | 20:49 |
| ltomasbo | yep | 20:49 |
| ltomasbo | that basically enables traffic from ports that has that SG id | 20:49 |
| ltomasbo | so if the rules says remote_group_id=SG_A | 20:49 |
| ltomasbo | all the ports that has SG_A in their security group can access it | 20:49 |
| johnsom | Ah, ok. | 20:50 |
| ltomasbo | what I don't know is if, for instance, if you create a SG on the tenant, but add a dummy rule inside as an admin | 20:51 |
| xgerman_ | yeah, all the SG build a transitive group and allow all traffic between each other | 20:51 |
| ltomasbo | that will make the user imposible to remove it | 20:51 |
| ltomasbo | ahh, well, the amphora is using it, so it cannot remove it anyway | 20:51 |
| johnsom | Yeah, so unless we are willing to give up SG control all together, I think the only option (short of changing neutron SGs) is to add the ACLs to the API. | 20:51 |
| johnsom | The other topic discussed was letting the SG go, making it tenant facing, and relying on iptables in the amphora kernel or the provider. | 20:53 |
| ltomasbo | johnsom, how do you ensure that at the moment? | 20:54 |
| ltomasbo | user could still open any port on the SG by creating the right listener | 20:54 |
| ltomasbo | so giving away the SG will not change any of that | 20:54 |
| johnsom | We don't. It's just the "open" port at the moment. This was because of the performance overhead of adding conntrack to the amphora... | 20:55 |
| ltomasbo | rather the opossite, limiting the access to the amphora to the ports on the same subnet or form the same remote_group_id | 20:55 |
| xgerman_ | we can’t assume users do what we ant | 20:57 |
| ltomasbo | sure! I just meant that they can already open any port they want by creating a listener | 20:58 |
| xgerman_ | I know people were reading out our SG. manipulating it, and using it for access restrictions | 20:58 |
| johnsom | Currently, they can restrict the source by setting up tenant networks, but I get that it is less than ideal | 20:58 |
| johnsom | Right, but with the listener we know the right thing is there and on that port. | 20:58 |
| xgerman_ | yep, we will listen ;-) | 20:59 |
| ltomasbo | :) | 20:59 |
| johnsom | Darn, we are out of time today.... | 20:59 |
| *** evgenyf has quit IRC | 21:00 | |
| ltomasbo | thanks for discussing it! | 21:00 |
| johnsom | Thanks folks | 21:00 |
| johnsom | #endmeeting | 21:00 |
| *** openstack changes topic to "OpenStack PTG etherpad: https://etherpad.openstack.org/p/octavia-stein-ptg" | 21:00 | |
| openstack | Meeting ended Wed Sep 26 21:00:16 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 21:00 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/octavia/2018/octavia.2018-09-26-20.00.html | 21:00 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/octavia/2018/octavia.2018-09-26-20.00.txt | 21:00 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/octavia/2018/octavia.2018-09-26-20.00.log.html | 21:00 |
| ltomasbo | appreciated the time! | 21:00 |
| *** aojea has quit IRC | 21:01 | |
| johnsom | I will put it on next weeks agenda as well. I think we are really down to two options we should discuss more. | 21:01 |
| xgerman_ | +1 | 21:06 |
| rm_work | wait, the remote_group_id thing sounded like it'd work perfectly? | 21:12 |
| rm_work | sorry i had to go afk for a minute right when we started discussing that T_T | 21:12 |
| xgerman_ | mmh, there was one snag people hit. Not sure if it can admin owned to work… | 21:14 |
| johnsom | I thought it didn't solve the "I want to limit access to my VIP to only be from 15.0.0.0/8" | 21:15 |
| *** yboaron_ has quit IRC | 21:28 | |
| *** blake has joined #openstack-lbaas | 21:29 | |
| xgerman_ | well, you will need to assign that SG to the nodes you want to allow access from | 22:00 |
| *** rcernin has joined #openstack-lbaas | 22:35 | |
| *** rcernin has quit IRC | 22:53 | |
| *** rcernin has joined #openstack-lbaas | 22:55 | |
| *** blake_ has joined #openstack-lbaas | 23:02 | |
| *** blake has quit IRC | 23:05 | |
| *** colby_ has quit IRC | 23:16 | |
| openstackgerrit | German Eichberger proposed openstack/octavia master: [WIP] Refactor the pluggin of the VIP https://review.openstack.org/604479 | 23:24 |
| *** blake_ has quit IRC | 23:26 | |
| *** rcernin_ has joined #openstack-lbaas | 23:41 | |
| *** blake has joined #openstack-lbaas | 23:41 | |
| *** rcernin has quit IRC | 23:43 | |
| *** blake has quit IRC | 23:45 | |
| *** openstackgerrit has quit IRC | 23:49 | |
| *** blake has joined #openstack-lbaas | 23:55 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!