Neutron mech driver host selection

[lukego]

The Neutron mechanism driver portbinding hook should be extended to place ports on compute hosts where the intended physical_network is available. This will require a config file mapping physical_network names onto compute host names.

The mechanism driver code is in the SnabbCo Github fork of neutron.

[thisisrmr]

I'm curious to know why this particular approach is taken. Are there any issues with the approach I took with the mech driver[1] and agent[2] ?

[1] https://bitbucket.org/thisisrmr/sns-neutron/src/a2550944e05b9e40dcfb6634e5281686ee9c7243/neutron/plugins/ml2/drivers/mech_snabbswitch.py?at=sns-qos-tunnel2

[2] https://bitbucket.org/thisisrmr/sns-neutron/src/a2550944e05b9e40dcfb6634e5281686ee9c7243/neutron/plugins/snabbswitch/agent/snabbswitch_neutron_agent.py?at=sns-qos-tunnel2

[lukego]

Can you explain your approach? I may not understand it properly.

My line of thought is basically: if we can live without a Python agent on the compute host then that makes the design simpler. (I think I got this idea from OpenDaylight driver?)

The disadvantages that I see in having a Python agent running on the compute nodes is:

1. One more process that we need to test, debug, and troubleshoot.
2. Makes basic operation of Snabb NFV depend on RabbitMQ.
3. More code that we need to upstream into OpenStack instead of developing independently.
4. More code in a language that's foreign to Snabb Switch i.e. Python.

There may be advantages that I am overlooking though?

[thisisrmr]

Hmm, the last time I tried to run without an agent, booting the vm failed at the scheduling stage (since the port was not reported "up" by a agent). I don't know if that check got removed from nova (btw are you sure you were not running an agent on the host?).

[lukego]

You are right. I hacked this in an ugly way and have not found a better solution. Here is what I did: lukego/neutron@31d6d06. It seemed like the problem was caused by the DHCP agent, and we don't necessarily want to run the DHCP agent at all in Snabb NFV, so I was hoping we can work around it somehow.

I would ideally like to not have an agent. Does ODL do that successfully? What would be needed to make this work? If you can analyze the situation I can discuss it with the OpenStack hackers e.g. via code review.

[thisisrmr]

IIUC we need a neutron agent running on each compute node if things are to work properly. The snabbswitch_neutron_agent.py was modeled after the NEC neutron agent (the simplest among the lot) and all it does is report the list of available ports at a regular interval. The alternative is to depend on the linuxbridge agent (but in that case, you have to test against an agent that is even more complicated and is being modified a lot). IIRC there was some talk about neutron getting a more flexible agent (don't know if/when that's going to happen).

If you're concerned about RabbitMQ, all I can say is that there are much more ugly things happening under the hood - try grep-ing a port-id in the openstack logs :).

Also, in issue #191 you've mentioned having an agent for error and statistics reporting. what about that?

[lukego]

Does OpenDaylight have an agent? If not then we shouldn't need one either. If they do then perhaps I will accept that we do need one after all :-).

I dislike the RabbitMQ infrastructure connecting our own components together. I would be happier if we had a "perimeter" around our code where all the message queue infrastructure stops. Then we only need to troubleshoot MQ for talking with OpenStack and not for internal communications in our own code.

I don't know how #191 should report on errors/statistics but I am not imagining this as something on the critical path for being able to boot a VM, like the other agent stuff we are talking about.

[lukego]

If you send a pull request with a tidied up version of your Snabb Agent then we can look seriously at merging that. I would like to take that discussion 100% on pull-request / mailing list without referring to code that's only on Bitbucket please.