Allow a single BMC to manage multiple BMs

[steveb]

This change creates a single BMC server and uses that to manage multiple baremetal servers.

It does this by using a naming convention on the BM and BMC neutron ports and using that to match a BMC port to a BM nova server.

In the BMC boot script a separate systemd unit is created per network interface, and the IP address of that interface is used to bind to instead of ::. This requires a small change to pyghmi which has been proposed upstream Ice82bf788269a31819e4495e15b9ce19a1dd057b. Until this lands upstream pyghmi is installed from my github fork.

Other approaches were considered:

• multiple neutron ports, single openstackbmc bound to ::, this would require switching the pyghmi socket recv function to recvmsg to get the receiving IP address, but recvmsg isn't available in python 2.7
• single neutron port, single openstackbmc, modified pyghmi to select based on different bmc username/password. This looks impractical based on the assumptions the pyghmi auth code makes.
• single neutron port, multiple openstackbmc units each bound to a different UDP port other than 623. Impractical without many changes to Ironic which assumes 623.

[cybertron]

Hmm, my initial testing went well, but when I tried to create a larger stack with this change it seems to have tickled https://bugs.launchpad.net/neutron/+bug/1515768 :-(

Not sure what to do about that (other than fix the bug, of course). The breaking point seems to be about 10 overcloud nodes - much more than that and the bmc fails to come up because of the bug. This would be sufficient for CI, but does mean that any kind of scale testing with this would no longer be possible.

[cybertron]

Okay, I am having significant problems with the BMC networking with a bunch of interfaces, so I've pushed a feature branch including this commit and a proposed alteration to it (details in the wall of text commit message): https://github.com/cybertron/openstack-virtual-baremetal/commit/94361331954464b4ade4e8d50b546f108abc0e62

Can you take a look and see what you think? I'm not 100% sure it's a complete solution, but it's working much better for me (I was able to boot a 14 node stack and talk to them all cleanly via their respective BMC services). There's a bunch of cleanup that needs to be done before it merges to master, but I think you can get the idea. Thanks.