<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 29 January 2014 23:13, Vishvananda Ishaya <span dir="ltr"><<a href="mailto:vishvananda@gmail.com" target="_blank">vishvananda@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im"><span style="color:rgb(34,34,34)"> I see the process as going something like this:</span><br>
</div>
<br>
* Migrate network data from nova into neutron<br>
* Turn off nova-network on the node<br>
* Run the neutron l3 agent and trigger it to create the required bridges etc.<br>
* Use ovsctl to remove the vnic from the nova bridge and add it to the appropriate ovs bridge<br>
<br>
Because the ovs bridge and the nova bridge are plugged in to the same physical<br>
device, traffic flows appropriately.<br>
<br>
There is some hand waving above about how to trigger the l3 agent to create the<br>
ports and security groups properly, but I think conceptually it could work.<br></blockquote><div><br></div><div>This is a task on my list to achieve in the next few months. The non-trivial aspect is step one as you've described it here. I would really appreciate it if a collaboration of those who know the nova-network data and those who know the neutron data could be put together in order to write some tooling to convert the network data.</div>
<div><br></div><div>Tasks which we've identified need to be done:</div><div><br></div><div>1) Convert existing networks</div><div>In our scenario we're using nova-network with VLANManager. Our target is a Neutron setup with name spaces, GRE tunnels and OpenVSwitch. In some cases networks need to be converted to provider networks to maintain functionality, in other cases the networks can be converted to completely virtual networks. The options here would point to the conversion requiring some sort of selection for the network to convert in a particular way. The selection being a single network or a set of networks.</div>
<div>A reasonable simple start would simply be to convert all networks the same way.</div><div><br></div><div><span lang="EN-US">2) Convert existing port
allocations</span></div><div><span lang="EN-US">When switching from nova-network to neutron the instance NIC's end up losing their port allocations. These have to be added, connecting them with the same IP address to the same instance on the same network (after it's converted). A specific requirement here is that the port assigned to the instance must have the same MAC address as it had before, otherwise Windows will require re-activation and linux will see the new port as an alternative network device and add it as the next NIC instead of using the same NIC that it already has.</span></div>
<div><span lang="EN-US"><br></span></div><div>3) Convert existing security
groups</div><div>4) Convert existing security rules</div><div>5) Convert existing floating IP
allocations</div><div><br></div><div>On 30 January 2014 08:14, Joshua Harlow <span dir="ltr"><<a href="mailto:harlowja@yahoo-inc.com" target="_blank">harlowja@yahoo-inc.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
1. Take offline APIs & nova-compute (so new/existing VMs can't be<br>scheduled/modified) -- existing running VMs will not be affected.<br>2. Save/dump nova database.<br>3. Translate nova database entries into corresponding neutron database<br>
entries.<br>4. Remove/adjust the *right* entries of the nova database.<br>5. Startup neutron+agents with database that it believes it was running<br>with the whole time.<br>6. Restart nova-api & nova-compute (it will now never know that it was<br>
previously using nova-network).<br>7. Profit!</blockquote><div><br></div><div>In our view, taking the API's and nova-compute off-line for the conversion period is perfectly acceptable. This is, after all, a major plumbing change in the architecture!</div>
<div><br></div><div>If we can't do this with all instances remaining online for most of the line (there will have to be a slight disruption as the traffic flows change to go through the L3 Agent), then ideally we should be able to convert a single node at a time so that we can manage the disruption with our customers.</div>
</div><div><br></div><div>My challenge is that I'm more of an operator than a developer. My python skills would rate as 'noob' or perhaps at most 'bugfixer'. Ideally I need the skills of a learned group with the same itch to scratch to work with to make this happen. If such a Holy Grail is not found, I shall find a way but it won't be pretty. ;)</div>
</div></div></div>