Open Stack

Aaron>> ...One would need to query quantum to actually see the status if
the port has been wired up or not.

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).

Aaron>> ....is that the interface is attached to the vm (i.e belongs to
compute)...I like how salvatore stated in the above thread (quoted below),

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.

Aaron>> Would have nova-compute retry to connect to libvirtd rather than
stopping solve the issue here?

Hmm...I don't think you understand the problem here. Maybe due to my bad
explanation...

Regards,

-Jun
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130520/df7e3203/attachment.html>