Open Stack

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.