Cisco Openstack

Bug #1164812
Comment #10

Comment 10 for bug 1164812

Revision history for this message

Ian Wells (ijw-ubuntu) wrote on 2013-06-19:

#10

Right, since we're back at the analysis phase, let me lead you through the problem in steps:

- /etc/network/interfaces is applied. bonds are made, interfaces are alive, one of them has the address we care about if you put it in interfaces on the component interface
- openvswitch starts via the startup scripts.
- OVS creates switches and adds ports. In creating switches, the switch interfaces turn up. Unfortunately it doesn't bother to run ifup for those interfaces, so any /etc/network/interfaces config for them is ignored. If you instead elected to put the config on a component interface, then the DNS / gateway config holds true, but the IP address is now on an interface in a bridge, that interface (being in a bridge) never receives packets to the kernel stack - they're all fed to the bridge interface instead - and you can't, therefore, contact any addresses it may have.

The original fix was to run a script after OVS startup to transfer all addressing information from the component interface to the switch interface. Unfortunately, because OVS is asynchronous, the switch interface often hasn't been created at this point and the transfer of information fails.

The right fix would be, I think, either to find a hook out of the OVS management software to call to a script to transfer the interface, or, better, to run ifup on the interface as you would for any other interface so that /etc/network/interfaces information would be taken up. This still has a shortcoming, in that, during the initial puppet run, you need an addressable interface; if that interface is put into a switch then its address becomes inaccessible; problems as above, plus you've cut yourself off from the puppet server. This could be fixed with some very specific puppet to the circumstance in question, but it's hard to see how you could write puppet that makes sense in the context of puppet. Perhaps it would explicitly unconfigure the component interface then configure the bridge per the interfaces file? Whatever, a simple address transfer doesn't really make any sense unless it happens in conjunction with an interfaces file change.

Fixes need to address all the problems listed here. And work on Redhat, which I've not looked at.

Right, since we're back at the analysis phase, let me lead you through the problem in steps:

- /etc/network/interfaces is applied.  bonds are made, interfaces are alive, one of them has the address we care about if you put it in interfaces on the component interface
- openvswitch starts via the startup scripts.
- OVS creates switches and adds ports.  In creating switches, the switch interfaces turn up.  Unfortunately it doesn't bother to run ifup for those interfaces, so any /etc/network/interfaces config for them is ignored.  If you instead elected to put the config on a component interface, then the DNS / gateway config holds true, but the IP address is now on an interface in a bridge, that interface (being in a bridge) never receives packets to the kernel stack - they're all fed to the bridge interface instead - and you can't, therefore, contact any addresses it may have.

The original fix was to run a script after OVS startup to transfer all addressing information from the component interface to the switch interface.  Unfortunately, because OVS is asynchronous, the switch interface often hasn't been created at this point and the transfer of information fails.

The right fix would be, I think, either to find a hook out of the OVS management software to call to a script to transfer the interface, or, better, to run ifup on the interface as you would for any other interface so that /etc/network/interfaces information would be taken up.  This still has a shortcoming, in that, during the initial puppet run, you need an addressable interface; if that interface is put into a switch then its address becomes inaccessible; problems as above, plus you've cut yourself off from the puppet server.  This could be fixed with some very specific puppet to the circumstance in question, but it's hard to see how you could write puppet that makes sense in the context of puppet. Perhaps it would explicitly unconfigure the component interface then configure the bridge per the interfaces file?  Whatever, a simple address transfer doesn't really make any sense unless it happens in conjunction with an interfaces file change.

Fixes need to address all the problems listed here.  And work on Redhat, which I've not looked at.