Open Stack

On Mon, May 20, 2013 at 2:47 PM, Jun Cheol Park <jun.park.earth at gmail.com>wrote:

> 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,
>

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


> So please clearly differentiate between quantum-server and quantum-agent)
>

FYI: not all the plugins use a 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).
>

Yes this is the meaning of the status from nova.


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

Correct (the meaning of the status from nova that the instance is booted)
but doesn't mean the network is ready.


> 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?
>

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.


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

Just to clarify there is a status  field on a quantum port. For example:

(Newly created port status is marked DOWN).

$ quantum port-create private
Created a new port:
+-----------------+---------------------------------------------------------------------------------+
| Field           |
Value
|
+-----------------+---------------------------------------------------------------------------------+
| admin_state_up  |
True
|
| device_id
|
|
| device_owner
|
|
| fixed_ips       | {"subnet_id": "bebe108a-0aed-47d1-9941-33ea365ff742",
"ip_address": "10.0.0.3"} |
| id              |
f535c164-540e-4c51-8932-31cf768e15ae
|
| mac_address     |
fa:16:3e:c7:6a:0d
|
| name
|
|
| network_id      |
2a29eced-9a08-44ff-b81d-6e9f28b27b60
|
| security_groups |
c0e4f419-86ee-447a-9f99-14e2ac8f7cc9
|
*| status          |
DOWN
|*
| tenant_id       |
b17b19efb55245fd8ff45d19cf6e6c0b
|
+-----------------+---------------------------------------------------------------------------------+

# Boot instance using port:
nova boot --nic port-id=f535c164-540e-4c51-8932-31cf768e15ae --flavor 1
--image 9442ca55-525a-410e-a6d2-6e7b9fd167f2 foobar



(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)
$ quantum port-show f535c164-540e-4c51-8932-31cf768e15ae
+-----------------+---------------------------------------------------------------------------------+
| Field           |
Value
|
+-----------------+---------------------------------------------------------------------------------+
| admin_state_up  |
True
|
| device_id       |
86a96cc5-553e-4a89-9238-8b58abb78eaa
|
| device_owner    |
compute:None
|
| fixed_ips       | {"subnet_id": "bebe108a-0aed-47d1-9941-33ea365ff742",
"ip_address": "10.0.0.3"} |
| id              |
f535c164-540e-4c51-8932-31cf768e15ae
|
| mac_address     |
fa:16:3e:c7:6a:0d
|
| name
|
|
| network_id      |
2a29eced-9a08-44ff-b81d-6e9f28b27b60
|
| security_groups |
c0e4f419-86ee-447a-9f99-14e2ac8f7cc9
|
*| status          |
ACTIVE
|*
| tenant_id       |
b17b19efb55245fd8ff45d19cf6e6c0b
|
+-----------------+---------------------------------------------------------------------------------+




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

I have rebooting a HV on my list of things to do and see if i can reproduce
what you are describing.

>
> Regards,
>
> -Jun
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130521/f954d433/attachment.html>