On Thu, Dec 14, 2023 at 2:04 AM Ilya Maximets <[email protected]> wrote:
>
> The original problem was summarized on the OVS+OVN Conf'22 last year:
> https://www.openvswitch.org/support/ovscon2022/#t19
> Slides:
> https://www.openvswitch.org/support/ovscon2022/slides/ovsdb-a-database.pdf
>
> In short, there are way to many ways to configure remotes and databases
> but not a single one of them can cover all the situations. And there
> are cases like max-backoff on active-backup connection that are not
> configurable at all.
>
> The proposed solution for this problem was to unify configurations
> within a new Local_Config database that will be local to a server
> and will have support for all we need in the schema.
>
> However, there are few issues with this solution:
>
> 1. It doesn't reduce the number of ways things can be configured,
> but increases, because we'll need to add things that are covered
> by other methods to the database, while those other methods
> are still in use. And it is actually required to use the
> command line or appctl in order to use the values stored in the
> database, i.e. --remote=db:db:table:row.
>
> 2. Not particularly user-friendly. Database files are user-readable
> -ish, but not writable, i.e. require special tools in order to
> make changes and in most cases require a running ovsdb-server
> in order to make changes.
>
> 3. We need a way to restrict write access for external users,
> but allow local administrators to change the configuration.
> Hence, potentially complex access management and potential
> security issues.
>
> Taking all of that into account and spending another year on a
> solution :) , I believe, introduction of a configuration file can
> make things easier. This patch set adds support for a new command
> line argument --config-file that is mutually exclusive with many
> other command line arguments and appctl commands that can configure
> the same thing.
Thank you for your work on this! The existing configuration model of
the OVSDB server is indeed on the list of black magic arts for anyone
using it for the first time.
I like the way you think wrt. making the new way mutually exclusive
with the old ways to reduce the end user surface area on these knobs.
> A few key points:
>
> 1. Configuration file is a plain text JSON file, so it can be edited
> with just a text editor without need for any extra tools.
> (JSON because we have a decent JOSN parser and there is no need
> for extra dependencies. And no other format is actually superior,
> all of them have their own issues.)
>
> 2. Configuration file is a replacement for many command line options
> and appctls, because it is mutually exclusive with them.
> If --config-file is set, configuration that can be done via
> configuration file can only be done via configuration file.
> (It still allows to point to the database for remotes, but there
> is no actual need for this, except in very rare cases, and it is
> visible from the file that it points to the database.)
>
> 3. If configuration change is needed in runtime: change the file
> and call ovsdb-server/reload. Ihar also suggested to use SIGHUP
> for this, can be added in the future.
+1
> SSL configuration is not moved to a config-file in this patch set,
> but can be done as a follow up.
>
>
> Structure of this patch set:
>
> - Patches 1-5 are general fixes and enhancements that are not
> really related to the change, but needed/useful
> one way or another.
>
> - There are only 4 actually large patches that are not tests.
> And they are mainly refactoring of the existing code without
> externally visible changes. This is because we have to
> isolate all the databases from each other so they do not
> share configuration. But at the same time we have to preserve
> all the current interfaces for backward compatibility and
> that takes a lot of code.
>
> - Most other patches in the set a small simple changes.
>
> More description and examples are in individual patches and the
> documentation.
>
> TL;DR; A small example of a config file from the patch #20:
>
> {
> "remotes": {
> "punix:db.sock": {},
> "pssl:6641": {
> "inactivity-probe": 16000,
> "read-only": false,
> "role": "ovn-controller"
> }
> },
> "databases": {
> "conf.db": {},
> "sb.db": {
> "service-model": "clustered"
I'm a bit worried about this item in the configuration file:
1) The database file itself is the authoritative source of truth for
the service model, and the configured value can get out of sync with
the on-disk reality. Throughout the lifetime of a database, the
operator may need to momentarily change the service model. Would this
not just add to the steps required to do this?
2) Having this in the configuration file may give the impression that
OVSDB will manage the on-disk DB files, while the reality is that it
will not. Is this a potential source of confusion?
--
Frode Nordahl
> },
> "OVN_Northbound": {
> "service-model": "relay",
> "source": {
> "ssl:[fe:::1]:6642,ssl:[fe:::2]:6642": {
> "max-backoff": 8000,
> "inactivity-probe": 10000
> }
> }
> }
> }
> }
>
>
> Ilya Maximets (22):
> ovsdb-server.at: Enbale debug logs in active-backup tests.
> tests: ovsdb: Use diff -up format for replay test.
> jsonrpc: Sort JSON objects while printing debug messages.
> ovsdb: jsonrpc-server: Fix the DSCP value in default options.
> ovsdb: trigger: Do not allow conversion in read-only mode.
> ovsdb: Allow database itself to be read-only.
> jsonrpc-server: Add functions to convert jsonrpc options to/from json.
> ovsdb: Track jsonrpc options per remote.
> ovsdb: Extract relay string parsing into a separate function.
> ovsdb: replication: Isolate databases from each other.
> ovsdb: replication: Automatically switch read-only mode.
> ovsdb-server: Database config isolation.
> ovsdb-server: Add no-op config-file option.
> jsonrpc-server: Re-add remotes on role changes.
> jsonrpc: Add function to update all options at once.
> ovsdb: Embed jsonrpc session options into ovsdb jsonrpc options.
> ovsdb: replication: Allow to set all jsonrpc options.
> ovsdb-cs: Add function to set all jsonrpc session options.
> ovsdb: relay: Allow setting all jsonrpc session options.
> ovsdb-server: Allow user-provided config files.
> tests: ovsdb: Add relay and replication execution with config file.
> tests: ovsdb: Add configuration tests with config file.
>
> Documentation/ref/ovsdb.7.rst | 86 +-
> Documentation/topics/ovsdb-relay.rst | 19 +
> NEWS | 4 +
> lib/jsonrpc.c | 17 +-
> lib/jsonrpc.h | 8 +
> lib/ovsdb-cs.c | 10 +
> lib/ovsdb-cs.h | 3 +
> ovsdb/jsonrpc-server.c | 123 ++-
> ovsdb/jsonrpc-server.h | 18 +-
> ovsdb/ovsdb-server.1.in | 96 +-
> ovsdb/ovsdb-server.c | 1399 +++++++++++++++++++++-----
> ovsdb/ovsdb.c | 2 +
> ovsdb/ovsdb.h | 3 +
> ovsdb/relay.c | 6 +-
> ovsdb/relay.h | 4 +-
> ovsdb/replication.c | 677 ++++++-------
> ovsdb/replication.h | 37 +-
> ovsdb/trigger.c | 8 +
> tests/ovsdb-client.at | 6 +-
> tests/ovsdb-server.at | 793 ++++++++++++++-
> 20 files changed, 2600 insertions(+), 719 deletions(-)
>
> --
> 2.43.0
>
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
