<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Thanks Slawek for your quick response!</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">
<div class="moz-cite-prefix">On 23/08/2022 07:47, Slawek Kaplonski
wrote:<br>
</div>
<blockquote type="cite" cite="mid:2446920.D5JjJbiaP6@p1">
<blockquote type="cite" style="color: #007cff;">
<pre class="moz-quote-pre" wrap="">1) Are the data models of the user managed resources abstract (enough)
from the ML2 used?
So would the composition of a router, a network, some subnets, a few
security group and a few instances in a project just result in a
different instantiation of packet handling components,
but be otherwise transparent to the user?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">Yes, data models are the same so all networks, routers, subnets will be the same but implemented differently by different backend.
The only significant difference may be network types as OVN works mostly with Geneve tunnel networks and with LB backend You are using VXLAN IIUC your email.
</pre>
</blockquote>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">That is reassuring. Yes we currently
use VXLAN. But even with the same type of tunneling, I suppose the
networks and their IDs will not align to form a proper layer 2
domain,<br>
not even talking about all the other services like DHCP or
metadata. See next question about my idea to at least have some
gradual switchover.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">
<blockquote type="cite" cite="mid:2446920.D5JjJbiaP6@p1">
<blockquote type="cite" style="color: #007cff;">
<pre class="moz-quote-pre" wrap="">2) What could be possible migration strategies?
[...] Or project by project by changing the network agents over
to nodes already running OVN?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">Even if You will keep vxlan networks with OVN backend (support is kind of limited really) You will not be able to have tunnels established between nodes with different backends so there will be no connectivity between VMs on hosts with different backends.
</pre>
</blockquote>
<p>I was more thinking to move all of a projects resources to
network nodes (and hypervisors) which already run OVN. So split
the cloud in two classes of machines, one set unchanged running
Linuxbridge and the other<br>
in OVN mode. To migrate "a project" all agents of that projects
routers and networks will be changed over to agents running on
OVN-powered nodes....<br>
So this would be a hard cut-over, but limited to a single
project. In alternative to replacing all of the network agents
on all nodes and for all projects at the same time.<br>
</p>
</div>
<div class="moz-cite-prefix">Wouldn't that work - in theory - or am
I missing something obvious here?<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<blockquote type="cite" cite="mid:2446920.D5JjJbiaP6@p1">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Has anybody ever done something similar or heard about this being done
anywhere?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
I don't know about anyone who did that but if there is someone, I would be happy to hear about how it was done and how it went :)
</pre>
</blockquote>
<p>We will certainly share our story - if we live to talk about it
;-)<br>
</p>
<p><br>
</p>
<p><br>
</p>
<p>Thanks again,<br>
With kind regards</p>
<p><br>
</p>
<p>Christian<br>
</p>
</body>
</html>