Hi Henrik,

That makes sense to me. We have been considering a single control node for this, but need to do more planning if that one node fails. Perhaps a single DB, multi control node is an easier recovery than 1 controller. 

Thanks! 
Michael 



On Sat, Sep 21, 2024 at 6:19 AM Henrik Hansen <hhansen06@googlemail.com> wrote:
Hey Michael,
kolla deploys (in a multinode scenario) a galena cluster. therefore it
needs to be sure that all nodes have the same content before the
cluster starts, thats by design.
But if all of your nodes are in the same Pelican Case (i'm really
interested in the use case) you could simply deploy your database on
only a single node. Then the database would survive a shutdown /
coldboot scenario.

Am Sa., 21. Sept. 2024 um 01:24 Uhr schrieb Michael Knox <michael@knox.net.nz>:
>
> Hey Folks.
>
> I am working through a scenario that requires us to have Openstack in a Pelican Case and deployed in the "field" on a semi regular basis. I guess, portal "edge cloud" if you will? The problem I am trying to clean up is the startup process. We use kolla-ansible and rocky with zed (though we have one with ubuntu and wallaby) in this specific use case.
>
> We do the shutdown nicely, kolla-ansible -i inventory stop, then power off the control nodes (we have 3 in the setup). The problem is on the start up. All the containers start  and then we still *have* to run the kolla-ansible -i inventory mariadb_recovery step to get the cloud back into a usable state. No matter the order of shut down or start up, MariaDB seems to always need a recovery.
>
> Are there any people here doing this or something similar? Is there a more efficient startup process I am not aware of or should consider? The folks in the field aren't Openstack admins, so hoping to figure out a solution that is less dependent on their knowledge of Openstack's undercloud tooling.
>
> Thanks in advance
> Michael



--
Mit freundlichen Grüßen
Henrik Hansen