On an Opensuse TW 5.0.5-0 version, I had to restart a Rockstore reinstallation, following some unfortunate manipulations in ACL and PAM management. After the traditional long wait for the update (see “Updating (Testing) from 5.0.4-0 to 5.0.5-0”), I recovered almost all my resources and plugins, following the few recovery operations described in the manual. Functionally, the plugins (Rockons) are operational, see the list of docker containers in services :
However, it’s impossible to recover the visualization of these containers in the visualization of the WEB-GUI Rock-ons page, which remains completely empty with the message “There are no Rock-ons installed currently.”
How can I go about bringing up the containers in the “Rock-ons” management, so that I can modify and adapt the configuration parameters of these extensions?
I’ve created an independent storage resource for the plugins, I can read and modify this directory which I’ve mounted in /mnt2/Rockext/ but I’m having trouble finding the directories and configuration files for these containers!
Another question: (but I think it’s more of an Opensuse question)
I lose my VGA console (ditto in HDMI) after putting the machine in sleep mode systemctl suspend, then a WoL resume (or anything else for that matter). I only find it again after a full reboot, but it’s much less convenient. Is there any way of getting out of standby mode while keeping the physical console?
@philuser, I think you did, but just for clarification, you used the backup/restore options to rebuild your box (along with the pre-requisites the pool imports, Rockon root stuff, etc.)?
@Hooverdan, For almost everything, yes, but I hadn’t taken the time to make a backup before I lost access to the interface, so I wasn’t able to restore. That’s certainly what I’m missing, I’m still surprised that all my containers work. If I don’t have any other alternatives, I’ll just delete my containers before regenerating them in the interface. But is this really the best choice? Wouldn’t it be better to manage containers directly with docker, if you have experience of docker/podman microservices?
Ah, ok that unfortunately explains it. The Rockon facility uses the underlying database to first store the docker definition and parameters (e.g. ports or shares that need to be specified) and second during installation store the defined parameters (actual ports or shares configured by the user).
Unfortunately, since you couldn’t make a backup before losing the interface, that connection is lost during the reinstall. Thus far, we don’t have any functionality that would allow to inspect the Rockons (aka underlying docker containers) and retrofit that information back into the database.
you could use the docker inspect to figure out your current (and, well, past) setting, if you don’t exactly remember what they were, but to have them exposed in the UI, I believe, your only option is to set them up anew via the WebUI, after removing the current instances, so you don’t run into duplicate container naming issues.
Not sure, how often you mess with your config, but if it’s not too often, then taking a configuration backup that you store someplace else might be good. Of course, not helping with your current problem…
Thank you for all your comments, which have given me a good idea of what to do next and how to get my containers back on track.
Is there any documentation explaining how and where rockstore manages its underlying information base?
With the docker, update, exec commands and others, I’ve been able to adapt the operation of my containers, to already retrieve some of the data stored in them, but also to match my new arrangements.
I’m curious and very interested to understand more deeply how rockstor handles this, possibly manually pulling up the information to restore my containers in rockstore. Is the documentation to do this accessible?
Glad to hear you made some progress and hopefully a path to full recovery of your settings.
@Flox did publish the Rockon framework implementation after some changes that he had implemented. I believe, bar some bug fixes and enhancements, the framework still holds up even though the post is from a few years ago. You can read about it here:
