Thursday, 2020-06-11

*** zhouhan_ has quit IRC00:39
*** zhouhan has joined #openvswitch00:41
*** anilvenkata has joined #openvswitch00:55
*** yamamoto has joined #openvswitch01:00
*** tbachman has quit IRC01:14
*** tbachman has joined #openvswitch01:15
*** ihrachys has quit IRC01:55
*** dholler has quit IRC02:10
*** acidfu has quit IRC02:24
*** dholler has joined #openvswitch02:24
*** acidfu has joined #openvswitch02:32
*** acidfu has quit IRC02:34
*** acidfu has joined #openvswitch02:36
*** acidfu has quit IRC02:50
*** acidfu has joined #openvswitch02:52
*** rcernin has quit IRC03:08
*** zhouhan_ has joined #openvswitch03:48
*** zhouhan has quit IRC03:49
*** zhouhan has joined #openvswitch03:50
*** ihrachys has joined #openvswitch03:51
*** zhouhan_ has quit IRC03:54
*** rcernin has joined #openvswitch03:55
*** rcernin has quit IRC03:55
*** rcernin has joined #openvswitch03:55
*** ihrachys has quit IRC03:56
*** links has joined #openvswitch04:50
*** acidfu has quit IRC04:50
*** acidfu has joined #openvswitch04:52
*** links has quit IRC05:12
*** acidfu has quit IRC05:20
*** links has joined #openvswitch05:21
*** acidfu has joined #openvswitch05:28
*** acidfu has quit IRC05:35
*** acidfu has joined #openvswitch05:35
*** acidfu has quit IRC05:50
*** acidfu has joined #openvswitch05:52
*** eelco has joined #openvswitch05:58
*** acidfu has quit IRC06:21
*** zhouhan_ has joined #openvswitch06:25
*** zhouhan has quit IRC06:25
*** blahdodo has quit IRC06:25
*** acidfu has joined #openvswitch06:29
*** blahdodo has joined #openvswitch06:29
*** acidfu has quit IRC06:51
*** acidfu has joined #openvswitch06:52
*** blahdodo has quit IRC06:54
*** blahdodo has joined #openvswitch06:55
*** blahdodo_ has joined #openvswitch06:58
*** blahdodo has quit IRC06:59
*** blahdodo_ has quit IRC07:02
*** blahdodo has joined #openvswitch07:03
*** dceara has quit IRC07:14
*** acidfu has quit IRC07:22
*** acidfu has joined #openvswitch07:26
*** dceara has joined #openvswitch07:43
*** factor has quit IRC07:46
*** factor has joined #openvswitch07:47
*** zhouhan_ has quit IRC07:55
*** zhouhan has joined #openvswitch07:56
*** rcernin has quit IRC08:00
*** yamamoto has quit IRC08:06
*** darkemon has quit IRC08:11
*** jaicaa has quit IRC08:13
*** darkemon has joined #openvswitch08:13
*** slaweq has quit IRC08:15
*** jaicaa has joined #openvswitch08:16
*** slaweq has joined #openvswitch08:20
*** yamamoto has joined #openvswitch08:23
*** acidfu has quit IRC08:25
*** yamamoto has quit IRC08:26
*** itandops has joined #openvswitch08:26
*** FH_thecat has quit IRC08:29
*** itandops has quit IRC08:29
*** FH_thecat has joined #openvswitch08:30
*** acidfu has joined #openvswitch08:33
*** yamamoto has joined #openvswitch08:36
*** yamamoto has quit IRC08:42
*** itandops has joined #openvswitch08:51
*** rcernin has joined #openvswitch08:56
*** mmirecki has joined #openvswitch09:05
*** factor has quit IRC09:16
*** factor has joined #openvswitch09:16
*** rcernin has quit IRC09:17
*** slaweq has quit IRC09:19
*** acidfu has quit IRC09:22
*** acidfu has joined #openvswitch09:35
*** acidfu has quit IRC09:36
*** ktraynor has quit IRC09:47
*** mmirecki has quit IRC09:49
*** acidfu has joined #openvswitch09:50
*** ktraynor has joined #openvswitch09:50
*** slaweq has joined #openvswitch09:58
*** yamamoto has joined #openvswitch09:59
*** yamamoto has quit IRC10:01
*** acidfu has quit IRC10:07
*** acidfu has joined #openvswitch10:11
*** inovas has joined #openvswitch10:16
*** slaweq has quit IRC10:20
*** acidfu has quit IRC10:23
*** acidfu has joined #openvswitch10:30
*** yamamoto has joined #openvswitch10:32
*** jraju__ has joined #openvswitch10:35
*** links has quit IRC10:36
*** acidfu has quit IRC10:37
*** yamamoto has quit IRC10:38
*** acidfu has joined #openvswitch10:50
*** acidfu has quit IRC10:51
*** acidfu has joined #openvswitch10:52
*** acidfoo has joined #openvswitch10:56
*** acidfu has quit IRC10:59
*** acidfoo has quit IRC11:07
*** acidfoo has joined #openvswitch11:11
*** acidfoo has quit IRC11:24
*** slaweq has joined #openvswitch11:24
*** acidfoo has joined #openvswitch11:31
*** yamamoto has joined #openvswitch11:35
*** yamamoto has quit IRC11:55
*** acidfoo has quit IRC12:08
*** acidfoo has joined #openvswitch12:12
*** slaweq has quit IRC12:13
*** acidfoo has quit IRC12:23
*** yamamoto has joined #openvswitch12:28
*** edsousa_ has quit IRC12:32
*** edwarnicke has quit IRC12:32
*** edwarnicke has joined #openvswitch12:33
*** edsousa_ has joined #openvswitch12:33
*** yamamoto has quit IRC12:33
*** yamamoto has joined #openvswitch12:34
*** itandops has quit IRC12:42
*** slaweq has joined #openvswitch12:43
*** slaweq has quit IRC12:47
*** bostondriver has joined #openvswitch12:48
*** yamamoto has quit IRC12:49
*** yamamoto has joined #openvswitch12:50
*** bostondriver1 has joined #openvswitch12:50
*** bostondriver1 has quit IRC12:50
*** bostondriver1 has joined #openvswitch12:50
*** bostondriver has quit IRC12:52
*** itandops has joined #openvswitch12:58
*** acidfoo has joined #openvswitch12:58
*** yamamoto has quit IRC13:00
*** inovas has quit IRC13:05
*** acidfoo has quit IRC13:08
*** acidfoo has joined #openvswitch13:13
*** dholler has quit IRC13:19
*** troulouliou_div2 has quit IRC13:21
*** acidfoo has quit IRC13:23
*** troulouliou_div2 has joined #openvswitch13:24
*** troulouliou_div2 has quit IRC13:31
*** troulouliou_div2 has joined #openvswitch13:31
*** dholler has joined #openvswitch13:32
*** yamamoto has joined #openvswitch13:36
*** acidfoo has joined #openvswitch13:36
*** troulouliou_div2 has quit IRC13:39
*** acidfoo has quit IRC13:41
*** yamamoto has quit IRC13:42
*** acidfoo has joined #openvswitch13:51
*** ihrachys has joined #openvswitch13:53
*** yamamoto has joined #openvswitch14:00
*** troulouliou_div2 has joined #openvswitch14:03
*** yamamoto has quit IRC14:05
*** thaller has quit IRC14:06
*** thaller has joined #openvswitch14:06
*** vkuramshin57 has joined #openvswitch14:08
*** vkuramshin57 has quit IRC14:19
*** dcbw has joined #openvswitch14:40
*** yamamoto has joined #openvswitch14:43
*** yamamoto has quit IRC14:48
*** troulouliou_div2 has quit IRC14:52
*** slaweq has joined #openvswitch14:52
*** factor has quit IRC14:52
*** jraju__ has quit IRC14:57
*** troulouliou_div2 has joined #openvswitch15:00
*** troulouliou_div2 has quit IRC15:00
*** troulouliou_div2 has joined #openvswitch15:00
*** apus has quit IRC15:13
*** itandops has quit IRC15:14
*** itandops has joined #openvswitch15:15
*** slaweq has quit IRC15:20
*** panda has quit IRC15:51
*** eelco has quit IRC15:53
*** panda has joined #openvswitch15:53
*** eelco has joined #openvswitch15:54
*** eelco has quit IRC15:57
*** dholler has quit IRC16:01
*** eelco has joined #openvswitch16:01
*** aconstan has quit IRC16:09
*** inovas has joined #openvswitch16:22
*** inovas has quit IRC16:23
*** eelco has quit IRC16:34
*** ktraynor has quit IRC17:06
*** aginwala has joined #openvswitch17:16
mmichelsonI'm going to start the meeting17:16
mmichelson#startmeeting ovn-community-development-discussion17:16
openstackMeeting started Thu Jun 11 17:16:35 2020 UTC and is due to finish in 60 minutes.  The chair is mmichelson. Information about MeetBot at http://wiki.debian.org/MeetBot.17:16
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.17:16
openstackThe meeting name has been set to 'ovn_community_development_discussion'17:16
pandao/17:16
*** blp has joined #openvswitch17:17
blpHi!17:17
numansHi17:17
dcearaHi17:18
mmichelsonhi everyone!17:18
flaviofhi all17:18
blpDo we need an #ovn channel or is everyone happy with using #openvswitch?17:18
mmichelsonblp, funny thing is I'm actually in a #ovn channel on freenode already17:18
blpOh. Should the meeting be there?17:18
zhouhanhello17:18
mmichelsonIt's not very heavily populated17:18
numansThe meeting bot is configured for #openvswitch I think.17:18
mmichelsonblp, I'm ambivalent on the matter. We're not interrupting conversations in here really17:19
blpOK.17:19
blpNo problem.17:19
blpAnyway, there's a discussion of OVN mailing lists going on in ovs-discuss.17:19
blphttps://mail.openvswitch.org/pipermail/ovs-discuss/2020-June/050221.html17:19
blpDid you #startmeeting?17:20
blpI have not.17:20
numansI think mmichelson did17:20
mmichelsonYes I did17:20
dcearablp, just a quick question about "closed" lists. The archives stay open and available to everyone regardless if they subscribed or not, right?17:20
blpYes. By "closed" I mean only "closed to posting by non-subscribers".17:20
blpNot "private".17:20
dcearablp, ack, thanks for confirming17:20
blpNumerous people have mentioned that and it took me by surprise because it never even occurred to me that we'd have private lists.17:21
blpI guess there's the "committers" and "security" lists but they're basically zero traffic.17:22
*** yamamoto has joined #openvswitch17:23
*** ChanServ sets mode: +o blp17:23
*** blp has quit IRC17:23
mmichelsonOK, so I guess since blp dropped that's a signal that someone else is free to give their update.17:24
*** blp has joined #openvswitch17:24
blpWeird, Pidgin hung and I had to restart it.17:24
*** ChanServ sets mode: +o blp17:24
mmichelsonblp, funny I had just said that since you had dropped someone else could give their update. But I'll re-yield the floor to you for now17:24
*** blp has quit IRC17:25
*** blp has joined #openvswitch17:25
blpOK I'm just not going to try to update the topic. It breaks Pidgin.17:25
blpAnyway, I was done anyway so I'll listen now.17:25
*** itandops has left #openvswitch17:27
mmichelsonOK cool17:28
mmichelsonI'll go real quick I suppose17:28
*** yamamoto has quit IRC17:28
mmichelsonI released OVN 20.06.0 earlier this week, and I've got an ACK to release 20.03.1. I'll release it before the end of the day17:28
mmichelsonI sent an email to ovs-announce but I think I'm not actually subscribed, so my email went to moderation.17:29
mmichelsonAnd aside from that, it's been a lot of catch-up on existing patches of mine that are out there and need updating. Also did some reviews of patches from Han and Anton17:29
mmichelsonThat's about all from me.17:29
flaviofMay I go next? I actually have more of a question on v20.06.0.17:30
numansmmichelson, I didn't see any email on ovs-announce17:30
numansand I don't see it in the archives too.17:31
numansflaviof, sure.17:31
numansmmichelson, can you please double check on that.17:31
numansAnd thanks for releasing 20.0617:31
flaviof++17:32
flaviofNot too long ago, we changed OVN to use OF1.5 so it can handle dp_hash selection for load_balancer.17:32
flaviof#link https://github.com/ovn-org/ovn/commit/6ec0b82038052866533f12823fe410308b3e457a [commit] controller: Use OpenFlow version 1.517:32
flaviof#link https://mail.openvswitch.org/pipermail/ovs-discuss/2020-April/049896.html [discuss] OVN Load balancing algorithm17:32
flaviofSo I think that we will have ovn-controller using OF1.5, starting on v20.06.0.17:32
numansmmichelson, oops. I didn't read your full message.17:32
numansflaviof, right.17:33
flaviofIn the upgrade path from v20.03.0 to v20.06.0 br-int may be already created and using OF1.3...17:33
flaviofDo you foresee special handling needed?  If so, would the proper thing to do is to have both OF1.3 and OF1.5 as supported versions?17:33
flaviofI'm assuming that the original code in the controller would only enable OF1.3. Please correct me if I'm wrong.17:33
flaviofWe can take this to discuss ML, of course, but I just wanted a general idea if any of you have already covered this.17:34
flaviofAnd that is all I have.17:34
mmichelsonflaviof, So a couple of things: First, I think that if ovn-controller is stopped and restarted, it will renegotiate the OF version with OVS.17:34
mmichelsonSecond, I'm pretty sure the documented update path involves restarting ovs-vswitchd, rather than updating OVN on top of a running OVS instance. I may be wrong about that, though.17:35
mmichelsonSomeone please correct me if I'm wrong on either of those two points17:36
numansflaviof, I know that devstack sets or was setting the protocol for the br-int in ovs db.17:36
numansif it doesn't set, I think it should work fine.17:36
numansor it should also set the protocol OF1.517:36
numansmmichelson, I think your first is correct. For the 2nd, I don't know.17:37
numansflaviof, I didn't find any issues in my testing. But I'll test it out again to be sure.17:37
flaviofAck. My question is on what happens if br-int exists and it is configured to use OF1.3... What would we expect to happen?17:37
numansflaviof, let me test out that scenario and come back to you on that.17:38
flaviofnumans++ TY17:38
numansI can go real quick next.17:38
numansif flaviof is done.17:39
zhouhanmmichelson: I didn't expect the point 2 either.17:39
* flaviof is done. except for saying TY to mmichelson too ;)17:39
numansI think for OVN, there is no need for CMS to set the protocol of the integration brdige17:39
numansAs ovn-controller never reads that and try to use that as OF flow version.17:40
numansI've been working on I-P patches this week addressing review comments.17:40
numansYesterday I applied first 3 patches of the series to master and branch-20.06 since I had 2 acks and a few rounds of reviews.17:41
numansSoon after dceara found 2 issues and fixed them. Thanks dceara for fixing and for the thorough reviews this week.17:41
numansI'm not sure if zhouhan had additional comments.17:41
numanszhouhan, If so, please let me know and I'll address them.17:41
dcearanumans, no problem, sorry for not spotting the issues earlier though17:41
numansdceara, no worries. I've never tested that scenario. I will test that now. And you added a test  case.17:42
numansthat's great.17:42
zhouhannumans: I will take a look for v1217:42
numansI submitted v12 of the series. I think there are in decent stage now.17:42
numanszhouhan, thanks.17:42
blpThe one thing that *might* turn up about OF1.5 is that it's much less tested than OF1.3.17:43
blpPerhaps we will turn up some bugs or points of  nonconformance. I hope not.17:43
numansHope not :)17:43
flaviof+117:43
numansI also worked on ovs idl patch which tries to return a valid txn object if it can. Thanks zhouhan for the reviews so far. I've addressed your comments17:43
numansand submitted v3.17:43
numansRequest to take a look - https://patchwork.ozlabs.org/project/openvswitch/patch/20200605083029.129633-1-numans@ovn.org/17:44
numansblp, not sure if you got some time for this patch. but if you can, that would be great.17:44
blpnumans: It's on my to-do list now.17:44
numansblp++17:44
numansthanks.17:44
numansI have a couple of smaller patches for review. Request to take a look17:44
numanshttps://patchwork.ozlabs.org/project/openvswitch/patch/20200601092742.550334-1-numans@ovn.org/17:44
numanshttps://patchwork.ozlabs.org/project/openvswitch/patch/20200430081000.751498-1-numans@ovn.org/17:44
numansAnd that17:44
numansthat17:45
zhouhannumans: sure, thx!17:45
numansthat's it from me.17:45
numansthanks.17:45
zhouhanI can go next17:45
zhouhanThanks imaximets for reviewing the dp_hash recirc fix17:45
blpOK, I added "es" to my "Review Numan's patch" to-do item.17:45
zhouhanimaximets: I replied your email. blp: please take a look as well, as requested by imaximets, too :)17:46
blpzhouhan: I missed the context. What should I look at?17:47
zhouhanimaximets: we can discuss offline, but the major point I wanted make is that the problem is caused only when there is a slowpath action required by the flow, so in that case I think always computing dp_hash in slowpath for the flow wouldn't have consistency issue.17:47
zhouhanblp: #link https://patchwork.ozlabs.org/project/openvswitch/patch/1589527067-91901-1-git-send-email-hzhou@ovn.org/17:48
zhouhanblp: this is dp_hash issue we have discussed in a previous meeting.17:48
zhouhanI also sent a RFC series for avoiding the flow explosion problem reported by ovn-k8s project.17:49
imaximetszhouhan, ok. I understand. Still looks a bit dangerous for me, need a fresh look from blp. :)17:49
zhouhanThanks mmichelson and numans for reviewing it. Sorry for missing some documentation in the RFC.17:50
zhouhanimaximets: ok, thx17:50
numanszhouhan, that's fine. I think you wanted Girish to test them first.17:50
zhouhannumans: yeah, I wanted to send out as early as possible so that they can try.17:50
zhouhanthat's it from me17:51
blpzhouhan: OK, will do.17:51
zhouhanblp: thx17:51
mmichelsonOK anyone else want to give an update?17:52
blpimaximets: Thanks so much for coming up with a simpler RCU fix.17:52
dcearaa oneliner from me this week: I started a thread on ovs-discuss about the current state of packet tracing in OVS/OVN. Feedback and suggestions are much appreciated: https://mail.openvswitch.org/pipermail/ovs-discuss/2020-June/050205.html17:52
dcearaThanks!17:52
numansdceara++ for working on this.17:53
imaximetsblp: no problem. Thanks for review.17:53
zhouhandceara: I saw it, that's wonderful17:53
aginwalathanks dceara ++ from my side too :)17:54
blpdceara: Is it worth discussing this here or would you prefer to keep it in email?17:54
blpIt's a big email so sometimes I find it exhausting to try to reply to every point at once, yet I feel bad if I only reply to one point in a long series.17:54
blpAnd so sometimes that results in me just ignoring things I should help with.17:55
dcearablp, i'm ok either way (ML or here)17:55
blpA discussion, however, could be helpful, if you're up for it here.17:55
dcearablp, sure17:55
blpLast point first: it should be possible to make the output format better.17:56
blpIIRC, ovn-trace has multiple output formats because it has a decent internal data structure that can be serialized multiple ways.17:56
blpofproto/trace used to be very primitive in that respect, but I think I redid it a few years ago to use a similar internal data structure.17:56
blpSo it might be possible to even just mostly copy code from ovn-trace into ofproto/trace to get a json output format.17:57
dcearablp, yes, I looked into it too a bit and it should be relatively straightforward indeed17:57
* numans also thinks that we can add --json option to most of the ovn (and ovs) utilities to output. That way ovn-kubernetes, ovn-scale-test etc can easily parse the output.17:58
blpSo, the other thing that occurs to me is that ovn-trace already knows how to talk to OVS instances, via the --ovs option.17:59
blpIt might be better to teach it to ofproto/trace than to create a new utility to do that.18:00
mmichelsonnumans, all DB operations have json as an option. I actually used it when adding support for unidling in ovn-kubernetes18:00
* numans is not happy with his ignorance.18:01
numansmmichelson, thanks. I haven't noticed that.18:01
mmichelsonThe json schema is...interesting, to say the least :)18:01
blpovn-trace, after all, already does a number of the operations listed in the description of ovn-global-trace.18:01
blpCurrently it doesn't know how to SSH or to connect to ovs-appctl, but it could learn; any other implementation would have to do that too.18:02
dcearablp, ok, that's possible too. I guess we'd drop the need for ovn-detrace then (for this use case at least).18:02
blpdceara: yes18:03
blpI think that the overall idea is a good one, it puts together a lot of the stuff that is now in bits and pieces.18:04
dcearablp, I agree that a single ovn-trace tool would be ideal.18:04
blpI think the shakiest part is probably the SSH interface. I guess popen("ssh...") would be the way to do that.18:04
flaviofblp: dceara: so would would think that using ssh is better than using geneve? I think it makes sense so data and ctrl are completely separate, right?18:06
numansI agree with single ovn-trace. But if ovn-global-trace is written in python then probably it will be easier to do ssh and other stuff18:06
dcearablp, would it be acceptable to have the connection to the node be externally setup somehow (e.g., socat a unix connection)?18:06
blpflaviof: We're talking about running ofproto/trace. That has to happen over SSH because OVS only listens on a unix domain socket for that kind of request.18:06
flaviofblp: ack!18:07
blpdceara: I don't want to prescribe anything, I was just assuming SSH was the best way.18:08
*** factor has joined #openvswitch18:08
imaximetsblp: theoretically we could allow appctl over ssl.18:08
* imaximets hides18:08
dcearaimaximets, :)18:08
blpimaximets: I think you can do that today if you specify --unixctl to a pssl: socket, but I think we only support a single such socket so you'd lose the unix domain socket support if you did that.18:10
blpIt looks like the discussion here is slowing down, please @ me if you want me.18:11
zhouhandceara: you mentioned recirculation. I think that's also important for the debugging tool to be useful. It includes not only conntrack, but also dp_hash :)18:11
zhouhannot sure if there is a better idea other than passing an hint18:12
imaximetsblp: it should be possible with a little magic to specify --unixctl pssl:<>,unix:<>.  But anyway, I don't think it's a way good way for production deployment.18:12
blpimaximets: +118:13
dcearablp, popen is fine I guess, we probably need to be a bit flexible and allow the protocol to be controlled by the user though. The node running OVS might not be running an ssh server.18:13
dcearazhouhan, good point, we should find a solution for dp_hash too. However with dp_hash I think hints are ok. The chances that you choose a "wrong" bucket are quite small. I would expect all buckets to produce the same behavior in a sane deployment.18:14
* numans waves and says goodbye to everyone.18:15
pandanumans: bye, and thanks for the reviews18:15
zhouhandceara: but if we are talking about the global tracing, a wrong bucket would lead to tracing on a wrong remote (at least in the case of ECMP)18:15
* zhouhan waves bye to numan18:16
dcearanumans, bye!18:16
dcearazhouhan, great point I didn't think of that. Do you have any other suggestions except hints?18:16
blpdceara: I think that an option or environment variable to specify the program to invoke would be suitable.18:16
dcearablp, ack18:17
zhouhandceara: not yet, just brainstorming the problems :)18:17
dcearazhouhan, ack :)18:17
blpdceara: although for awful programs I sometimes end up doing PATH=/path/to/my/special/binary:$PATH to override their program choices, I don't like it ;-)18:18
dcearablp, what about the conntrack related part?18:18
*** Franky_T has joined #openvswitch18:19
blpdceara: Chasing the link, is the main point here that your patch hasn't been applied? Or is there something deeper?18:19
dcearablp, I have the impression that providing hints for conntrack (and dp_hash) would make the tool quite user "unfriendly"18:19
dcearablp, that patch addresses a small part of the problem18:19
dcearablp, that's why I didn't push for it too much. It only improves the case when we hit a ct(nat(src/dst=...))18:20
blpdceara: conntrack might be hard, but maybe it depends on what assumptions we can make in the common case.18:20
blpdceara: In the common case, are we tracking down a problem where a packet is getting dropped? If so, then conntrack is a big ??? since it might be the thing doing the drop.18:20
dcearablp, maybe adding support to conntrack for "what would happen to a packet like this?" is an alternative18:21
*** jaicaa_ has joined #openvswitch18:22
dcearablp, To answer your question: I think yes, most of the times we'll be tracking down why a packet is dropped.18:22
*** jaicaa has quit IRC18:22
dcearablp, But it might be that we need to track why packets are forwarded to the wrong port (for example).18:23
blpSo, ovn-trace and ofproto/trace mostly play "what-if" games. This is fine as far as it goes.18:23
blpWe might need something else though.18:23
blpWe might need something where we can inject a real packet and then attempt to actually track where it really goes in the system.18:24
blpNVP/NSX offer this feature to admins. I believe it gets used regularly.18:24
mmichelsonThat would be a super-useful thing, I think.18:25
blpOr, alternatively, a feature where we can "put a trace" on packets that match a particular specification.18:25
blp"All my UDP to a.b.c.d is getting dropped, what's happening?"18:25
blp"Where's my DNS going?"18:25
blpetc.18:25
blpThere's already a way to log ACL matches, I think, this would be more advanced.18:25
dcearablp, If the packet hits a datapath flow it might be quite hard to determine the oflow that created it and subsequently the OVN records that inserted it.18:26
blpAll the information to trace that back is there.18:26
dcearablp, hmm, OK, I had the impression that we have a many-to-one relationship from oflow to dp-flow18:27
dcearablp, I'll look more into that.18:27
blpIt's not always efficient to look it up.18:28
blpIt might be worth starting from the viewpoint, "What's the ideal debugging tool that I want to use in deployments?" and then see how close it can be approximated.18:28
dcearablp, ack18:29
blpI've always assumed we'd need a way to track real packets for debugging but I was curious how far we could take the ovn-trace model. Pretty far, it seems.18:30
dcearablp, thanks for all the pointers. I'll take a step back and have a look at this from the other perspective too. It might turn up to be more useful and easier to implement in the end :)18:30
zhouhanblp: we definitely need to track real packets, usually as a start in the debugging process. With OVN ECMP used, it is even not easy to tell which remote did the packet go. And ovs-dpctl dump-flows can't tell that in many cases.18:32
zhouhantcpdump used to help much, but with tunnel (especially, STT), this step is even troublesome18:33
zhouhan(geneve has better support by linux, so it is more straightforward)18:34
zhouhandceara: It sounds like a big project, but I hope it can be started small and progesses made incrementally :)18:34
mmichelsonI think this is a good time to end the meeting. If people still want to talk, feel free to continue here or through e-mail18:36
mmichelson#endmeeting18:36
dcearazhouhan, blp, I guess we need to decide on a direction first. I'll think more about the tracking of real packets though and start a discussion about that alternative on the ML18:36
openstackMeeting ended Thu Jun 11 18:36:04 2020 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)18:36
openstackMinutes:        http://eavesdrop.openstack.org/meetings/ovn_community_development_discussion/2020/ovn_community_development_discussion.2020-06-11-17.16.html18:36
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/ovn_community_development_discussion/2020/ovn_community_development_discussion.2020-06-11-17.16.txt18:36
openstackLog:            http://eavesdrop.openstack.org/meetings/ovn_community_development_discussion/2020/ovn_community_development_discussion.2020-06-11-17.16.log.html18:36
flaviofbye all18:36
zhouhanbye all18:36
imaximetsbye18:37
dcearabye18:37
*** bostondriver1 has quit IRC18:39
*** bostondriver has joined #openvswitch18:39
*** thaller has quit IRC18:47
*** thaller has joined #openvswitch18:48
*** aginwala has quit IRC18:56
*** dceara has quit IRC18:59
*** Franky_T has quit IRC19:01
*** dceara has joined #openvswitch19:06
*** inovas has joined #openvswitch19:13
dcearablp, If you're still here, if we'd be able to mark a packet for "tracking" do you think forcing an upcall for such packets for every ovs action and after recirculation would be an option?19:13
blpdceara: Depending on the details, that might be reasonable.19:24
dcearablp, cool, I'll start digging more into this then. Thanks again for the guidance :)19:24
blpdceara: I would worry about it if there was a risk of ending up doing that to every packet that passes through the switch. If it would only happen to specially marked (e.g.) packets, it's reasonable.19:24
dcearablp, definitely only for specific packets19:25
*** zhouhan_ has joined #openvswitch19:30
*** zhouhan has quit IRC19:34
*** slaweq has joined #openvswitch19:49
*** dceara has quit IRC20:15
*** slaweq has quit IRC20:26
*** yamamoto has joined #openvswitch21:26
*** yamamoto has quit IRC21:32
*** troulouliou_div2 has quit IRC21:33
*** bostondriver has quit IRC21:35
*** acidfoo has quit IRC21:36
*** acidfoo has joined #openvswitch21:37
*** dcbw has quit IRC21:37
*** JamesBenson has quit IRC21:38
*** acidfoo has quit IRC21:45
*** acidfoo has joined #openvswitch21:47
*** rcernin has joined #openvswitch21:49
*** blp has quit IRC22:01
*** dceara has joined #openvswitch22:06
*** rebrec has quit IRC22:14
*** yamamoto has joined #openvswitch23:03
*** dceara has quit IRC23:09
*** rcernin has quit IRC23:48
*** rcernin has joined #openvswitch23:51
*** yamamoto has quit IRC23:53
*** acidfu_ has joined #openvswitch23:58
*** acidfoo has quit IRC23:58

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