P4RT-2.1: P4RT Election about featureprofiles

[Hobbydos]

Hi @dplore, would you consider assigning this case to me?

[dplore]

Thanks @Hobbydos , I have assigned to you. Please let us know when you expect to send a PR for this test. Thanks!

[Hobbydos]

No Problem, just assessing the timeline and will comment with an estimated time.
As for now, it looks like This comment on Issue 64 seems to hint that p4runtime-go-client is the preferred client. One clarification I would like is if there's a preference for featureprofiles to use either p4runtime-go-client or go-p4.

[dplore]

Hi, the preferred client is now https://github.com/cisco-open/go-p4. Please use the client for your test implementation. Note, we acknowledge this is a new work and the p4rt tests here are also without much precedent. We welcome feedback on your findings using this client.

[Hobbydos]

@dplore

I have a quick question regarding the handling of multiple P4RT tests. P4RT-3.1 and P4RT-3.2, election IDs are being used (0,100=primary), (0,99=secondary) and I've observed that in two different vendor implementations of P4RT, the highest election ID is kept track. When featureprofile tests are ran sequentially, the P4RT server might remember the highest election ID until the P4RT server is restarted. Any following script using lower election ID for its clients will cause the client to fail to be elected as primary. Are there any expectations that users are to handle restarting the P4RT server via bindings file/CI process? If not, is there a proposed alternative?

[dplore]

@robshakir @Ankur19 this is a common issue with gRIBI as well. Should we update our tests to have the client assume primary using a methodology like described in the gRIBI spec. Are p4rt and gRIBI elections using the same algorithm?

[Hobbydos]

PR #849

[Hobbydos]

Renamed the test to "P4RT Election" to be more inclusive.

[Hobbydos]

PR849 was merged