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 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? 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> > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
