Use libovsdb bindings for collecting ovs metrics #4637
Conversation
github-actions
bot
added
the
area/unit-testing
crnithya
force-pushed
the
libovsdb_metrics
branch
from
5508c97
to
288bf29
Compare
| @@ -0,0 +1,17 @@ | |||
| package ops | |||
There was a problem hiding this comment.
So I would probably setup a different package for ovn and ovs ops: ops/ovn and ops/ovs
Also no need to qualify the methods themselves, if needed we can rely on package qualification: ops.ListOVSBridges vs ovsops.ListBridges
There was a problem hiding this comment.
I have updated the code moving the ovs related ops under libovsdb/ops and also fixed the naming.
I can work on moving ovn related ops to ops/ovn as a different PR.
| ) | ||
|
|
||
| // Get OpenvSwitch table from the cache | ||
| func GetOVSOpenvSwitchTable(ovsClient libovsdbclient.Client) (*vswitchd.OpenvSwitch, error) { |
There was a problem hiding this comment.
nit: I would probably leave this at GetOpenVSwitch
There was a problem hiding this comment.
But how about GetOpenvSwitch? This not getting the OpenvSwitch table, just the single row that happens to be in that table. Maybe you and I are thinking in something different with Table. If so, do let me know.
There was a problem hiding this comment.
Fixed. Thanks for catching this misnomer, I started off with this getting the full table and changed later to single row.
| client.WithTable(&vswitchd.OpenvSwitch{}), | ||
| client.WithTable(&vswitchd.Bridge{}), | ||
| client.WithTable(&vswitchd.Port{}), | ||
| client.WithTable(&vswitchd.Interface{}), |
There was a problem hiding this comment.
I guess that metrics is not the best amortization of the extra memory consumption this brings. But I also guess as we further migrate things to libovsdb it would make more sense. What are the plans for further pieces? This is marked as WIP, do you plan to merge this before the other pieces come? Trying to get a sense of a timeline.
There was a problem hiding this comment.
Yes, I am planning to start the migration to libovsdb with metrics first.
There was a problem hiding this comment.
Would it be possible to have and merge all at once? Each bit could be a different commit here, and I would do a staggered review of each without waiting for the full set. The only problem would be rebases, but we don't expect a lot of changes on the OVS calls that we make.
It is more convenient for our downstream but I understand it might be too much to ask.
There was a problem hiding this comment.
It will be difficult to address all at once. I have added another commit to this though, to address those OVN metrics using vsctl.
crnithya
force-pushed
the
libovsdb_metrics
branch
from
288bf29
to
5c89cbe
Compare
crnithya
changed the title
crnithya
changed the title
crnithya
force-pushed
the
libovsdb_metrics
branch
3 times, most recently
from
0d4cebf
to
e5a8ef0
Compare
Signed-off-by: nithyar <[email protected]>
Signed-off-by: nithyar <[email protected]>
crnithya
force-pushed
the
libovsdb_metrics
branch
from
e5a8ef0
to
36749bd
Compare
What this PR does and why is it needed
This PR creates an ovsdb client for a node's vswitch database at startup and monitors selected tables. OVS metrics is collected periodically from these tables instead of executing ovs-vsctl commands, for performance benefits.
Which issue(s) this PR fixes
Fixes #
Special notes for reviewers
How to verify it
Details to documentation updates
Description for the changelog
Does this PR introduce a user-facing change?