On 12 Jul 2023, at 23:09, Dumitru Ceara <dce...@redhat.com> wrote:
On 7/12/23 21:46, Odintsov Vladislav wrote: Hi Dumitru, Hi Vladislav, first of all, I’l like to mention that’s a great idea! I’m wondering wether ovn interconnection infrastructure and ovn vtep could also be a part of this testing? There's actually already work in progress to add ovn interconnection support to the current ovn-heater workloads. Lorenzo, in cc, is working on that: https://github.com/ovn-org/ovn-heater/pull/169 Oh, that’s very good, thanks! OVN VTEP was not on our immediate list but it's definitely nice to have. Do you maybe have time to contribute a formal description of the OVN VTEP topology and maybe what workloads to simulate on it for testing the control plane? I’ll try to see if I can do anything in this direction. Thanks! On 12 Jul 2023, at 22:38, Dumitru Ceara <dce...@redhat.com> wrote: On 7/12/23 14:42, Frode Nordahl wrote: On Wed, Jul 12, 2023 at 2:31 PM Felix Huettner <felix.huettner@mail.schwarz> wrote: On Wed, Jul 12, 2023 at 01:57:18PM +0200, Dumitru Ceara wrote: On 7/12/23 13:00, Felix Huettner wrote: Hi everyone, On Wed, Jul 12, 2023 at 12:29:58PM +0200, Dumitru Ceara wrote: On 7/12/23 12:04, Frode Nordahl wrote: On Wed, Jul 12, 2023 at 10:51 AM Dumitru Ceara <dce...@redhat.com> wrote: Hi all, During the ovn-heater community meeting organized by Frode yesterday (thanks again for that!) we agreed to follow up on some points. Two of these are related to gathering more information that allow us to build realistic test scenarios (1) and define targets for them (2). On that note we have agreed to prepare a _short_ questionnaire to be shared with OpenStack + OVN users (companies and other operators). I started a draft document here: https://docs.google.com/document/d/151saO5a5PmCt7cIZQ7DkgvU755od76BlN2bKjXc1n08 It's mostly based on the previous discussion and information we received from Felix Hüttner [0]. I gave access to everyone with the link to suggest changes/comment on the document. Also, if people prefer a different way of building this questionnaire (e.g., a PR on github/ovn-org/ovn-heater) please let me know. An additional note: I don't think the goal is to get an 100% comprehensive list of all possible workloads and scale targets. AFAIU the intention is to quickly (in a few weeks?) identify a "few" relevant types of workloads and start with writing test scenarios for those. We could then, incrementally, build on top of that. Thanks alot for putting this together, I think it is a great start. There is currently no mention of what type of topology is being used though, I do not want to complicate things, but I do think we need to at least gauge what is used behind the numbers being presented, as it would have consequences for how we lay out the tests, and consequently what we scale for. I was hoping for targets that make sense for all topologies. I think these should cover the most normal cases: Gateway topologies: * Distributed gateways with distributed FIPs * Distributed gateways with centralized NAT * Centralized gateways IP topologies: * Project networks mainly use IPv4 RFC1918 and SNAT/DNAT * Project networks mainly use routed IPv4 (no NAT) * Project networks mainly use routed IPv6 (no NAT) Do we really need to differentiate between IP topologies? I think the only significant difference above is NAT vs noNAT. From ovn-heater perspective there should be no difference between private and routed IPv4 or v6. If we test and optimize OVN for the worst case and always configure NAT we should be fine, right? i'm not sure if that works. With centralized gateways it makes a big difference if you have NAT or no NAT. The reason (iirc) is that without NAT you are not actually using these gateways for most of the traffic in your environment. But with NAT you need to use them. Well, from a control plane perspective, I thought the "worst case" is when we also configure NAT. thats probably right. Maybe we just stick to it then for now (until we see special scaling issues just for the non nat path) I brought up the NAT / no NAT cases because with the current way OpenStack lays out logical routers and logical router ports the traffic is in practice centralized when not using NAT. But as you point out, this would be a data plane scaling issue and more a question to feed into possible future topology changes for OpenStack Neutron rather than a question informing the control plane scale testing. So I agree, let's drop them. Any suggestions for how to tie these into the questionnaire without causing a matrix explosion? Not really, but if we only have "Gateway topologies" as a variable then we end up with a way smaller matrix. :) i would go for a matrix with gateways (distributed or central) and nat (yes or no). +1 Should we also give up on the "cluster type" differentiation and just focus on "large clusters"? In the end that's what we want to be able to run. I think that makes sense. If someone finds a small cluster that has issues thats probably also interesting, but they will hopefully write that in there as well. +1 Thanks, Felix and Frode! I tried to re-phrase the questionnaire according to our discussion until now. I ended up with two topologies (distributed/centralized gateways) and questions applicable to both topologies. NAT vs noNAT is now expressed through two different questions. I created an "RFC-v1" document version before these changes so we can always roll back to that but I'm not sure if anyone else except the owner of the document can actually see it. On a different note, I'm starting to wonder if this "questionnaire" shouldn't just live in a form or another inside the ovn-heater repo so that it can serve as example for the future if we ever want to add more types of workloads. If you agree I could also move this into a PR that adds a new file to the repo. Thanks, Dumitru _______________________________________________ dev mailing list d...@openvswitch.org<mailto:d...@openvswitch.org><mailto:d...@openvswitch.org> https://mail.openvswitch.org/mailman/listinfo/ovs-dev _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
