On 9/19/23 13:57, Robin Jarry wrote: > Ilya Maximets, Sep 19, 2023 at 13:47: >> With flexibility of appctl comes absolutely no guarantee for API >> stability. But as soon as we have structured output, someone will >> expect it. If we can agree that users cannot rely on the structure >> of that structured output, then it's fine. Otherwise, OVSDB with >> its defined schema is a much better choice, IMO. Constructing a >> single 'select' transaction for OVSDB isn't really much more >> difficult than constructing an appctl JSON-PRC request. > > I would argue that the ovsdb schema could also be modified so I guess > this comes up to deciding whether API can be broken or not.
Schema can be modified, but only in major releases. And columns can't be removed from the schema or changed, only added. Appctl output can change completely even in a minor release. > However, going through ovsdb simply as an API proxy to query live stats > to ovs-vswitchd seems complex and not resource efficient. Especially if > the appctl socket is already available and allows to reach vswitchd > directly. > > I think that for statistics, it would make more sense to go with the > lightweight option. OVSDB has a few advantages. First is that you may actually avoid waking up ovs-vswitchd if you're fine with a couple of seconds delay in stats. And I'm not convinced that many users actually need higher precision. Things like prometheus collector definitely don't need that. In that sense the database solution is actually much lighter. What kind of use case you have in mind for these stats? Who is the consumer? The second advantage is a potential ability to expose the stats over the network, instead of only to processes that run locally and have enough privileges to talk to ovs-vswitchd directly. Best regards, Ilya Maximets. _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
