Indeed this is more powerful than it looks on a first glance.
But i'm thinking about how to provide a UI for that because the whole OMV UI is done in a declarative manner, so it should be easy to provide that for container based plugins as well.
With an easy to use UI on top of this it might get pretty close to what I imagined initially. Thanks for elaborating, I'm excited for the things to come on Kubernetes.
Thanks for your active participation in this discussion, especially to Volker - very interesting to hear what's on your mind for the future with Kubernetes support and the related recipes!
mergerfs + snapraid give you this and very simple yet satisfies most users requirements.
When I mentioned the two core features, I thought about it more as a native feature in OMV itself. To support only one solid file system with modern features like snapshots and storage pools primarily and other ones as extensions for example. Maybe OMV isn't far from this today, I'll definitely give those two plugins a try, thanks for pointing in that direction.
Sounds like you haven't used OMV 7.x or even 6.x for that matter.
That's true, the last time I tried OMV Docker support was with the "old" Docker plugin. The Docker Compose plugin seems to be a easy and a good choice, I'll check this on OMV after upgrading to OMV 7.
I think storage management in OMV is good, but there is room for getting better. Keep in mind that OMV is done by myself and omv-extras.org by Aaron and other contributors. It is unfair to compare it with companies that have employees that work on it full-time. We do it in our spare time as a hobby.
I absolutely get that and really appreciate your efforts and consistency over all the years.
OMV7 has now a Kubernetes plugin to run containers in a K8s environment without the need of Docker or Podman. I've also started a repository for it to collect recipes to easily install container apps from Helm Charts or K8s API resources. Standalone plugins require much much much time and maintenance. Therefore container based apps are much easier to maintain. The sad thing is that they need to be managed via Yaml and are not integrated very well in the UI. But i'm thinking about how to provide a UI for that because the whole OMV UI is done in a declarative manner, so it should be easy to provide that for container based plugins as well.
I've seen the repository for the Kubernetes recipes but wasn't aware that this goes in the direction of being a possible successor for Docker Compose extensions. From what you describe it pretty much goes in the direction I have thought of.
For a lot of people it might be daunting to deal with the concepts of Kubernetes. However for other people it might be a huge benefit to be able to control the Kubernetes ressources as they need it. To serve both audiences it might be the best to serve an easy to use way over the UI ("one click") with reasonable defaults (your idea of recipes?) while in an extended view the raw Kubernetes ressources could be displayed and edited.
To populate and increase this Kubernetes recipes it requires active participation of the community. When it comes to plugins/apps, i think this is the way to go because it reduces the implementation and maintenance time of apps/plugins.
Definitely, since the most features and apps already exist as Docker images out there. When I got the idea of recipes right you "only" have to put the things together in a recipe to run it on OMV. This is pretty much the idea of a Helm chart. Do you think this might be an option, too as replacement for recipes or are you afraid that the complexity will get higher when incorporating Helm?
I think that OMV made the right decision when it moved more to docker containers, which to me means the maintainers of OMV and OMV-Extras can spend more time on that code, and we get the best of both worlds.
I second that. No matter if it's Docker, Docker Compose, Kubernetes or Helm in the end. The important thing is to support Containerization in an easy and inuitive way with the ability to install/deploy "server-side apps" and without the hazzle of YAML files and ressource definitions (if you don't want or aren't able to).
Hi OMV-Community,
I'm a OMV user and fan since the first hour and appreciate all the history, development and efforts of this beautiful project.
In the recent time I often noticed that when people requested different features as a plugin the community reacted: just use Docker for this. This is a natural reaction since Docker / Containerization became the de facto standard of "server side apps". This trend seems to reflect in the plugin selection. There are a few plugins remaining but for the most interesting features the way seems to be to check for a respective Docker Compose snippet.
Besides this observation I encountered an issue when a big part of my network share (folders + files) suddenly disappeared. This happens occassionally and luckily enough a simple restart fixes this problem. I don't judge OMV for this, maybe it's an integrity problem caused by hardware, etc. Nevertheless it's quite concerning when a huge part of your data suddenly disappears. That made me curious for NAS software in 2024. The big players seem to be OMV, TrueNAS and Unraid.
When watching some videos about Unraid and reading some blog posts, it took me quite a while to realize what the success factors / the reasons for the hype around Unraid are.
* Simple creation and management of solid storage pools with parity features out of the box
* Native (first class?) Docker support, shipped as predefined "server side apps"
After a while I came to the conclusion that these two capabilities are pretty much the core features for me that make a NAS interesting. For sure this is only one single perspective and this is achievable with OMV, too. On the other hand I'm convinced that a system gets incredibly powerful by solid/simple core features and a vast variety of extensions.
You might ask: why don't you just switch to Unraid then? Well, I'm still a huge OMV fan and really disagree with a proprietary solution for all my data (no, it's not the pricing/license fee).
What do you think about the focus on this two core capabilities of a NAS solution? Is it a valid view for the future of OMV or is my point of view to specific/biased?
I'm aware this is a rather provocative and sensational question and might evoke emotions. Nevertheless I ask you for a discussion in substance.
Cheers
InTheNoon
Hey there,
a few years ago I decided to build my own NAS. First it was running FreeNAS, afterwards Windows Home Server and then Ubuntu + MythTV for a long time. Week for week I checked the OMV Website - waiting for the release. As it was there finally, I wasn't hesitating and installed it immediately. And I never regret it so far! 
Here it is:
Hardware
CPU: Intel Atom N550 @ 1.5GHz
RAM: 2GB Corsair
SSD (System): 128GB
HDD (Data): 3 TB, 2TB
HDD (Backup): 2TB
Case: Fractal Design Array R2
Other: Satelco DVB-S Card
Software
OS: Debian/OMV 1.5
Storagemanagement: LVM2
Fileserver: SMB/CIFS
Backup: RSync backup to local attached USB drive, duplicity backup to Google Drive
TV: TVHeadend (Backend), XBMC (Clients)
Thanks to all OMV developers and contributors for enabling the running this box!
Regards
InTheNoon
