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 <[email protected]> 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. >> >>> 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). > 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. > Thanks > Felix > Diese E Mail enthält möglicherweise vertrauliche Inhalte und ist nur für die > Verwertung durch den vorgesehenen Empfänger bestimmt. > Sollten Sie nicht der vorgesehene Empfänger sein, setzen Sie den Absender > bitte unverzüglich in Kenntnis und löschen diese E Mail. > > Hinweise zum Datenschutz finden Sie hier<https://www.datenschutz.schwarz/>. > > > This e-mail may contain confidential content and is intended only for the > specified recipient/s. > If you are not the intended recipient, please inform the sender immediately > and delete this e-mail. > > Information on data protection can be found > here<https://www.datenschutz.schwarz/>. > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
