Merge lp://qastaging/~yorik-sar/nova/dumb-nics into lp://qastaging/~hudson-openstack/nova/trunk

This looks like it could be useful, but I'm not sure if it will be needed after trey's multinic patch comes in. I've requested a review from him to see what he thinks.

Unfortunately, I didn't see his work earlier. I'll look deeper into Trey's branch. But it looks like he have ceased development for 3 weeks now without merging into trunk.
Multinic feature became very essential to us, so we're cutting edges on it. But, I guess, if Trey's branch is suitable enough, I'll put all my efforts into making it work.

Yuriy, are you making the observation that you need multiple nics attached to a single bridge or just that you need multi-nic very soon and that the was simplest way you could swing it?

Also, nova multi-nic will be in long before the next release, if that helps your situation.

It was the simplest way to run a machine with several NICs attached. Distributing NICs between different networks would require some heavy changes in almost every level of the system, so that they would be not so dumb. Dumb NICs solution suites our needs enough right now.
After that I suspended work on multi-nic since I found out that your progress is great and your branch is under active development.
Actually, I had couple of questions about design of your multi_nic implementation, wrote them in feedback request under multi_nic blueprint.

*takes a look*

If multi-nic is merged in the next few weeks, are you comfortable dropping this branch?

Took a look at your feedback. I prefer the ability to track an instance's fixed IPs. If I read you correctly, you don't like the db model associations. I dislike them also. Part of what I've done with multinic is to stop referring to db model associations so that in the future the tables can be separated without causing horrible trouble.

example:
instance['fixed_ips']
exists (for now), but prefer to use
self.db.fixed_ip_get_all_by_instance(instance_id)

This way if in the future network is looking at a table that doesn't contain instances, it can still look at the fixed_ips table, which has a column relating a fixed_ip to an instance_id passed in from compute.

Also note that the MacAddress table is basically what you are suggesting by virtual_interface. I chose to call it MacAddress instead of VIF, and I'm regretting that decision. I have a feeling I will probably change it before this is all said and done.

I've tried to describe my view of ideal world with totally decouple network service, where we have relations like these:

<network> 0..1 <---- oo <port> 0..1 <--- 0..1 <vif> oo ---> 1 <instance>

and <fixed_ip> 0..1 ---> 0..1 <vif>

Where <port> along with <network> model sit in core network (L2) service, <fixed_ip> appears from some L3 plugin for it (e.g. virtual DHCP server), and <instance> with its <vif>s are placed in nova core. Obviously, MAC address here belongs to <vif> and should be globally unique.
In this scheme instance is created with several vifs, connected to some abstract ports in L2-networks (request for this ports being made to external network service). Some of this networks can be associated with L3 plugins like this fixed_ip one that associate its IPs to VIFs (actually, to their MAC addresses).
So, to achieve such level of decoupling we should not have reference from VIF to fixed_ip or network.