[FEAT]: Notification webhooks and more

[via-justa]

Feature Description

Thanks for the amazing tool. I just installed and started playing with it and I can already say I'm sure that it's just a matter of time until this this tool becomes a common name in the home lab community

Here are a few small features that I think the tool can benefit from.

Monitoring

Webhooks notifications

At the moment, you provide the ability to send alert notifications by email or as a UI notification.
It would be beneficial to allow setting alert webhook so external tools can be used for notifications.

I for example use Grafana Oncall for alerts and all my services are sending JSON alert for triggers and resolutions to a webhook endpoint.

Monitor mounts not under /mnt

There are use cases mounting disks under /mnt is undesirable. Having the ability to see those mounts can be a huge improvement.
Getting the mounts from /etc/fstab can make it easier to locate all the mounts

I did try to trick the system with -v /path/to/mount:/mnt/name but it did not work

Home panel

The home panel is maybe the part I like the most. That said, I think it can include some more features like

• Disk usage metric (for home media server, in my opinion, it's the most important part to monitor)
• "Calculated" system status. I.e., If there are any recognized issues based on configured alerts

ServApps

• The ability to export the backup as Yaml. For people less technical, JSON is unreadable
• It would be nice if we could view the backup file instead of only download it. Not strictly needed but a nice to have

Others

• Dark mode and theme based on system like GitHub does can be nice.
• Native file browser (I saw in another issue you are working on it so a plus one from me for the feature)
• It would be nice if the disks view would hide snap disks (/mnt/host/snap/loop*)

[azukaar]

webhook monitoring

Definitely yes, I was actually thinking about adding those but it's just not super high priority

Monitoring mounts not under /mnt

DO NOT Mount things outside of /mnt, it's the point of the folder to mount things into it. I'd be curious about such use case where it's undesirable, but unless convinced otherwise, for now the policy is mounts go to /mnt

Dashboard

I plan to have a home-assistant -like dashboard system, with full customization available as json file (as in defining your dashboard in term of icons, widgets, etc.. as a json file)

Servapps backups

JSON vs YAML is used semantically to have a clear division between docker-compose and cosmos-compose, it makes it clear which tools generated or which tools is file is destined to (althought they are mostly the same)

View Backup file

You can see individual's containers backup files in the compose tab of each container

other
It already has dark theme, it follows the browser setting
file browser is definitely a planned and high priority item
I was not aware that snap packages were showing up as disks, thanks for reporting

Summary of actionnable items (for now, and not documented in other tickets)

• Hide snap disks
• Webhooks for alerts

[via-justa]

Hey @azukaar, thanks for the speedy response.

For the mount, I use a secondary disk (faster NVMe) for my home folder as I format the computer more often than I should and would like higher performance working on my files.
Other valid use cases are storing logs in /var/logs or application data of apps that don't provide the ability to change the path of in a different disk.
I'm sure I can find more use cases. I used to be a Sys Admin of bare metal servers. It wasn't uncommon to mount disks in other locations. The only times I personally use /mnt is when I mount external devices like a flash drive or external disk.

I plan to have a home-assistant -like dashboard system, with full customization available as json file (as in defining your dashboard in term of icons, widgets, etc.. as a json file)

That sounds amazing!!! I'm defiantly looking forward to it.

JSON vs YAML is used semantically to have a clear division between docker-compose and cosmos-compose, it makes it clear which tools generated or which tools is file is destined to (although they are mostly the same)

I accept your decision in that regard although I think that from UX perspective, allowing the user to view the files in a more human readable meaner makes more sense.

It already has dark theme, it follows the browser setting

At the evening, after posting I saw it. As I wrote, I literally just started playing with it. I expected to see the regular sun, moon, half and half icons I got used to on sites or display settings under the configurations, as I haven't seen any settings, I assumed it's not there. My bad.

Just out of curiosity, was there a reason you decided to create your own struct instead of expending the docker compose struct? Same goes for most other structs you create in the api_blueprint.go file
I'm asking as your implementation removes some functionality and in the long run will be harder to keep in track with new docker features.

[azukaar]

I did initially use te docker compose struct, I do not remember why I stopped, I think I was having issues (de)serializing back and forth the container

[via-justa]

Roger.

If you open a "buy me a coffee" or something else that accepts PayPay/ApplePay, I would gladly donate (Honestly I don't understand why GitHub removed PayPay as an option). It's a very nice work you're doing here and I would love to support you.

Hopefully soon I'll have some free time and I'll be able to work a bit on the Go code if you want.