Future of OpenMediaVault

  • 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

  • ryecoaaron

    Hat das Thema freigeschaltet.
    • Offizieller Beitrag

    n 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.

    This topic has been beat to death. The only plugins that are really missing are the downloader plugins and they were just on/off switches with links to the services web interface. Docker isn't always about the severe lack of time that the two people who work on plugins have (unraid has full time paid employees) but it is also about security and not having to corrupt the core OS with the unstable requirements that many of these services require.

    Simple creation and management of solid storage pools with parity features out of the box

    mergerfs + snapraid give you this and very simple yet satisfies most users requirements.


    Native (first class?) Docker support, shipped as predefined "server side apps"

    The compose plugin offers this in my opinion. It is a native plugin and the examples make it easy enough to create the server side apps.

    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?

    Sounds like you haven't used OMV 7.x or even 6.x for that matter.


    I'm aware this is a rather provocative and sensational question and might evoke emotions.

    I'm not going to let this thread get out of hand because they always repeat what other threads on the same topic do. They are almost always not productive.

    omv 7.0.5-1 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.13 | compose 7.2 | k8s 7.1.0-3 | cputemp 7.0.1 | mergerfs 7.0.4 | scripts 7.0.1


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    • Offizieller Beitrag

    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.


    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.


    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.


    Users have to choose then between Kubernetes and Docker. I'm in favor of K8s because it is much easier when it comes to network config. I hate the Docker approach. But thats my personal point of view.


    Finally, a ecosystem like OMV can only increase when the community is contributing. This is something that is sadly going lim x->0.

  • IMO OMV is a Debian based NAS and does an excellent job reliably serving my network. All the necessary plugins are there. I don't use Docker for anything because there aren't any core functions that need it.

  • requires active participation of the community.

    The forum has no Kubernetes category and with the amount of existing help and tutorials here for Docker, even if it did exist I doubt it would active. Following that, Kubernetes brings nothing new to OMV users, it simply asks to redo what has already been done with Docker.


    You've stated that you don't want a store like feature to enable a 1-click interface but, that's what a whole lot of people want. Well, that and apparently how to make the UI full width...


    I find the current plugin system too limiting as it seems you can't even add your Javascript. Admittedly, I haven't tried it so I could be wrong, but it looks like the leash is on the plugin system extremely tight.

    • Offizieller Beitrag

    I find the current plugin system too limiting as it seems you can't even add your Javascript.

    This is a unique selling point and a feature of OMV. The UI can be implemented in a declarative way via YAML which is much simpler than doing that in Javascript. This allows users to contribute without having the knowledge of Javascript, Typescript, Angular and aIl the other things that would be necessary. IMO the UI already provides everything that is necessary for this type of UI.

  • IMO Kubernetes is the future and much more powerful than Docker Compose. TrueNAS Scale is based on SUSE K3s for a reason.

    Got to say, I've looked at some Kubernetes video's and for me Docker is much easier for me to understand and my containers work well. The Compose plugin makes docker very easy to manage. Perhaps I'll have another look at Kubernetes again.


    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.

    • Offizieller Beitrag

    I like docker and kubernetes. They both have their pros and cons. k3s requires quite a bit more resources than docker and I think docker's storage is much simpler. k3s does scale better and can do many more things. I have also use kompose to convert docker-compose files to k3s manifests with little problem.


    While the declarative system in OMV 6/7 can be a bit limited occasionally, I have been able to implement all of the omv-extras plugins in a good way while saving a lot of time. I definitely prefer the declarative system over all previous versions of OMV.

    omv 7.0.5-1 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.13 | compose 7.2 | k8s 7.1.0-3 | cputemp 7.0.1 | mergerfs 7.0.4 | scripts 7.0.1


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • 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).

    • Offizieller Beitrag

    When I mentioned the two core features, I thought about it more as a native feature in OMV itself.

    A plugin isn't any less "native" in OMV. The zfs and lvm plugins provide snapshots as well. Borgbackup and rsnapshot provide a type of snapshot. Many users (including myself) do not use or need true snapshots or pools.


    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.

    The k8s plugin is not the successor of the compose plugin. They will coexist. Volker maintains the k8s plugin and I maintain the compose plugin. They both have their use cases and there is no reason to only have one. The compose plugin has 100 example compose files which require very few changes to use. and can be added right from the plugin like a store I know users want "one click" but those one click systems aren't really one click and you lose a lot of flexibility that true compose files offer.

    omv 7.0.5-1 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.13 | compose 7.2 | k8s 7.1.0-3 | cputemp 7.0.1 | mergerfs 7.0.4 | scripts 7.0.1


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    • Offizieller Beitrag

    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?

    Recipes are using Helm charts. I don’t want to create Helm charts, I want to consume them and that is very simple with k3s. Check out the FileBrowser recipe, it is based on a Helm chart. As you can see, the recipe uses only three resources to get this app running behind a reverse proxy with SSL certificate and subpath. The user only needs to file the shared folder path. Voila, that’s near to a one-click installation.


    Recipes are building on Helm charts if possible plus adding everything else that the chart does not provide to give the user a more or less one-click solution.

  • 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.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!