<div dir="ltr"><div>Thanks for the reply!</div><div><br></div><div>I guess that I thought there was distinction between the ovsdb case and the</div><div> OpenFlow case  since the latter is held non-persistently by the ovs switch,</div><div> so my source of truth will be the app's DB;</div><div>also, applying lots (1,000+) of OF rules on a datapath, from my experience,</div><div> is done almost instantly by ovs-vswitchd (and the kernel DP), but adding bridges might <br></div><div>take longer than that, especially when having a large number of bridges*.</div><div></div><div><br></div><div>So, from an architectural perspective, I'm more worried of the ovsdb(s) state getting <br></div><div>out of sync with my source of truth, which is my app DB (suppose it's a DB with</div><div>ACID gurantees, i.e. MySQL).</div><div><br></div><div>(*) The actual ovsdb transaction happens quite quickly, but it may take a lot of time</div><div>for ovs-vswitchd to ack that and apply the changes.<br></div><div><br></div><div>How'd you approach having multiple ovsdb-servers which have to be kept in a consistent</div><div>state?</div><div></div><div>(Not replicated, but consistent.)<br></div><div><br></div><div>I suppose that I can get rid of the app DB, and just keep the state distributed <br></div><div>between all the OVS hosts, but that approach is hard to modify or query,</div><div>generally because of lack of client libraries for that (Python or Java).</div><div>There's Ryu, but it's very  cumbersome to work with when comparing to, <br></div><div>say, any SQL library.</div><div><br></div><div>Even more importently, when the state is distributed, it's impossible to make an <br></div><div>atomic change to the system, because you can't have a distributed transaction</div><div>with multiple ovsdb-servers.</div><div></div><div></div><div><br></div><div>Ideally, I'd be best if a single ovsdb-server could serve multiple OVS hosts.<br></div><div></div><div><br></div><div>P.S. <br></div><div>How can am ovsdb manager know when ovs-vswitch had applied a change?</div><div>(I want it to mimic the "wait" functionality of ovs-vsctl).<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 29 Nov 2019 at 18:17, Ben Pfaff <<a href="mailto:blp@ovn.org">blp@ovn.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Nov 29, 2019 at 11:54:13AM +0200, Matan Rosenberg wrote:<br>
> I'm tying to understand what ovsdb managers actually do.<br>
> <br>
> Say that I have two OVS hosts, each with its own ovs-vswitchd and<br>
> ovsdb-server.<br>
> Both OVS hosts are logically related, and I want to control them from a<br>
> single, central location.<br>
> <br>
> In the datapath plane, I can set-controller on all bridges on both OVS<br>
> hosts to the same OpenFlow controller, and thus achieve central management.<br>
<br>
OK, yes.<br>
<br>
> In the management plane, I don't see how I can add/remove/manipulate<br>
> bridges on both OVS hosts from the same location, since each OVS host has<br>
> its own ovsdb-server.<br>
<br>
That's a strange comment, since each OVS host also has its own<br>
ovs-vswitchd, which the controller addresses individually.  The<br>
situation for OpenFlow controllers and OVSDB managers is exactly<br>
analogous.<br>
<br>
> (In my use case, I happen to add/remove bridges quite frequently).<br>
> <br>
> Of course, I can just issue two ovs-vctl command with different DB each<br>
> time, but this isn't a vert scalable approach, and it also has severe<br>
> consistency drawbacks, since the network topology is held in two places.<br>
> This is in direct contrast from the datapath plane, because I can actually<br>
> write an OpenFlow controller that determines the correct rules from, say,<br>
> an application DB (not ovsdb!).<br>
<br>
No, there's no contrast here.  The situation is exactly the same, since<br>
the OpenFlow controller and the switch each hold the network topology<br>
and the controller is responsible for pushing its view down to the switch.<br>
<br>
> I've stumbled upon the ovs-vsctl set-manager command, which, from what I<br>
> can see, can be used in conjunction with something like an OpenDaylight<br>
> OVSDB Manager.<br>
> If so, can a single OVSDB manager manage both OVS hosts?<br>
<br>
Yes.<br>
<br>
> And if so, what part does the local ovsdb-server play, if the network<br>
> topology is held with the OVSDB manager? Do I still actually need it, or<br>
> can ovs-vswitchd just directly query the manager?<br>
<br>
The local ovsdb-server is the actual database.  The manager just queries<br>
and updates it.  This is exactly the same as the OpenFlow situation.<br>
</blockquote></div>