*** ari98 has joined #openvswitch | 01:18 | |
*** thaller has quit IRC | 02:01 | |
*** thaller has joined #openvswitch | 02:02 | |
*** dholler has quit IRC | 02:25 | |
*** acidfu has quit IRC | 02:30 | |
*** larsks has quit IRC | 02:36 | |
*** dholler has joined #openvswitch | 02:38 | |
*** larsks has joined #openvswitch | 02:50 | |
*** rcernin has quit IRC | 02:52 | |
*** rcernin has joined #openvswitch | 02:57 | |
*** larsks has quit IRC | 02:59 | |
*** larsks has joined #openvswitch | 03:02 | |
*** larsks has quit IRC | 03:05 | |
*** larsks has joined #openvswitch | 03:08 | |
*** larsks has quit IRC | 03:09 | |
*** larsks has joined #openvswitch | 03:12 | |
*** links has joined #openvswitch | 03:37 | |
*** kobis1 has joined #openvswitch | 04:47 | |
*** kobis1 has quit IRC | 04:47 | |
*** blahdodo has quit IRC | 06:08 | |
*** tbachman has quit IRC | 06:10 | |
*** blahdodo has joined #openvswitch | 06:12 | |
*** tbachman has joined #openvswitch | 06:15 | |
*** slaweq has joined #openvswitch | 06:21 | |
*** slaweq has quit IRC | 06:44 | |
*** slaweq has joined #openvswitch | 06:46 | |
*** ralonsoh has joined #openvswitch | 07:05 | |
*** jraju__ has joined #openvswitch | 07:22 | |
*** links has quit IRC | 07:22 | |
*** dceara has joined #openvswitch | 07:37 | |
*** rcernin has quit IRC | 07:42 | |
*** imaximets has quit IRC | 07:48 | |
*** imaximets has joined #openvswitch | 07:48 | |
*** rebrec has quit IRC | 07:49 | |
*** rebrec has joined #openvswitch | 07:50 | |
*** elvira has joined #openvswitch | 07:57 | |
*** rcernin has joined #openvswitch | 08:01 | |
*** rcernin has quit IRC | 08:12 | |
*** jraju__ has quit IRC | 08:26 | |
*** zhouhan_ has quit IRC | 08:32 | |
*** zhouhan has joined #openvswitch | 08:33 | |
*** labelette has joined #openvswitch | 08:39 | |
*** labelette has quit IRC | 08:41 | |
*** labelette has joined #openvswitch | 08:42 | |
*** labelette has quit IRC | 08:43 | |
*** labelette has joined #openvswitch | 08:43 | |
*** labelette has quit IRC | 08:45 | |
*** labelette has joined #openvswitch | 08:45 | |
*** labelette has quit IRC | 08:46 | |
*** labelette has joined #openvswitch | 08:47 | |
*** labelette is now known as blt | 08:48 | |
*** blt has quit IRC | 08:54 | |
*** lablt has joined #openvswitch | 08:55 | |
*** jaicaa has quit IRC | 09:22 | |
*** jaicaa has joined #openvswitch | 09:23 | |
*** jraju__ has joined #openvswitch | 10:18 | |
*** jraju__ has quit IRC | 10:19 | |
*** cpaelzer has quit IRC | 10:56 | |
*** acidfu has joined #openvswitch | 10:57 | |
*** tbachman has quit IRC | 11:04 | |
*** cpaelzer__ has joined #openvswitch | 11:51 | |
*** thaller has quit IRC | 12:02 | |
*** thaller has joined #openvswitch | 12:02 | |
*** bostondriver has joined #openvswitch | 12:10 | |
*** tbachman has joined #openvswitch | 12:39 | |
*** donhw has quit IRC | 13:27 | |
*** donhw has joined #openvswitch | 13:28 | |
*** thaller has quit IRC | 13:52 | |
*** thaller has joined #openvswitch | 13:57 | |
*** thaller has quit IRC | 13:59 | |
*** thaller has joined #openvswitch | 14:00 | |
*** Kamilion has quit IRC | 14:07 | |
*** dcbw has joined #openvswitch | 14:27 | |
*** Kamilion has joined #openvswitch | 14:27 | |
*** tbachman_ has joined #openvswitch | 14:33 | |
*** tbachman has quit IRC | 14:35 | |
*** tbachman_ is now known as tbachman | 14:35 | |
*** acidfu has quit IRC | 14:36 | |
*** acidfu has joined #openvswitch | 14:41 | |
*** acidfu has quit IRC | 14:46 | |
*** tbachman_ has joined #openvswitch | 15:10 | |
*** tbachman has quit IRC | 15:11 | |
*** tbachman_ is now known as tbachman | 15:11 | |
*** |subz3r0| has quit IRC | 15:12 | |
*** |subz3r0| has joined #openvswitch | 15:14 | |
*** |subz3r0| has joined #openvswitch | 15:14 | |
*** acidfu has joined #openvswitch | 15:19 | |
*** gregwork has joined #openvswitch | 15:26 | |
*** |subz3r0| has quit IRC | 15:42 | |
*** |subz3r0| has joined #openvswitch | 15:43 | |
*** zhouhan_ has joined #openvswitch | 16:03 | |
*** zhouhan has quit IRC | 16:07 | |
gregwork | is pvlan in ovs a thing ? | 16:10 |
---|---|---|
*** donhw has quit IRC | 16:16 | |
*** donhw has joined #openvswitch | 16:19 | |
*** ralonsoh has quit IRC | 17:08 | |
*** _mdgray_ has joined #openvswitch | 17:08 | |
*** mmichelson_ has quit IRC | 17:14 | |
*** mmichelson has joined #openvswitch | 17:14 | |
mmichelson | Hi everyone | 17:15 |
mmichelson | I'm going to go ahead and start the meeting | 17:15 |
dceara | Hi | 17:16 |
mmichelson | #startmeeting ovn_community_development_discussion | 17:16 |
openstack | Meeting started Thu Oct 22 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 |
openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 17:16 |
openstack | The meeting name has been set to 'ovn_community_development_discussion' | 17:16 |
numans | Hello | 17:17 |
mmichelson | As a quick note at the beginning, we're coming up on that awkward time of year where the clocks start getting set back. Europe sets their clocks back an hour this weekend. North America waits one more week before doing it. And I'm not sure about the rest of the world. | 17:17 |
*** blp has joined #openvswitch | 17:18 | |
mmichelson | The email that goes out should take that into account when announcing the meeting for next week. | 17:18 |
blp | I made it! | 17:18 |
mmichelson | blp, hi! | 17:18 |
numans | blp, hI | 17:18 |
imaximets | hi | 17:18 |
numans | sorry my caps were on :) | 17:18 |
mmichelson | Anyway, with time change stuff out of the way, we can get this thing started. | 17:19 |
*** _mdgray_ has quit IRC | 17:19 | |
mmichelson | Biggest things to report are that I'm giving Anton's newest patches a review and I'm reworking the unit test patch series based on Ilya's feedback | 17:19 |
_lore_ | hi all | 17:19 |
*** mdgray has joined #openvswitch | 17:19 | |
mmichelson | And that's all I have to report. I also plan to review Numan's loopback optimization patches sometime real soon | 17:19 |
numans | I can go real quick next | 17:22 |
numans | I worked on the load balancer hairpin lflow improvement patches and submitted for review yesterday | 17:22 |
numans | thanks mmichelson for planning to take a look | 17:22 |
numans | I did some code reviews today. | 17:23 |
numans | one of the OVS patch broke the OVN compilation. I submitted a patch for that - https://patchwork.ozlabs.org/project/ovn/patch/20201022155339.300989-1-numans@ovn.org/ | 17:23 |
blp | I have a brief report when there's an opportunity. | 17:24 |
numans | I think we need to discuss about this on how to fix it in OVN. | 17:24 |
numans | That's it from myside. | 17:24 |
numans | blp, go ahead. | 17:24 |
imaximets | numans, IMHO, we need to support building OVS with all supported versions of OVS. at least starting from 2.13 if possible. | 17:24 |
blp | Two things. | 17:25 |
mmichelson | imaximets, agreed | 17:25 |
blp | First, we got 20 submissions for ovscon (not 17 as I originally thought). I think we're on track to announce the accepted talks by the end of the month. | 17:25 |
blp | Second, I'm starting to push ddlog patches toward OVN. It's a lot of patches, so I'm doing them in batches. I sent out the first batch last night. They should be easy to review because they are only documentation improvements. | 17:26 |
blp | The documentation improvements relate to the current state of OVN. They are not ddlog specific. | 17:26 |
*** donhw has quit IRC | 17:27 | |
blp | I'd appreciate it if people could take a look at them and pass along their feedback. Once those are in, I'll prepare and send the next batch, which will actually include some code changes. | 17:27 |
mmichelson | blp, numan acked the doc patches and I pushed them to master earlier today | 17:28 |
*** donhw has joined #openvswitch | 17:28 | |
mmichelson | blp, so we at least got that part done :) | 17:28 |
blp | oh! That was fast. | 17:28 |
blp | I'll prepare the second batch today then. Honestly I was expecting it to take longer. | 17:28 |
blp | But it's fantastic that it was quick. | 17:28 |
blp | That's all from me. | 17:28 |
mmichelson | Doc patches are pretty easy to review :) | 17:28 |
blp | Well, if they're correct, anyhow. I hope that was reviewed :-) | 17:29 |
blp | Some of these were me figuring things out from code and commit messages, and who knows whether I misunderstood something. | 17:29 |
mmichelson | blp, it all looked correct to me | 17:29 |
blp | yay! | 17:29 |
imaximets | blp, now it's documented and we'll change the code to correspond. :D | 17:30 |
numans | blp, shall we hold on merging any patches to OVN mainly the ones which change ovn-northd ? until your ddlog patches are reviewed and merged ? | 17:31 |
blp | numans: If you can afford to do that, it would be great! | 17:32 |
numans | I'm fine with it | 17:32 |
blp | I've been struggling to keep up. | 17:32 |
numans | others, does that sounds reasonable ? | 17:32 |
numans | blp, I understand. with many changes, you have to rework again. And that could be frustrating. | 17:33 |
*** zhouhan_ has quit IRC | 17:34 | |
blp | Someone else wants to speak? | 17:34 |
*** zhouhan has joined #openvswitch | 17:34 | |
imaximets | I have a small update. | 17:35 |
zhouhan | numans: maybe holding on new features, but allowing bug fixes. | 17:35 |
blp | zhouhan: +1 on that | 17:35 |
zhouhan | imaximets: sorry, please go ahead | 17:35 |
imaximets | I'm swamped into memory consumption issues of ovsdb-server. Technically, one thing that bothers the most is that ovsdb-server doesn't free memory back to system if we're cleaning up the database. | 17:36 |
blp | imaximets: You mean ovsdb-server calls free() but that doesn't return memory to the kernel? | 17:37 |
imaximets | It seems like reusing most of this memory later if we're performing same tests, ubt not always. | 17:37 |
blp | (That's a very old C FAQ.) | 17:37 |
imaximets | blp, no, it seems like not calling free() on some memory. | 17:37 |
blp | imaximets: Oh! That's more of an issue. | 17:37 |
imaximets | but I'm not sure right now. | 17:37 |
imaximets | blp, right now I have an instance of ovsdb-server that consumes 13GB with empty database. | 17:38 |
blp | I think ovsdb-server has some features for memory statistics. | 17:38 |
blp | At least, ovs-vswitchd does, I don't recall whether we put the same thing into ovsdb-server. | 17:38 |
blp | 13GB! | 17:38 |
blp | wow | 17:38 |
imaximets | blp, these are not enough. I'm extending them. | 17:38 |
blp | great! | 17:38 |
imaximets | blp, I suppose, these are raft or ovsdb transaction logs. | 17:39 |
blp | Probably. The raft transaction log stays in memory until it gets snapshotted. You could force a snapshot and see what happens. | 17:39 |
imaximets | blp, I did. Does not help. So, I'm digging different places and trying to get more statistics right now. | 17:40 |
blp | The C heap is so opaque. | 17:41 |
imaximets | the test is to create one port group and add few thousands of acls one by one. This generates huge trafic since each transaction is a few hundreds of kilobytes. | 17:41 |
imaximets | investigating. | 17:42 |
zhouhan | imaximets: does 13GB reflect the peak usage (data or raft log) in your test? If you start new tests with the empty DB does it increase before the data/log size get large enough? | 17:42 |
imaximets | zhouhan, memory consumption continuously grows while adding new acls to port group and stays at the peak forever. Even after removin all acls and the port group. and after db compaction. | 17:43 |
zhouhan | imaximets: yes, but the 13GB doesn't grow until you have enough new data that exceeds the previous peak, right? | 17:44 |
imaximets | zhouhan, it depends. I'm not sure. In most cases it doesn't grow if I'm starting the test again. But there are cases where it grows higher. | 17:45 |
zhouhan | ok. thanks! I am trying to understand is it something like memory leak which is critical for production, or just something to be optimized, but it seems not quite clear yet. Will see what you find later. | 17:46 |
imaximets | I'll continue my investigation and will send something on a mail list, likely. | 17:46 |
zhouhan | thanks imaximets | 17:47 |
imaximets | And I'll be on PTO next week. :) | 17:47 |
imaximets | That's it form me. | 17:47 |
zhouhan | imaximets: no worries, we still have enough memory | 17:47 |
zhouhan | (I've nothing to report except some reviews) | 17:48 |
numans | zhouhan, sounds good to me accept just bug fixes. | 17:49 |
*** blp has left #openvswitch | 17:49 | |
*** blp has joined #openvswitch | 17:49 | |
blp | Anyone else? | 17:50 |
imaximets | maybe one more thing | 17:50 |
imaximets | The issue that OVN depends on non-exported sources of OVS that leads to OVN build failures. | 17:51 |
imaximets | i.e. non-public OVS parts. | 17:51 |
blp | Yes, that's nasty. | 17:51 |
blp | There are multiple possible solutions. All of them require work. | 17:52 |
imaximets | I just think tht we need a policy for this kind of things, to not discuss each time | 17:52 |
numans | right now OVN compilation is broken after this commit - 91fc374a9c5a("Eliminate use of term "slave" in bond, LACP, and bundle contexts.") in OVS | 17:53 |
imaximets | mmichelson seems to agree that we need to support OVN build with all stable OVS versions starting from 2.13, if possible. | 17:53 |
numans | mmichelson During the split we did discuss about this right ? | 17:54 |
numans | there are two things, one is run time compatibility and other compilation. | 17:54 |
numans | I'm not sure if we want to support compilation of OVN with older versions of OVS as it could be hard to maintain that | 17:55 |
imaximets | But this is hard to handle, because OVN releases are more frequent. | 17:56 |
numans | I think if some one is compiling OVN from master, he/she can pick up the latest OVS. | 17:56 |
numans | just for compilation. | 17:56 |
blp | OVN shouldn't use non-public bits of OVS. Either OVS should export the bits it needs, or OVN should copy-paste the bits it uses, I think. | 17:56 |
mmichelson | numans, imaximets Thinking about it again, the most important thing is for OVN to be able to run against older 2.13 and newer versions of OVS. When it comes to compilation, it's not nearly as important to be compatible with older versions | 17:56 |
numans | mmichelson, that's what I think too. | 17:57 |
imaximets | mmichelson, but building with unstable OVS sources doesn't seem like a good idea. | 17:57 |
imaximets | or we need to say that OVN builds with latest stable release and not support building with master. | 17:58 |
imaximets | * latest stabel OVS release | 17:58 |
mmichelson | imaximets, But then we run into the issue that may happen where a change we make in OVN requires an OVS change as well. I guess we can go with Anton's method for handling that right now. | 17:59 |
mmichelson | At least that will work for new functionality. | 17:59 |
blp | OK, I'm switching to a different meeting now. Thanks so much for the reviews, especially! I'll post another series later today. | 18:00 |
mmichelson | If you're not sure what I mean, I can link Anton's paralellization patch. Just a sec. | 18:00 |
numans | I think for compilation we should not complicate things or add #ifdef code which checks the ovs version and compile conditionally. | 18:00 |
imaximets | mmichelson, numans: is conditional compilation that bad? | 18:00 |
numans | blp, Bye | 18:00 |
mmichelson | See the bottom of: https://patchwork.ozlabs.org/project/ovn/patch/20201014162714.5978-1-anton.ivanov@cambridgegreys.com/ | 18:00 |
*** blp has left #openvswitch | 18:00 | |
numans | imaximets, I think in a long run it would complicate the code. | 18:01 |
zhouhan | In fact it seems even runtime compatibility is tricky. In redhat it may be fine but for ubuntu since deb package uses dynamic .so libs, would this be concerned? | 18:01 |
mmichelson | Yes that can be a problem. | 18:02 |
numans | I think if some one wants to compile OVN from sources, he/she can definitely pull up latest OVS sources too. | 18:03 |
numans | for production anyway, a user is expected to consume OVN from distributions. | 18:03 |
numans | and stable versions of OVN. | 18:03 |
mmichelson | Correct. We just need to ensure that we don't break debian packages. | 18:04 |
imaximets | numans, how can I find out which version of OVS is compatible with specific OVN commit? | 18:04 |
numans | In the case of fedora which I maintain, if compilation breaks due to OVS, I usually sync to the latest OVS or backport such patches. | 18:05 |
zhouhan | Now that we release OVN more frequently than OVS, does it mean the mid-cycle release of OVN is regarded unstable (because it may depend on unreleased OVS?) | 18:05 |
numans | imaximets, we discussed that during split. During a release, OVN would mention the commit of OVS. | 18:05 |
imaximets | numans, so how can I bisect issues if my OVN bisect will always require different versions of OVS and I do not even know which exactly? | 18:06 |
numans | imaximets, you mean for production deployments ? | 18:06 |
imaximets | numans, doesn't matter. | 18:06 |
numans | imaximets, when you compile OVN, you need to provide the OVS sources right ? | 18:07 |
numans | as a developer if you're compiling OVN, you would probably know which OVS version of code base is used for compilation. | 18:07 |
zhouhan | imaximets: I guess now bisect means both OVN and OVS (it is not a bisect anymore). That's the case when I debugged the northd performance regression caused by an OVSDB IDL change. | 18:08 |
imaximets | numans, right. Assuming I have a bug and I'm truing to identify the commit that introduced it. I'm using git bisect, but I can not automate it and I need to find out correct OVS commit to build with each time. | 18:08 |
imaximets | zhouhan, at least you were able to use OVS master with all your OVN versions higher that 2.12. | 18:09 |
numans | imaximets, I don't think we will have a straightforward answer until we either use a openvswitch lib or copy the ovs bits to OVN | 18:09 |
mmichelson | We've been doing the separate OVN builds for nearly a year now. I think the war stories you have imaximets can factor into how we manage the project going forward | 18:09 |
numans | as suggested by Ben | 18:09 |
mmichelson | It may be that we need to pin our builds to a specific version of OVS, in order to stabilize things and make debugging easier. | 18:10 |
mmichelson | numans, which OVS bits would we copy to OVN? | 18:10 |
numans | imaximets, in the case of RHEL and fedora we would be knowing which OVS version/tar ball is used. | 18:10 |
numans | mmichelson, this is what Ben said a while back - <blp> OVN shouldn't use non-public bits of OVS. Either OVS should export the bits it needs, or OVN should copy-paste the bits it uses, I think. | 18:11 |
mmichelson | numans, OK, it probably makes sense to make the "non-public" pieces public then. In my view, there's no much reason why hmap is public but smap is not. | 18:11 |
mmichelson | As an example | 18:11 |
mmichelson | Assuming that "public" refers to headers in include/ and "non-public" refers to headers in lib/ | 18:12 |
numans | mmichelson, we also use lib/packets.h too. | 18:13 |
numans | all that needs to be moved to include/ of ovs. | 18:13 |
imaximets | numans, mmichelson: making things public will require versioning anyway and OVN will have to detect version of OVS public libraries. | 18:13 |
imaximets | and stick to specific versions or support multiple with conditional compilation. | 18:15 |
zhouhan | Or, if OVN depends on a new feature of OVS which is not released, we could create a branch for the stable OVS release and backport the new features to the stable OVS branch. This way we can avoid using unstable OVS as much as possible. | 18:15 |
mmichelson | imaximets, I agree that making things public still requires versioning. You have to crawl before you can walk or run, though. So step one would be to make the library we need to consume. Step 2 would be to version this API. | 18:16 |
numans | The big question is how we want to handle the compilation issue now ? I submitted a patch here - https://patchwork.ozlabs.org/project/ovn/patch/20201022155339.300989-1-numans@ovn.org/ | 18:16 |
numans | if we accept the submitted patch, then we release ovn 20.12 we need to consume OVS from unstable branch for "compilation". | 18:17 |
mmichelson | numans, the current attitude with OVN is to do exactly what you did. Compile against the latest OVS, even if it's unstable. | 18:17 |
mmichelson | numans, but going forward, we probably need to come up with a more structured way of doing things for our own sanity | 18:17 |
imaximets | numans, mmichelson, zhouhan: what about git submodule? Was this option discussed during the split? | 18:17 |
imaximets | I mean submodules are fixed to specific commit hash. | 18:18 |
*** elvira has quit IRC | 18:18 | |
zhouhan | imaximets: that was discussed, but I remember it was dropped because of other drawbacks | 18:19 |
zhouhan | maybe mmichelson numans remember more details | 18:20 |
numans | And the agreement at that time was to compile OVN master from OVS master and when OVN is released we document the OVS commit to use to. | 18:20 |
numans | I think until now we didn't face a compilation issue so far in which released OVN depends on OVS master. | 18:21 |
imaximets | submodules are not pretty, but it's less evil if we're sticking to OVS master for compilation anyway. At least we will know against which version we're building exactly. | 18:21 |
numans | or unreleased OVS | 18:21 |
zhouhan | imaximets: Would OVS stable branch with backporting work? It solves the compile problem (and also the debian runtime problem, probably), but has lower risk than using OVS master | 18:22 |
mmichelson | yeah we went the submodule way (actually I think we used subtree, but it's very similar) as a test, but ended up not going that way because it took us away from the long-term goal of being able to just install an ovs-devel package on the system and compile against that. | 18:22 |
numans | I think its better if we work towards having a ovs-devel package and then OVN using it for compilation. | 18:24 |
numans | I got to sign off now. | 18:25 |
numans | Bye | 18:25 |
mmichelson | OK | 18:25 |
mmichelson | I think we can continue this discussion over email. For the record, I like zhouhan's idea of having a clone of a stable OVS branch that we can backport fixes/necessary features to. | 18:26 |
mmichelson | Including that branch as a submodule or otherwise requiring it for compilation would be the next step | 18:26 |
numans | mmichelson, may be we can also think of cloning ovs repo in the ovn-org git and use it for compilation. | 18:27 |
numans | Just a thought. | 18:27 |
mmichelson | numans, yeah that's a good place for the backport to live | 18:27 |
zhouhan | yes | 18:27 |
zhouhan | We can continue discussing in ML | 18:27 |
numans | sounds good. | 18:28 |
numans | Bye | 18:28 |
zhouhan | I need to drop, too. Bye folks | 18:28 |
mmichelson | We've gone pretty long today for this meeting, so I'm going to end it. | 18:28 |
mmichelson | #endmeeting | 18:28 |
openstack | Meeting ended Thu Oct 22 18:28:14 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 18:28 |
openstack | Minutes: http://eavesdrop.openstack.org/meetings/ovn_community_development_discussion/2020/ovn_community_development_discussion.2020-10-22-17.16.html | 18:28 |
openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/ovn_community_development_discussion/2020/ovn_community_development_discussion.2020-10-22-17.16.txt | 18:28 |
openstack | Log: http://eavesdrop.openstack.org/meetings/ovn_community_development_discussion/2020/ovn_community_development_discussion.2020-10-22-17.16.log.html | 18:28 |
imaximets | OK. Bye. | 18:28 |
mmichelson | OK, now for the moment of truth. Does my python script that sends the email meeting know about the Europe time change this weekend... | 18:28 |
mmichelson | Success! | 18:28 |
mmichelson | Writing a time library has got to be a giant PITA | 18:29 |
*** mdgray has quit IRC | 18:47 | |
*** dceara has quit IRC | 19:22 | |
*** cpaelzer__ has quit IRC | 20:07 | |
*** cpaelzer__ has joined #openvswitch | 20:08 | |
*** slaweq has quit IRC | 20:26 | |
*** dceara has joined #openvswitch | 20:57 | |
*** slaweq has joined #openvswitch | 21:08 | |
*** bostondriver has quit IRC | 21:21 | |
*** dcbw has quit IRC | 21:23 | |
*** mutin-s has quit IRC | 21:25 | |
*** mutin-s has joined #openvswitch | 21:26 | |
*** mutin-s has quit IRC | 21:26 | |
*** slaweq has quit IRC | 21:27 | |
*** dceara has quit IRC | 21:39 | |
*** dceara has joined #openvswitch | 22:00 | |
*** rcernin has joined #openvswitch | 22:31 | |
*** rcernin has quit IRC | 22:49 | |
*** rcernin has joined #openvswitch | 22:53 | |
*** dceara has quit IRC | 23:01 | |
*** tbachman has quit IRC | 23:40 | |
*** tbachman has joined #openvswitch | 23:41 | |
*** tbachman_ has joined #openvswitch | 23:44 | |
*** tbachman has quit IRC | 23:47 | |
*** tbachman_ is now known as tbachman | 23:47 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!