OMV 5 - So Confused

Zitat von cogitech

So in the end, Docker appears to be an incredibly complicated and wasteful way to avoid having to install and configure services from the command-line. If that's true, then I certainly don't need or want it.

Docker and container technology that is used in the industry and other products more and more.

Zitat von dziekon

he problem is that OMV doesn't have enough documentation nor its code base is easy to read and understand. In addition to that, anyone who wants to do anything is simply left on their own, because "you're supposed to learn the ways around like the rest of the old folks did". While I understand that it's mostly a time problem, everyone is doing this in their own free time, but using it as an excuse won't lead to anything other than stagnation. You can write as many explanations and excuses as you want, but it doesn't matter - it's just a fact, and the number of recent contributions from people other than the longtimers is the best argument supporting that. What this project needs is an easy way for developers to get to know project's internals, its mechanisms and flows. OMV is pretty complicated, so the easier this onboarding process is, the more developers will be willing to help.

I agree. I will be the first to say I don't have time to do more than I am doing. Do you have a solution or idea for any of these problems? I don't know how to fix the chicken and egg problem of we need more devs but we need more docs to get devs.

Zitat von dziekon

There's also a big problem of no clear path about release management, future plans, how bugs and tasks are managed, etc. Maybe if you dig deep enough into this forum, you'll be lucky to find anything meaningful by accident.

I know about them when they are released just like you.

Zitat von dziekon

or example, the migration process from v4 to v5, even though it's not official, should have been extracted into a separate, highly visible article a long time ago. Instead, people still ask about it and are still being redirected there once someone is kind enough to share a link.

Upgrades from 4 to 5 are not supported (not my decision). That is why there is no omv-release-upgrade or an official post on how to do it like previous versions. I came up with a process that works ok but I'm not making it a front and center post because I would rather people not do it.

Zitat von dziekon

