Closed PlagueCZ closed 3 months ago
One is for LB target returning an error when it does not exist
Did this behavior change during maglev hashing implementation ? In other words, did we return an error for a non-existing LB target before maglev implementation ?
If not and we are adding it now, metalnet should ignore the "Not-found" error, if not already done. Otherwise, we might be breaking the idempotency of the LB target deletion call on the metalnet side.
Yes, we actually did return an error before, it'S jsut that dpservice-go
tests were not run for a while now this we did not notice the change.
I did also check the code (though briefly) and it is ignored explicitly on
controllers/loadbalancer_controller.go:150: dpdkerrors.Ignore(dpdkerrors.NOT_FOUND),
which is in deleteLoadBalancer()
Thanks for checking. All fine then.
@PlagueCZ Could you please rebase ?
There were two small problems in LB gRPC. Nothing that happened in the production environment as the caller did not cause the situation/require such response. But dpservice should have the protocol robust on its own.
One is for LB target returning an error when it does not exist, the other for LB creation with duplicate ports.