On Wed, Feb 26, 2025 at 10:17 AM <martin.kal...@canonical.com> wrote: > > On Wed, 2025-02-26 at 13:46 +0100, Dumitru Ceara wrote: > > On 2/26/25 1:44 PM, martin.kal...@canonical.com wrote: > > > On Wed, 2025-02-26 at 13:02 +0100, Dumitru Ceara wrote: > > > > Hi MJ, > > > > > > > Hi MJ and Dumitru, > > > > > > > +Numan (original author of ovn-fake-multinode) > > > > > > > > On 2/25/25 7:43 PM, MJ Ponsonby wrote: > > > > > This is being posted as a RFC. I have a number of concerns with > > > > > this > > > > > test: > > > > > - This test requires two nodes not using ovn, one of them > > > > > cannot be > > > > > a > > > > > fake vm as it needs to be able to run frr to act as a BGP > > > > > peer > > > > > using > > > > > an external daemon, which was an important part of this test. > > > > > > > > Do you mean: > > > > - ovn-gw-2 will run the FRR instance that's behind an OVN port > > > > AND > > > > - ovn-gw-3 is removed from the OVN underlay (I see you remove its > > > > interface from br-ex) and will run the "external" FRR instance > > > > > > > > ? > > > > > > > > If that's the case, can't we start the "external" FRR instance in > > > > a > > > > network namespace that plug into the br-ovn-ext bridge > > > > (OVN_EXT_BR)? > > >
I'd suggest creating a namespace in ovn-gw-x fake chassis and adding a veth pair connecting this namespace to ovs bridge br-ex. Just like how it is done here - https://github.com/ovn-org/ovn/blob/main/tests/multinode.at#L170 You can start frr in this namespace. Thanks Numan > > > That's my understanding of the topology too. I agree that it would > > > be > > > cleaner to have "dedicated" "external vm", rather than re-purposing > > > one > > > of the GW chassis. > > > > > > It seems to me that it would be relatively easy to introduce new > > > class > > > of "VMs", in the ovn-fake-multinode's 'ovn_cluster.sh', that would > > > represent "external host". There are currently > > > chassis/gw/central/relay > > > "VMs" that are controlled by > > > CHASSIS_COUNT/GW_COUNT/CENTRAL_COUNT/RELAY_COUNT variables. In the > > > same > > > vein, there could be "EXTERNAL_COUNT" that would spawn N podman > > > containers plugged 'br-ovn-ext' bridge on host. > > > Such external VM's would probably find usage in other tests too. > > > Whenever an connectivity from external network to OVN needs to be > > > tested. > > > > > > > Well my suggestion was to use the br-ovn-ext bridge ovn-fake- > > multinode > > already configures for exactly this use case: testing connectivity > > from > > an external entity to OVN. > > Oh I see, perhaps my idea was indeed an overkill. > > Thanks, > Martin. > > > > > Regards, > > Dumitru > > > > > Best regards, > > > Martin. > > > > > > > > > > > > - Currently frr is not one of the packages installed on the > > > > > ovn-fake-multinode nodes, I am posting a PR to ovn-fake- > > > > > multinode > > > > > to > > > > > address this however. > > > > > > > > > > > > > That's fine in my opinion. We need to figure out how to do this > > > > properly though. In CI we run ovn-fake-multinode v0.2. Maybe we > > > > should > > > > tag a new v0.3 version once frr is added and update our CI tests > > > > to > > > > be > > > > compatible with that new version. > > > > > > > > > Looking forward to responses regarding this, > > > > > Thanks. > > > > > > > > > > MJ Ponsonby (1): > > > > > Multinode BGP unnumbered test for ovn > > > > > > > > > > tests/multinode.at | 148 > > > > > +++++++++++++++++++++++++++++++++++++++++++++ > > > > > 1 file changed, 148 insertions(+) > > > > > > > > > > > > > Thanks, > > > > Dumitru > > > > > > > > _______________________________________________ > > > > dev mailing list > > > > 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 _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
