<div dir="ltr"><div>Yes, you could think of our use case as an appliance.  I'm being intentionally vague about the actual implementation, but the underlying requirement to build an arbitrary cluster configuration off-line, or pre-boot, is the key thing we're looking for help with.</div><div><br></div><div>Craig<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 14, 2020 at 2:05 PM Strahil Nikolov <<a href="mailto:hunter86_bg@yahoo.com">hunter86_bg@yahoo.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On April 14, 2020 9:46:14 PM GMT+03:00, Craig Johnston <<a href="mailto:agspoon@gmail.com" target="_blank">agspoon@gmail.com</a>> wrote:<br>
>Hello,<br>
><br>
>Sorry if this has already been covered, but a perusal of recent mail<br>
>archives didn't turn up anything for me.<br>
><br>
>We are looking for help in configuring a pacemaker/corosync cluster at<br>
>the<br>
>time the Linux root file system is built, or perhaps as part of a<br>
>"pre-pivot" process in the initramfs of a live-CD environment.<br>
><br>
>We are using the RHEL versions of the cluster products.  Current<br>
>production<br>
>is RHEL7 based, and we are trying to move to RHEL8.<br>
><br>
>The issues we have stem from the configuration tools' expectation that<br>
>they<br>
>are operating on a live system, with all cluster nodes available on the<br>
>network.  This is obviously not the case during a "kickstart" install<br>
>and<br>
>configuration process.  It's also not true in an embedded environment<br>
>where<br>
>all nodes are powered simultaneously and expected to become operational<br>
>without any human intervention.<br>
><br>
>We create the cluster configuration from a "system model", that<br>
>describes<br>
>the available nodes, cluster managed services, fencing agents, etc.. <br>
>This<br>
>model is different for each deployment, and is used as input to create<br>
>a<br>
>customized Linux distribution that is deployed to a set of physical<br>
>hardware, virtual machines, or containers.  Each node, and it's root<br>
>file<br>
>system, is required to be configured and ready to go, the very first<br>
>time<br>
>it is ever booted.  The on-media Linux file system is also immutable,<br>
>and<br>
>thus each boot is exactly like the previous one.<br>
><br>
>Under RHEL7, we were able to use the "pcs" command to create the<br>
>corosync.conf/cib.xml files for each node.<br>
>e.g.<br>
>      pcs cluster setup --local --enable --force --name mycluster node1<br>
>node2 node3<br>
>          pcs -f ${CIB} property set startup-fencing=false<br>
>          pcs -f ${CIB} resource create tftp ocf:heartbeat:Xinetd<br>
> service=tftp  --group grp_tftp<br>
>          etc...<br>
><br>
>Plus a little "awk" "sed" on the corosync.conf file, and we were able<br>
>to<br>
>create a working configuration that worked out of the box. It's not<br>
>pretty,<br>
>but it works in spite of the fact that we feel like we're swimming up<br>
>stream.<br>
><br>
>Under RHEL8 however, the "pcs cluster" command no longer has a<br>
>"--local"<br>
>option.  We can't find any tool to replace it's functionality.  We can<br>
>use<br>
>"cibadmin --empty" to create a starting cib.xml file, but there is no<br>
>way<br>
>to add nodes to it (or create the corosync.conf file with nodes".<br>
><br>
>Granted, we could write our own tools to create template<br>
>corosync.conf/cib.xml files, and "pcs -f" still works.  However, that<br>
>leaves us in the unenviable position where the cluster configuration<br>
>schema<br>
>could change, and our tools would not be the wiser.  We'd much prefer<br>
>to<br>
>use a standard and maintained interface for configuring the cluster.<br>
><br>
>Any suggestions would be very welcome.  While we have a non-standard<br>
>use-case, we don't believe it is unrealistic given the current<br>
>environment<br>
>for cloud services, and automated deployment.<br>
><br>
>Thanks,<br>
>Craig<br>
<br>
I guess I'm a  little bit narrow-minded , but I don't get the whole concept.<br>
<br>
Why should you need to use  a ' pre-pivot" process in the initramfs of a live-CD environment.'   ?<br>
<br>
Can't you just pull the configuration from a central location (lile salt, puppet or just a plain http server ) ?<br>
<br>
Are you trying to build an apliance that selfdeploys without human intervention ?<br>
<br>
Best Regards,<br>
Strahil Nikolov<br>
</blockquote></div>