Friday, 2022-05-27

opendevreviewyatin proposed openstack/networking-ovn stable/train: [OVN] Pin OVS/OVN versions in Octavia job  https://review.opendev.org/c/openstack/networking-ovn/+/84347705:13
opendevreviewyatin proposed openstack/networking-ovn stable/train: Revert "Use Port_Binding up column to set Neutron port status"  https://review.opendev.org/c/openstack/networking-ovn/+/84339105:29
opendevreviewyatin proposed openstack/networking-ovn stable/train: Refactor the OVN revision module to access the DB correctly  https://review.opendev.org/c/openstack/networking-ovn/+/84348605:35
opendevreviewLajos Katona proposed openstack/networking-bagpipe master: Remove "distutils" library  https://review.opendev.org/c/openstack/networking-bagpipe/+/84236906:37
lajoskatonaslaweq, obondarev: when you have some free time could you please check this doc patch to add back fwaas docs to Neutron doc tree: https://review.opendev.org/c/openstack/neutron/+/841748 ?06:41
obondarevlajoskatona: sure, done06:45
lajoskatonaobondarev: thanks06:45
opendevreviewFernando Royo proposed openstack/ovn-octavia-provider master: Fix way of calculate LB status after HM event  https://review.opendev.org/c/openstack/ovn-octavia-provider/+/84330807:07
opendevreviewyatin proposed openstack/neutron master: [WIP] Switch fullstack/functional fips jobs to 9-stream  https://review.opendev.org/c/openstack/neutron/+/84324507:34
opendevreviewyatin proposed openstack/neutron master: [DNM] fips fullstack/functional test without dbcounter  https://review.opendev.org/c/openstack/neutron/+/84325207:37
opendevreviewOleg Bondarev proposed openstack/neutron master: Functional test: wait for dhclient in test_good_address_allocation  https://review.opendev.org/c/openstack/neutron/+/84338907:40
opendevreviewyatin proposed openstack/neutron master: [WIP] Switch fullstack/functional fips jobs to 9-stream  https://review.opendev.org/c/openstack/neutron/+/84324507:53
opendevreviewMerged openstack/neutron master: Create an index for "ports.network_id"  https://review.opendev.org/c/openstack/neutron/+/84176107:59
opendevreviewEdward Hope-Morley proposed openstack/neutron stable/yoga: Partially revert "Do not link up HA router gateway in backup node"  https://review.opendev.org/c/openstack/neutron/+/84358108:38
opendevreviewEdward Hope-Morley proposed openstack/neutron stable/xena: Partially revert "Do not link up HA router gateway in backup node"  https://review.opendev.org/c/openstack/neutron/+/84358208:42
opendevreviewyatin proposed openstack/neutron master: [DNM] fips fullstack/functional test without dbcounter  https://review.opendev.org/c/openstack/neutron/+/84325208:44
ralonsohbcafarel, https://review.opendev.org/q/Id1907481077d230e4461906a1a2a1447abac330a if you have some minutes. I've replied to your comments08:49
ralonsohthanks in advance08:49
ykarellajoskatona, slaweq ralonsoh can you please check the revert https://review.opendev.org/c/openstack/neutron/+/84342608:57
ralonsohok08:58
ykarelsquashed  multiple commits08:58
ykarelthx in advance08:58
lajoskatonaykarel: I set https://bugs.launchpad.net/tripleo/+bug/1964940 to have Neutron affected09:00
ykarellajoskatona, okk09:01
opendevreviewyatin proposed openstack/neutron master: [DNM] fips fullstack/functional test without dbcounter  https://review.opendev.org/c/openstack/neutron/+/84325209:10
lajoskatonaykarel: wouldn't it be simpler to revert one-by-one?09:14
ykarellajoskatona, need to backport these till train, after yoga, all these are already squashed09:15
ykarelso thought of doing same in yoga/master09:15
lajoskatonaykarel: I feared it will be the answer, for future reference I will add comment to review to make it cleaner for the future developers :-)09:16
ykarellajoskatona, ok Thanks09:17
slaweqykarel: +209:21
opendevreviewFernando Royo proposed openstack/ovn-octavia-provider master: Fix request to OVN NB DB API  https://review.opendev.org/c/openstack/ovn-octavia-provider/+/83905509:31
opendevreviewyatin proposed openstack/networking-ovn stable/train: [DNM] Test ovn tempest job on nested virt nodes  https://review.opendev.org/c/openstack/networking-ovn/+/84358809:34
slaweqlajoskatona: ralonsoh ykarel hi, I'm now looking at https://review.opendev.org/c/openstack/neutron/+/841246 and TBH I think that we should remove requirements.txt file from the irrelevant files list for e.g. scenario jobs09:40
slaweqIMO any changes in requirements should be tested with all possible jobs09:40
ralonsohslaweq, agree09:41
slaweqI can propose patch for it but I first wanted to know Your opinion about it09:41
ralonsohslaweq, in any case, we usually take the upper versions defined in requirements09:41
ralonsohactually, this version of n-lib is being used right now09:41
ralonsohthis patch is only to "consolidate"09:41
ralonsohbut I'm ok09:42
slaweqyeah, I'm good with this patch09:42
ralonsohplease, propose this patch09:42
slaweqbut I'm talking generally about requirements file09:42
slaweqas I just discovered that in that patch :)09:42
slaweqralonsoh++ ok, I will propose it09:42
opendevreviewMerged openstack/neutron master: [UT][ovn] Access config options after they are registered  https://review.opendev.org/c/openstack/neutron/+/84346110:07
opendevreviewSlawek Kaplonski proposed openstack/neutron master: Remove requirements.txt from irrelevant files in CI jobs  https://review.opendev.org/c/openstack/neutron/+/84359410:09
opendevreviewFernando Royo proposed openstack/ovn-octavia-provider master: Fix Load balancer remains on PENDING_CREATE  https://review.opendev.org/c/openstack/ovn-octavia-provider/+/84238210:18
opendevreviewFrode Nordahl proposed openstack/neutron master: [OVN] Make binding profile validation more robust  https://review.opendev.org/c/openstack/neutron/+/84360110:30
opendevreviewFernando Royo proposed openstack/ovn-octavia-provider master: Fix Load balancer remains on PENDING_CREATE  https://review.opendev.org/c/openstack/ovn-octavia-provider/+/84238210:37
ykarelslaweq, almost all jobs already run with upper-constraints10:39
ykarelnot sure running all those jobs jobs with requirements.txt will really help10:40
ykareldependency related issue should alraedy be caught by the limited functional, tox jobs running there10:40
ykarelor there is some case where we can catch some issues with those extra jobs?10:40
ykareli commented just to understand that case, else i think it's just extra load 10:54
ralonsohlucasagomes, https://review.opendev.org/c/openstack/networking-ovn/+/843477 please, we need this patch to fix the n-ovn CI11:06
opendevreviewElvira García Ruiz proposed openstack/neutron-specs master: Add spec for DNS subdomain support in OVN  https://review.opendev.org/c/openstack/neutron-specs/+/83265811:16
opendevreviewMerged openstack/neutron master: Remove session active check in "_add_segment_host_mapping_for_segment"  https://review.opendev.org/c/openstack/neutron/+/84329411:20
opendevreviewMerged openstack/neutron master: Revert "doc: Remove fwaas references from docs"  https://review.opendev.org/c/openstack/neutron/+/84174811:20
opendevreviewMerged openstack/neutron stable/yoga: Switch to cirros uec image in multinode jobs  https://review.opendev.org/c/openstack/neutron/+/84339611:20
opendevreviewMerged openstack/neutron stable/xena: Switch to cirros uec image in multinode jobs  https://review.opendev.org/c/openstack/neutron/+/84345311:20
opendevreviewMerged openstack/neutron stable/wallaby: Switch to cirros uec image in multinode jobs  https://review.opendev.org/c/openstack/neutron/+/84345611:20
slaweqykarel: I don't know any specific case when it can catch some specific issue11:20
opendevreviewMerged openstack/neutron master: [OVN][FT] Wait until virtual parents are written  https://review.opendev.org/c/openstack/neutron/+/84129811:20
opendevreviewElvira García Ruiz proposed openstack/neutron-specs master: Add spec for DNS subdomain support in OVN  https://review.opendev.org/c/openstack/neutron-specs/+/83265811:21
slaweqI just tought  that it may be good to run all jobs on such changes, e.g. when we are adding/removing something from requirements file11:21
ykarelslaweq, ralonsoh pointed out one valid case i.e removing a requirement which may cause tempest failure11:22
slaweqyeah, that's what I though too11:23
lajoskatonaslaweq, ykarel: I agree with slaweq, it is slightly related but now to have some early feedback I created a DNM patch in neutron-tempest-plugin to run all stadiums also with this change11:24
lajoskatonaslaweq, ykarel: and as it was a depends-on only I have to check if I got really the result which I was looking for11:24
slaweqlajoskatona: I think they should be ok, but it's worth to check to be sure11:25
ykarelyeap those should be already ok as all should be using u-c11:26
opendevreviewRodolfo Alonso proposed openstack/neutron master: Set "type=virtual" for OVN LSP with parent ports  https://review.opendev.org/c/openstack/neutron/+/84347411:27
lucasagomesralonsoh, looking, sorry I was having lunch11:58
ralonsohsure, no rush11:59
opendevreviewMerged openstack/networking-ovn stable/train: [OVN] Pin OVS/OVN versions in Octavia job  https://review.opendev.org/c/openstack/networking-ovn/+/84347712:11
opendevreviewMerged openstack/neutron master: Refactor the OVN revision module to access the DB correctly  https://review.opendev.org/c/openstack/neutron/+/84347812:12
opendevreviewMerged openstack/neutron master: Bump neutron-lib to 2.21.0  https://review.opendev.org/c/openstack/neutron/+/84124612:12
opendevreviewyatin proposed openstack/neutron master: [DNM] fips fullstack/functional test without dbcounter  https://review.opendev.org/c/openstack/neutron/+/84325212:15
opendevreviewyatin proposed openstack/tap-as-a-service master: Make neutron tempest plugin job voting again  https://review.opendev.org/c/openstack/tap-as-a-service/+/84361512:31
ykarellajoskatona, switching back to voting ^12:31
lajoskatonaykarel: thanks, it was on my todo, but just burning my time on meetings :-)12:33
opendevreviewFrode Nordahl proposed openstack/neutron master: [OVN] Make binding profile validation more robust  https://review.opendev.org/c/openstack/neutron/+/84360112:39
opendevreviewyatin proposed openstack/neutron master: [WIP] Switch fullstack/functional fips jobs to 9-stream  https://review.opendev.org/c/openstack/neutron/+/84324513:07
opendevreviewGhanshyam proposed openstack/neutron-tempest-plugin master: DNM: testing Tempest pin in stable/victoria  https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/84329913:51
lajoskatona#startmeeting neutron_drivers14:00
opendevmeetMeeting started Fri May 27 14:00:23 2022 UTC and is due to finish in 60 minutes.  The chair is lajoskatona. Information about MeetBot at http://wiki.debian.org/MeetBot.14:00
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.14:00
opendevmeetThe meeting name has been set to 'neutron_drivers'14:00
opendevreviewSlawek Kaplonski proposed openstack/neutron master: Use new combined neutron_tempest_plugin as nftables jobs parent  https://review.opendev.org/c/openstack/neutron/+/84361814:00
lajoskatonao/14:00
mlavalle2o/14:00
opendevreviewSlawek Kaplonski proposed openstack/neutron master: Update ci jobs docs  https://review.opendev.org/c/openstack/neutron/+/84361914:00
amotokihi14:00
mtomaskao/14:00
slaweqo/14:01
lajoskatonaI think we can start14:02
lajoskatonaWe have one RFE for today:14:02
lajoskatona[RFE] Allow setting --dst-port for all port based protocols at once (#link https://bugs.launchpad.net/neutron/+bug/1973487)14:02
lajoskatonathe idea seems valid for me14:03
mtomaskaBackground: This came from a customer I have been working with14:03
lajoskatonamtomaska: yeah that is mentioned in one of the comments14:04
slaweqAFAIK current behaviour is consistent with e.g. iptables14:04
mtomaskamy main concern is if that option can bring some implications. In another words...14:04
slaweqand if we will accept protocol "any" and some port, we will need to apply many rules in e.g. iptables (I'm not sure about ovn and ovs fw)14:04
amotokidst-port is L4 field so it totally depends on L4 protocol. How can we support all L4 protocol?14:05
amotokiI am not sure how we can determine if a L4 protocol is port-based.14:06
ralonsoh(hi, sorry, network problems)14:06
mtomaskaDo you see any corner cases such that specifying '--protocol all_l4' would case problems on some systems? The 'all_l4' protocol arg will just iterate over this list of protocols14:08
mtomaskahttps://github.com/openstack/neutron/blob/master/neutron/common/_constants.py#L23-L2914:08
mlavalle2and maybe we should not get so hung up on the "L4" piece. If we were going to implement this, we would clarify the list of protocols supported by the feature14:10
mtomaskaI also want to mention that customer was just annoyed that they have to issue cli command for each --protocol (udp | tcp and so on). The counter argument could be that its not hard to automate it :)14:10
lajoskatonamlavalle2: aggree the bases of that should be the above constant14:11
mlavalle2yeap14:11
amotokimlavalle2: +114:11
slaweqthere is 5 protocols in that list mtomaska so is it really that hard for the customer to automate it on the client's side?14:11
obondarevhi, sorry for being late14:12
slaweqIMHO it sounds like something what should be done on the client's side really14:12
mtomaskaslaweq. IDK but that was my response as well :)14:12
lajoskatonaIs there any difference if the user call 5 CLIs to issue this or doing the same with one call from iptables or such perspective?14:12
opendevreviewyatin proposed openstack/neutron master: [WIP] Switch fullstack/functional fips jobs to 9-stream  https://review.opendev.org/c/openstack/neutron/+/84324514:12
slaweqotherwise You will then have SG rule with protocol "all_l4" (all whatever else) and will need to use in docs what that exactly means14:12
lajoskatonathe client side was in my mind also, not sure if HEAT can do such thing for example14:13
slaweqI'm not going to block this rfe, but personally I'm not very enthusiastic about it :)14:13
mlavalle2ah,, so implement this somewhere in OpenStack, although not necessarily thorugh the Neutron API14:13
haleybas a data point it doesn't look like iptables allows this behavior, you have to make individual rules using -p individually14:14
mtomaskaapparently heat only supports tcp. udp and icmp https://docs.openstack.org/heat/latest/template_guide/openstack.html#OS::Neutron::SecurityGroup14:14
mlavalle2but I think that what was meant is that this might be a RFE for Heat, or the clients14:15
mlavalle2regardless of what they support right now14:15
lajoskatonamtomaska: so there's thing to do in heat also14:15
opendevreviewSlawek Kaplonski proposed openstack/neutron-tempest-plugin master: Update OVS and OVN branches used in the CI jobs  https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/84362214:15
lajoskatonaok, so if iptables anyway works this way let's say it is better to do it from the client side14:17
mtomaskaright, we could propose that HEAT supports other two protocols from the list. That is UDP-Lite dccp and sctp14:17
amotokiI personally am not very excited with this proposal. this looks like an area where some automation tool (or client side) can cover (as others already mentioned)14:17
mtomaskathis way the user has few option to automate. Write your own script :), use HEAT, use Ansible 14:18
mtomaskaor whatever they like to use to automate 14:18
mlavalle2or even without automation on the part of the operator, if this were to be implemented in the openstack client14:19
opendevreviewEdward Hope-Morley proposed openstack/neutron stable/xena: Partially revert "Do not link up HA router gateway in backup node"  https://review.opendev.org/c/openstack/neutron/+/84358214:19
mlavalle2the client might be the right place in the stack to implement this14:19
slaweqmtomaska exactly, and plus value of such solution is that when he will do SG rules list, he will see all rules which are really created by backend14:19
lajoskatonamlavalle2: you mean openstacksdk?14:20
mlavalle2maybe14:20
mtomaskaok so who votes for "automate at the client side" ?14:21
mtomaskao/14:21
mlavalle2I think through this discussion we have higlighted that it is not clear where in the stack is the best place to implement this14:21
amotokipotentially OSC can accept a list of protocols as --protocol argument. if so, the next question is how osc should behave if a subset of protocols fails (e.g. as dst-port is not supported)14:21
lajoskatonaslaweq, mtomaska: that is also good point that the list will be clear, and will display all protocol-port pair14:21
mlavalle2but it seems the Neutron API is unlikely to be that place14:22
lajoskatonamtomaska: after this discussion I vote to place it to the client side14:23
haleybamotoki: that's a good question, which is maybe why i don't like this proposal14:23
amotokihaleyb: yeah14:23
opendevreviewSlawek Kaplonski proposed openstack/neutron-lib master: Check proper config option to see if scope is enforced or not  https://review.opendev.org/c/openstack/neutron-lib/+/83995614:23
haleybi am curious about the API impact - on a POST today you get back a single object, is returning many even an option?14:24
ralonsohI think amotoki could be a good alternative, IMO14:25
ralonsohamotoki's idea14:25
amotokihaleyb: the neutron API supports bulk creation of resources. I think if we would like to create multiple sg rules, bulk creation would be used.14:26
mlavalle2yeap14:26
haleybamotoki: thanks for reminding me of that14:26
lajoskatonabut no bulk for security-groups or rules14:27
ralonsohnot yet, no14:28
amotokiah, I haven't checked which resources support bulk creation14:28
mlavalle2yes, but it means that the concept of bulk creation in general is compatible with the API14:29
mlavalle2it wouldn't be an aberration14:29
lajoskatonamalavalle2: +114:29
amotokimlavalle2: +114:29
lajoskatonaso generally we agree that it is better to be done on the client side, but perhaps Neutron need bulk support for security-groups and rules, am I right?14:32
amotokilajoskatona: it sounds good14:32
amotokiIIRC, another point on bulk creation is osc and sdk have no support for bulk creation right now14:32
mtomaskasounds good to me14:32
lajoskatonaamotoki: thanks14:33
slaweq+114:33
ralonsohI think so if we want to, for example, fail and remove any SG already created14:33
mlavalle2yes, but I don't think we have a pressing need for SG bulk creation14:33
mlavalle2with that clarification +114:33
lajoskatonathanks14:34
lajoskatonasummary the RFE is not accepted14:34
lajoskatonaok, if no more comments on this we can move on14:35
lajoskatona#topic On Demand Agenda14:36
lajoskatona(lajoskatona): meaning of option "router_auto_schedule" is ambiguous (#link https://bugs.launchpad.net/neutron/+bug/1973656 )14:36
lajoskatonaif I understand well the original question was to rename router_auto_schedule to something else14:39
lajoskatonaand an intersting discussion is now under this question, with haleyb and obondarev with their good memories :-)14:40
ralonsohaccording to the LP comments, I think we should improve the documentation14:40
ralonsohbut I'm not sure about the name change14:40
obondarev+1 for doc improve14:41
slaweqI'm looking now at network_auto_schedule option, which is pretty similar but for the networks to be scheduled to the dhcp agents14:41
slaweqand it seems from https://github.com/openstack/neutron/blob/aff0a75ecb76e12f240b4ab00a8ecfc75776216b/neutron/db/agentschedulers_db.py#L48114:41
ralonsoh^^ exactly14:41
lajoskatonagood analogy14:41
slaweqthat it would control if neutron should try to schedule networks automatically to the dhcp agents or not14:42
slaweqand that works in case when networks are removed from dead agents14:42
slaweqand also e.g. for new networks14:42
slaweqat least that's how it looks like for me14:42
amotokirouter_auto_schedule is also used for initial scheduling just after a router is created, right?14:42
amotokihttps://github.com/openstack/neutron/blob/aff0a75ecb76e12f240b4ab00a8ecfc75776216b/neutron/api/rpc/handlers/l3_rpc.py#L10914:43
mlavalle2that's my understanding14:43
lajoskatonaI agree to improve the documentation14:44
mlavalle2seems like a good next step14:44
mlavalle2we really don't know how this is being used in the wild, but since we don't have many complaints, it is not probably wise to mess with it14:45
mlavalle2so let's improve documentation14:45
lajoskatonaok, then I add to the bug as comment that the cfg option name is good, but the doc can be improved14:45
slaweqIMO this is valid bug14:46
slaweqand we should check if that option is enabled e.g. in https://github.com/openstack/neutron/blob/430abde13ec58e611a8752ca579fee5110a0a61d/neutron/db/l3_agentschedulers_db.py#L48414:46
slaweqso it would probably work the same way like network_auto_schedule option for dhcp agents14:46
lajoskatonaas I see the first step anyway is to document to have it written how it behaves currently and act if there are complaints for that14:48
amotokithe router scheduler class have both auto_schedule_routers() and schedule(). I am not sure schedule() should work only when auto_schedule is enabled14:49
ralonsoh+114:49
mlavalle2yeah, let's make it clear to everybody in doc how it is intended to bahave14:49
slaweqlajoskatona I agree, we should check it to be sure, document how it works and then maybe change this behaviour a bit if that will be needed14:49
amotokianyway agree to imporve the doc14:49
ralonsohand yes, we should check amotoki's question14:49
lajoskatonaok, let's go this way then, improve the doc first14:51
mlavalle2+114:51
amotoki+114:51
ralonsoh+114:51
slaweq+114:51
haleyb+114:51
lajoskatona+114:51
obondarev+114:52
lajoskatonaok, thank you very much14:52
lajoskatonaIs there anything to discuss?14:52
slaweqnothing from me14:53
amotokinone from me14:53
mlavalle2not from me14:53
lajoskatona#endmeeting14:53
opendevmeetMeeting ended Fri May 27 14:53:56 2022 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)14:53
opendevmeetMinutes:        https://meetings.opendev.org/meetings/neutron_drivers/2022/neutron_drivers.2022-05-27-14.00.html14:53
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/neutron_drivers/2022/neutron_drivers.2022-05-27-14.00.txt14:53
opendevmeetLog:            https://meetings.opendev.org/meetings/neutron_drivers/2022/neutron_drivers.2022-05-27-14.00.log.html14:53
obondarevo/14:53
ralonsohhave a nice weekend!14:54
slaweqo/14:54
lajoskatonaHave a nice weekend, and see you next week :-)14:54
slaweqhave a nice weekend14:54
haleybo/14:54
amotokio/14:54
opendevreviewRodolfo Alonso proposed openstack/neutron stable/yoga: Remove session active check in "_add_segment_host_mapping_for_segment"  https://review.opendev.org/c/openstack/neutron/+/84362414:54
opendevreviewRodolfo Alonso proposed openstack/neutron stable/xena: Remove session active check in "_add_segment_host_mapping_for_segment"  https://review.opendev.org/c/openstack/neutron/+/84362614:58
opendevreviewRodolfo Alonso proposed openstack/neutron stable/wallaby: Remove session active check in "_add_segment_host_mapping_for_segment"  https://review.opendev.org/c/openstack/neutron/+/84362714:59
opendevreviewRodolfo Alonso proposed openstack/neutron master: Set "type=virtual" for OVN LSP with parent ports  https://review.opendev.org/c/openstack/neutron/+/84347415:02
opendevreviewFernando Royo proposed openstack/ovn-octavia-provider master: Fix way of calculate LB status after HM event  https://review.opendev.org/c/openstack/ovn-octavia-provider/+/84330815:12
opendevreviewMerged openstack/tap-as-a-service master: Code cleaning: make RPC method signatures more meaningful  https://review.opendev.org/c/openstack/tap-as-a-service/+/83343215:42
opendevreviewMerged openstack/tap-as-a-service master: py310: Add rpm packages to bindep.txt  https://review.opendev.org/c/openstack/tap-as-a-service/+/83488015:47
opendevreviewMerged openstack/tap-as-a-service master: test: Make py310 passing  https://review.opendev.org/c/openstack/tap-as-a-service/+/83492815:47
mnaserhi neutron team, could we have eyes on https://review.opendev.org/c/openstack/neutron-vpnaas/+/444186 ?15:48
mnaserit's a really nice change that will clean things up a lot and .. well overdue lol15:48
opendevreviewRodolfo Alonso proposed openstack/neutron master: [sqlalchemy-20] Add missing DB contexts in L3 methods  https://review.opendev.org/c/openstack/neutron/+/84246815:53
opendevreviewMerged openstack/neutron-fwaas master: Remove "distutils" library  https://review.opendev.org/c/openstack/neutron-fwaas/+/84237116:33
jamesbensonCan someone help with a networking question?  Why does launching an instance to the external subnet fail but on a private subnet local to the tenant pass, then allocate a public ip work?  What setting(s) need to change to make an instance able to launch off of the external network?16:46
opendevreviewGhanshyam proposed openstack/neutron-tempest-plugin master: Pin neutron-tempest-plugin for ussuri/victoria jobs  https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/83805318:29
opendevreviewMerged openstack/neutron master: Remove requirements.txt from irrelevant files in CI jobs  https://review.opendev.org/c/openstack/neutron/+/84359418:32
opendevreviewGhanshyam proposed openstack/os-vif master: Drop lower-constraints.txt and its testing  https://review.opendev.org/c/openstack/os-vif/+/84002018:54
opendevreviewMiguel Lavalle proposed openstack/neutron master: [WIP][DNM][OVN] Change the default firewall policy  https://review.opendev.org/c/openstack/neutron/+/83906622:52
*** jlibosva is now known as Guest54123:16

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!