Not to mention that people pointing out certain problems are being left with dubious and unfriendly answers (like the recent banter related to OMV 5's release notes or something similar to that). And don't get me wrong, I don't mean that everyone should love each other and barf rainbows, I'm simply saying that snarky answers to legitimate questions will drive people away

I will admit I have little patience for nitpicking. If I am preventing the project from growing by my actions, I would gladly hand over the work to someone else.

Zitat von dziekon

Again, you can say all you want about this project being available for free, that authors are not responsible for anything and so on as so forth, but at the end of the day, it's just a waste of everybody's time - people will get mad, you'll get mad and nothing will get fixed or developed. I'm pretty sure that some people will see this post in the same way.

Is it really that bad? Every solution seems to point to "spend more time and fix everything".

Zitat von dziekon

As for the mentioned REST API. I'm sure it won't be the "next big thing" in the plugins development process, but I believe that it's existence and the related refactor might be really beneficial to the codebase. It might clear it up a bit and make certain things much simpler than they are now. For example, the ZFS plugin uses certain built-in methods of the OMV itself. Having a REST API with good enough documentation, or even a well-documented service related to a specific endpoint, could help to make certain things easier for plugin developers. In addition to that, any UI-only plugin could potentially be developed in separation from the backend's code; or maybe some statistics-related plugins could consume these API endpoints on their own, living completely outside of the OMV's lifecycle as stand-alone services based on docker... who knows what fantastic ideas are being held back by the lack of a legitimate and easy to use interface.

I really like that idea.

Zitat von dziekon

However, that's not why I brought it up. I've mentioned it as an example of an initiative being developed "in the shadows" - there's no way of knowing what is its current development status, what's the plan, what's left to do or even how can anyone help with developing it.

I'm in the same boat about 99% percent of the time. But people can develop against the stable version. You don't have to develop against what's next.

Zitat von dziekon

As for the mentioned REST API. I'm sure it won't be the "next big thing" in the plugins development process, but I believe that it's existence and the related refactor might be really beneficial to the codebase.

OMV has a RPC service. It's not REST, but it works and can be used via HTTP.

Start developing or contributing to the project does not mean you need to know how the whole system works. If there is a problem you can digg into it and try to fix it. To do that it is NOT necessary to code a single line, simply find out what is going wrong, check the service config files, try to manually fix it, test it and open a bug report with a detailed description what is going wrong and how to fix it. The code to finally fix that can be done by someone else with deeper knowledge. But do you know how often this happens? ZERO times. No help from the community. Nothing. Only complaining that feature x or y is not working.

And don't tell me that it is not possible to get familar with OMV without huge docs. Most of the knowledge is written down in the code as comments or function method description. And isn't it the best way to get familar with a code base when you read it?

One of the positiv contributions in the past (maybe years) was this: https://github.com/openmediavault/openmediavault/pull/661

This PR shows that it is possible if you WANT it.

Zitat von dziekon

Instead of getting mad at me and immediatelly attacking me

I really don't attack anyone. This was a neutral analyses of the current situation.

And you're right. The documentation lacks, but this is the chicken egg problem. And i'm not a good docu writer, so someone else must do that. Maybe someone who gets familar with the code and can write down his experiences.

There are pros and cons to docker and plugins. Using docker also allows support from many other places. I have seen many, many times that the author of service would like to help but doesn't know how the plugin works. If you are using their docker, they know exactly how to help. Unraid moved most of their "plugins" to docker and people love it. Not sure why it is so terrible here.

The funniest thing is that the plugin people miss the most is the docker plugin since they don't like the change to portainer. But lets look at the list of plugins not ported to OMV 5 and the reason why: The downloader plugins aren't included because they weren't ported to OMV 4.x, belong in a docker since most (if not all) of them need dependencies newer than Debian has in the repos, and most were just frontends for the downloader's web interface

openmediavault-calibre - never ported to OMV 4. couldn't get the plugin to work with calibre3. bad to stay on old version.

openmediavault-cups - version of cups in debian repo lacking features, plugin pain to maintain due to custom extjs stuff, most people have network printers

openmediavault-dnsmasq - pihole is what most people want and it is better installed in a docker.

openmediavault-docker-gui - plugin features falling behind including no docker-compose, portainer very good and maintained by lots of people

openmediavault-domoticz - debian OS dependencies not up to date enough, just a redirector to own web interface

openmediavault-duplicati - just a redirector to own web interface

openmediavault-emby - just a redirector to own web interface, debian OS dependencies frequently behind, lots of OS dependencies that added cruft to host

openmediavault-letsencrypt - debian OS dependencies behind

openmediavault-mysql - version in Debian repo usually behind or different than wanted, plugin didn't have options needed, wanted different admin web interface (instead of mywebsql)

openmediavault-nginx - version in Debian repo usually behind, version of php behind, bad user settings would break OMV web interface

openmediavault-plexmediaserver - plugin terrible, just a redirector to own web interface

openmediavault-pxe - relied on dnsmasq plugin

openmediavault-remotedesktop - version in Debian repo frequently broken, recommend danielguerra/ubuntu-xrdp image)

openmediavault-shellinabox - cockpit has better web terminal and can be installed by omv-extras

openmediavault-syncthing - plugin not flexible enough, frequent syncthing repo issues

openmediavault-urbackup-server - plugin just a redirector to own web interface

openmediavault-virtualbox - virtualbox isn't available from Debian 10 repo, phpvirtualbox isn't maintained, breaks often when new kernel version released

openmediavault-webdav- plugin not flexible enough, version of sabredav behind in debian repos.

So, if someone can come up with a good reason it should be ported to OMV instead of being run in a docker after the reasons I just gave, I will consider porting it.

Zitat von cogitech

I am happy to report that I took the advice early on in the thread to get OMV4 while it is still available.

My expectations for OMV have been lowered through this experience and that is a good thing. To me, I will simply think of OMV as a good general purpose Linux server implementation with a decent webGUI and some good essentials built in. I'll install, configure and manage the "extras" myself.

Last step is to decommission the trusty Stone Burner installation and re-purpose the drives.

I find it crazy you find installing software on a server the "normal" way easy, yet you find docker and/or portainer, so confusing? I'm not so sure if your expectations of OMV should be lower, but your ability to adapt is.

When I first started with docker (probably about a year ago).. I just put OMV in a virtual machine and started practicing... reading tutorials, watching videos, etc. Probably within a few hours, I had a pretty good understanding over it and could install basic containers (linuxserver, and a few others) w/o issue. More reading and a few days.. and I was able to install some more complex containers. When I heard the docker-plugin was going away... I did the same thing and installed portainer. Portainer is very easy if you've spent any time with the docker plugin.. it should make sense to you in little time (but portainer is considerably better)... then you start getting into how to deploy containers with docker-compose/docker-run.. I can set up my whole server in about an hour from scratch, because I have a bunch of docker-compose files backed up.