For the latest staypuft release, we're configuring per-host fencing using
the bmc_nic associated with the host – so the params fencing_enabled?,
username, password, and ip address are all coming from the bmc nic object.
If there is no bmc nic at all, we're not currently supporting fencing. At
the moment we're only supporting IPMI, so this works for us.
Unfortunately, this nic-based model doesn't work so well for fencing
methods not based on network interfaces (bladecenter, virt-based fencing in
ovirt/RHEV, VMWare, etc.)
So the question is what changes do we need to make to foreman to support
per-host fencing configuration in a less nic-dependent way? Should some of
the fencing metadata move to the host itself, or onto some other
intermediate object? Instead of directly accessing @host.bmc_nic, perhaps
we should have something returned by @host.fencing_obj (or whatever) which
tracks fencing type (bmc, RHEV, bladecenter, etc) and either stores the
metadata directly or has accessors that know how to find the required
metadata for nic-based fencing like IPMI, as well as the non-nic-based
fencing for rhev, bladecenter, etc.
to be honest I don't have much experience in that area and I know only network
based BMC. I'd be interested in how do they work, I think you always need some
kind of network communication.
Anyway if it does not make sense to have the associated subnet or even IP I
think we should introduce new model - e.g. Fencing. Host model has too much
responsibilities already. Fencing could support multiple adapters using STI,
suclasses would handle the underlaying implementation details either using
Nic::BMC or any other object (ComputeResource maybe?). The shared parent class
(Fencing::Base?) would define an interface for tasks like "power on".
Also I'd say that while Fencing object may still belong into foreman core,
specific implementation should probably be pluginized.
I'd also like to hear opinions of others that have more experience in this
area.
For the latest staypuft release, we’re configuring per-host fencing using
the bmc_nic associated with the host – so the params fencing_enabled?,
username, password, and ip address are all coming from the bmc nic object.
If there is no bmc nic at all, we’re not currently supporting fencing. At
the moment we’re only supporting IPMI, so this works for us.
Unfortunately, this nic-based model doesn’t work so well for fencing
methods not based on network interfaces (bladecenter, virt-based fencing in
ovirt/RHEV, VMWare, etc.)
So the question is what changes do we need to make to foreman to support
per-host fencing configuration in a less nic-dependent way? Should some of
the fencing metadata move to the host itself, or onto some other
intermediate object? Instead of directly accessing @host.bmc_nic, perhaps
we should have something returned by @host.fencing_obj (or whatever) which
tracks fencing type (bmc, RHEV, bladecenter, etc) and either stores the
metadata directly or has accessors that know how to find the required
metadata for nic-based fencing like IPMI, as well as the non-nic-based
fencing for rhev, bladecenter, etc.
