overcloud deployment misses automatic fencing configuration. user have to configure fencing manually after deployment is finished.
So this is doable today with liberty and ospd. What you need to do is create a yaml file like this: parameters: EnableFencing: true FencingConfig: { "devices": [ { "agent": "fence_ipmilan", "host_mac": "b8:ca:3a:66:e3:82", "params": { "delay": "20", "ipaddr": "10.1.8.102", "lanplus": "true", "login": "qe-scale", "passwd": "******" } }, { "agent": "fence_ipmilan", "host_mac": "b8:ca:3a:66:d6:da", "params": { "delay": "20", "ipaddr": "10.1.8.100", "lanplus": "true", "login": "qe-scale", "passwd": "******" } }, { "agent": "fence_ipmilan", "host_mac": "b8:ca:3a:66:dc:da", "params": { "delay": "20", "ipaddr": "10.1.8.94", "lanplus": "true", "login": "qe-scale", "passwd": "******" } }, { "agent": "fence_ipmilan", "host_mac": "b8:ca:3a:66:eb:ea", "params": { "delay": "20", "ipaddr": "10.1.8.107", "lanplus": "true", "login": "qe-scale", "passwd": "******" } }, { "agent": "fence_ipmilan", "host_mac": "b8:ca:3a:66:ee:2a", "params": { "delay": "20", "ipaddr": "10.1.8.105", "lanplus": "true", "login": "qe-scale", "passwd": "******" } }, { "agent": "fence_ipmilan", "host_mac": "b8:ca:3a:66:f1:b2", "params": { "delay": "20", "ipaddr": "10.1.8.104", "lanplus": "true", "login": "qe-scale", "passwd": "******" } }, { "agent": "fence_ipmilan", "host_mac": "b8:ca:3a:66:ef:5a", "params": { "delay": "20", "ipaddr": "10.1.8.106", "lanplus": "true", "login": "qe-scale", "passwd": "******" } } ] } Then you just need to pass -e fencing.yaml and after the deploy you will get one stonith device per host. In case of fence_xvm you can use something like the following: parameters: EnableFencing: true FencingConfig: { "devices": [ { "agent": "fence_xvm", "host_mac": "52:54:00:2d:bb:38", "params": { "multicast_address": "225.0.0.12", "port": "osp8-node1" } }, { "agent": "fence_xvm", "host_mac": "52:54:00:e9:f4:a8", "params": { "multicast_address": "225.0.0.12", "port": "osp8-node2" } }, { "agent": "fence_xvm", "host_mac": "52:54:00:9f:9f:3f", "params": { "multicast_address": "225.0.0.12", "port": "osp8-node3" } }, { "agent": "fence_xvm", "host_mac": "52:54:00:55:02:bb", "params": { "multicast_address": "225.0.0.12", "port": "osp8-node4" } }, { "agent": "fence_xvm", "host_mac": "52:54:00:8e:f9:36", "params": { "multicast_address": "225.0.0.12", "port": "osp8-node5" } } ] } Of course in this case the mapping macaddress-vm is very specific to my setup. I have started some work to output the yaml above automatically via a tripleo command called "openstack baremetal fencing export foo.yaml" here: https://github.com/mbaldessari/python-tripleoclient/tree/wip-fencing-support
No, automated fence agent configuration will not make RHEL OSP 8.
This bug did not make the OSP 8.0 release. It is being deferred to OSP 10.
what about constraints? will the yml file configure them so the fence resource will not be managed on the same controller they applied for? like: stonith-overcloud-controller-0 (stonith:fence_ipmilan): Started overcloud-controller-0
*** Bug 1194301 has been marked as a duplicate of this bug. ***
*** Bug 1340941 has been marked as a duplicate of this bug. ***
Can you please link the upstream patches in external trackers and update the component appropriately? Thanks
@Lukas: I'd probably replace "for automatic High Availablity" with "for easier High Availability" - I think the current wording suggests that this configuration generator somehow does magic for automating all of HA.
VERIFIED.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2017:1245