<div>Aaron>> ...One would need to query quantum to actually see the status if the port has been wired up or not. </div><div><br></div><div>Nope, it's not possible. That's exactly what I mentioned as a problem. Since quantum API (served from a quantum-server, not from quantum-agent, So please clearly differentiate between quantum-server and quantum-agent) manages only quantum DB, according to the current design of quantum there is no way to verify whether or not a port is fully functioning even when a port is properly wired to a VM ("wired" means that a VM is already running on an attached tap from a hypervisor perspective). As I said, when there is no OVS flow deployed on an OVS tap (BTW, this is supposed to be done by quantum-agent, not quantum-server in the current design), a VM (already claimed to be active) does not have network connectivity. Now we get an inconsistent state of the port information. This is a whole point I have been using for saying that there is a design flaw. Keeping the functionality of creating taps belong to nova-compute makes things much more complex and infeasible to track down what goes wrong unless nova-compute communicates with quantum-agent to check out the true state of a port. But, unfortunately, there is no way to make nova-compute directly or explicitly talk to quantum-agent now. So my suggestion has been why not simply make nova-compute call a truly abstracted quantum API for creating a port, which returns the actual state of a port? I believe this is a much simpler design and better in many ways (that I already described using several use cases before).</div>
<div><br></div><div>Aaron>> ....is <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">that the interface is attached to the vm (i.e belongs to compute)...</span><span style="font-size:13px;background-color:rgb(255,255,255);color:rgb(34,34,34);font-family:arial,sans-serif">I like how salvatore stated in the above thread (quoted below), </span></div>
<div><span style="background-color:rgb(255,255,255);color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="background-color:rgb(255,255,255);color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px">At minimum, what really matters regardless of who wires a port to a VM is there must be a way to make sure whether or not a port is fully functioning. Towards that goal, I've been just trying to provide my suggestion, which definitely does not have to be the only solution. As you tried to do, if we can find a way to resolve the inconsistency issue while not changing the current nova-compute design, it would be fine although seems not ideal. But, as a first step, I think we should understand what the problem is and then proceed.</span></div>
<div><br></div><div>Aaron>> Would have nova-compute retry to connect to libvirtd rather than stopping solve the issue here? </div><div><br></div><div>Hmm...I don't think you understand the problem here. Maybe due to my bad explanation... </div>
<div><br></div><div>Regards,</div><div><br></div><div>-Jun</div>