On 01/04/2017 07:31 PM, Clint Byrum wrote:
Excerpts from George Shuklin's message of 2016-12-26 00:22:38 +0200:
Hello everyone.
Did someone actually made Ironic running with ToR (top rack switches)
under neutron in production? Which switch verdor/plugin (and OS version)
do you use? Do you have some switch configuration with parts outside of
Neutron reach? Is it worth spent efforts on integration, etc?
We had an experimental setup with Ironic and the OVN Neutron driver and
VTEP-capable switches (Juniper, I forget the model #, but Arista also has
models that fully support VTEP). It was able to boot baremetal nodes on
isolated L2's (including an isolated provisioning network). In theory this
would also allow VM<->baremetal L2 networking (and with kuryr, you could
get VM<->baremetal<->container working too). But we never proved this
definitively as we got tripped up on scheduling and hostmanager issues
running with ironic in one host agg and libvirt in another. I believe
these are solved, though I've not seen the documentation to prove it.
Few weeks later I can answer may own question.
Most of vendor drivers for Ironic suck. Some of them do not support
baremetal ports, others have issues with own devices, or have no support
for newer openstacks.
Nonetheless, there is a great 'networking_generic_switch' ML2 driver
which can do everything needed to run Ironic with tenant networking. It
so well-written, that adding new vendor is bearable task for average
admin. Switch description is just ~15 lines of code with switch-specific
configuration commands.
Ironic should be at least Newton to support multitenancy.
And it has plenty of bugs, most of which are obvious to fix, but show
that no one ever done production deployment before (or done, but patched
it by oneself and kept that patch out of public).
And one more question: Does Ironic support snapshotting of baremetal
servers? With some kind of agent/etc?
I think that's asking too much really. The point of baremetal is that
you _don't_ have any special agents between your workload and hardware.
Consider traditional backup strategies.
But we already have cloud-init in baremetal instances. Why it can't be a
cloud-backup? Main advantage of openstack-based snapshots for baremetal
is to have 'golden image' creation. You press button, and your server
become image. And that image (with proper cloud-init) can boot as VM or
as baremetal. Convergence at it highest point.
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
