<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, May 20, 2013 at 2:47 PM, Jun Cheol Park <span dir="ltr"><<a href="mailto:jun.park.earth@gmail.com" target="_blank">jun.park.earth@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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,</div></blockquote><div><br></div><div>Yes I know. The quantum-agent is supposed to notify quantum-server of the status of the port (i.e set it to ACTIVE when it's wired... meaning that the backend implementation does what it needs to do to configure the network: i.e installing flows, trunking vlans, etc). <br>
</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div> So please clearly differentiate between quantum-server and quantum-agent) </div></blockquote>
<div><br></div><div>FYI: not all the plugins use a quantum-agent.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>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). </div>
</blockquote><div><br></div><div>Yes this is the meaning of the status from nova.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>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.</div>
</blockquote><div><br></div><div>Correct (the meaning of the status from nova that the instance is booted) but doesn't mean the network is ready. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div> 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? </div>
</blockquote><div><br></div><div>In my opinion we do not want to have the status of the vm so tightly coupled with the status of it's port like that. There are multiple status's and one would need to check them all in order to determine if a vm is ready. <br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>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-size:13px;font-family:arial,sans-serif">that the interface is attached to the vm (i.e belongs to compute)...</span><span style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">I like how salvatore stated in the above thread (quoted below), </span></div>
<div><span style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif"><br></span></div><div><span style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">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. </span></div>
</blockquote><div><br></div><div>Just to clarify there is a status field on a quantum port. For example: <br><br></div><div>(Newly created port status is marked DOWN). <br><br></div><div>$ quantum port-create private<br>
Created a new port:<br>+-----------------+---------------------------------------------------------------------------------+<br>| Field | Value |<br>
+-----------------+---------------------------------------------------------------------------------+<br>| admin_state_up | True |<br>| device_id | |<br>
| device_owner | |<br>| fixed_ips | {"subnet_id": "bebe108a-0aed-47d1-9941-33ea365ff742", "ip_address": "10.0.0.3"} |<br>
| id | f535c164-540e-4c51-8932-31cf768e15ae |<br>| mac_address | fa:16:3e:c7:6a:0d |<br>| name | |<br>
| network_id | 2a29eced-9a08-44ff-b81d-6e9f28b27b60 |<br>| security_groups | c0e4f419-86ee-447a-9f99-14e2ac8f7cc9 |<br><b>| status | DOWN |</b><br>
| tenant_id | b17b19efb55245fd8ff45d19cf6e6c0b |<br>+-----------------+---------------------------------------------------------------------------------+<br><br></div><div>
# Boot instance using port: <br>nova boot --nic port-id=f535c164-540e-4c51-8932-31cf768e15ae --flavor 1 --image 9442ca55-525a-410e-a6d2-6e7b9fd167f2 foobar<br></div><div><br><br><br>(after a little while once w/e implements the backend to the quantum plugin you are using wires the port (meaning installs flows NOT the creation of the tap interface) <br>
</div><div>$ quantum port-show f535c164-540e-4c51-8932-31cf768e15ae<br>+-----------------+---------------------------------------------------------------------------------+<br>| Field | Value |<br>
+-----------------+---------------------------------------------------------------------------------+<br>| admin_state_up | True |<br>| device_id | 86a96cc5-553e-4a89-9238-8b58abb78eaa |<br>
| device_owner | compute:None |<br>| fixed_ips | {"subnet_id": "bebe108a-0aed-47d1-9941-33ea365ff742", "ip_address": "10.0.0.3"} |<br>
| id | f535c164-540e-4c51-8932-31cf768e15ae |<br>| mac_address | fa:16:3e:c7:6a:0d |<br>| name | |<br>
| network_id | 2a29eced-9a08-44ff-b81d-6e9f28b27b60 |<br>| security_groups | c0e4f419-86ee-447a-9f99-14e2ac8f7cc9 |<br><b>| status | ACTIVE |</b><br>
| tenant_id | b17b19efb55245fd8ff45d19cf6e6c0b |<br>+-----------------+---------------------------------------------------------------------------------+<br><br></div><div>
<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><span style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">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>
</blockquote><div><br></div><div>I have rebooting a HV on my list of things to do and see if i can reproduce what you are describing. <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div><br></div><div>Regards,</div><div><br></div><div>-Jun</div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>