Open TapGhoul opened 4 months ago
/attempt #2708
with your implementation plan/claim #2708
in the PR body to claim the bountyThank you for contributing to coollabsio/coolify!
Add a bounty • Share on socials
Attempt | Started (GMT+0) | Solution |
---|---|---|
🟢 @LEstradioto | Jun 28, 2024, 12:29:54 AM | #2710 |
Couple extra notes - these are out of scope for the most part, but are relevant to my error logs, and may be nice to add a message for:
transactional-update
to be invoked on MicroOS unlike Tumbleweed, so trying to remedy that manually can cause issues. Either the podman socket should be enabled and used, or it should be a hard failure and require the user install Docker themselves. If it can be detected if it's MicroOS vs standard Tumbleweed (I'm sure there's a way, zypper can detect it) then this may be a safe operation to perform. Could also just check zypper's exit code./attempt #2708
Algora profile | Completed bounties | Tech | Active attempts | Options |
---|---|---|---|---|
@LEstradioto | 2 bounties from 2 projects | Cancel attempt |
Edit: I should’ve looked at the PR first, it does everything I wanted already!!
Oh hey! This is pretty much the exact same request as I would make! Unlike the OG poster and adder of the bounty (thank you for that!) I mainly deploy on CoreOS. One thing that I think may be a help, and I don't wanna complicate things too much, but on my read on the install script (I'm not the best at bash so please let me know if I'm wrong) it just attempts to install all the prerequisites. Given that it may actually be kinda difficult to install all the prerequisites in the script, a flag to skip their installation and get right to the setting up of coolify would be ideal as well. As on CoreOS right now, it is failing on line 94, attempting to install git, wget, and jq. (It's doing so because CoreOS does not have DNF or Yum, but uses RPM-ostree, honestly it'd be easier on y'all's end to let us weirdos using immutable systems just make sure the prerequisites are already installed than to try and install them in the script. Or at least that's the path of least resistance I see.
Description
OpenSUSE MicroOS has an immutable filesystem, with a few specific directories mounted as read-write - /etc, /var and /home. As coolify tries to install itself to /data, which is in a read-only location, it cannot be installed via the standard scripts. While this can be modified by customizing the paths during manual install, the automatic update mechanism built into coolify doesn't know how to handle this correctly.
What should ideally happen is at the very least, if updating from the UI, it should know where it is installed to and change the base data directory. This is already somewhat possible via by setting
BASE_CONFIG_PATH
in the docker environment, but this does not cover installation or updating. Existing work can be seen at https://github.com/coollabsio/coolify/blob/e9158b7305bb9253fe75a0e76ef34af62f75199b/config/coolify.php#L13 and usages of this code.A nice "cheat" here may be to allow the installer to put everything into a docker volume, or spin up a basic container and perform the installation with the volume attached to it, to then transfer to the real coolify instance.
There is also the issue of no podman support, but this can be worked around by just installing docker into MicroOS if absolutely needed, with an asterisk in the docs about this, so it need not be part of the solution to claim the bounty. Some docs would be nice, though, as even the
BASE_CONFIG_PATH
bit is undocumented currently.Minimal Reproduction (if possible, example repository)
Start a VM based off of https://get.opensuse.org/microos/ - the self-installing host, or the "KVM and XEN Container Host" images both work great here on linux, but there's other platforms too. Install to the disk (if you didn't pick an existing FS image) Attempt to run the coolify installer, even after installing prerequisites manually - fails. Perform a manual install via manual steps... Sorta works, but update script will break.
Note: you can get it to install under a transactional-update context, but this goes against the purpose of having a container host OS. With a privileged container, the volume can re-deploy itself from within the container. Though I'm sure there's other more elegant options.
Exception or Error
Version
v4.0.0-beta.306