Beiträge von noiro

    That would require maintenance of each yaml afterwards. Every time an author modifies their container it could break a lot of people's settings. Maybe I'm wrong, but I think this exceeds what OMV can contribute. I understand and agree with ryecoaaron 's answer. Each user must take responsibility for their containers.

    Yes that the idea of templates. There are quite a few github repositories with curated templates/stacks that it is easy to deploy. It is excactly the same logic with the examples in omv. A json file with a lot of templates of apps and/or stacks. The dirence is that omv json file is more simplistic than the one from portainer, and portainer has larger user base and thus more people maintain those lists.

    But IMHO it worth investing some time to have a proper examples list that it will make easier the deployement of containers (less errors=less support) and by extend it will increase the capabilities of omv. as ryecoaaron pointed out 99% might not needed but then again I see a lot of questions/issues around containers in the forum... just my humble opinion here..

    Then no, those will not be part of the compose plugin. The first problem is that they require portainer. I see the example compose files available on the files tab as being pretty much an equivalent. We just need more people to contribute to the examples.

    How? Pull request in Github?

    It is quite simple to transform those potainer templates to compose plugins. They are just yaml files in the end with some default locations that portainer uses, predifined.

    But I am going to try very hard to push people toward using the compose plugin because there are way too many portainer support requests on this forum.

    Truth be told portainer is not doing good job of keeping appdata, yamls etc tidy and in easy to find place. The compose plugin simplifies that I think.

    I do not think you need to push. It is a good evolution so people will follow. Well at least the 99.9% of them :)

    Maybe a way to assist is a clear path/guide to "migrate" from portainer way to compose plugin.

    Portainer saves the stacks in /var/lib/docker/volumes/portainer_data/_data/compose/ but in folders with a number and not with the stack name. But they are there. Copy past to the plugin and you are up and running.

    Yes, it's better. Read publication 1 of this thread, ask your questions.

    That is debatable :) They serve different purpose.

    If one wants a pure OMV installation, then yes. The "new" way of manage docker containers is a huge improvement.

    If one wants to go one step further from just "managing" docker containers (i.e. play with kubernetes, play with kubernetes on cloud, manage more than one server) then portainer is a very good solution. Both the Community Edition and the Business Edition (free for up to 5 nodes).

    I fully support the decision to split portainer/yacht from omv-extras and have a more "native" solution even thoough I will still use portainer.


    It is also debatable if the timing of the introduction of that "split" was right or no. There is no perfect time IMHO. Did it cause problems? Not really. The forum is here and if someone can read it will sort any issue in no time. ryecoaaron is very helpful and petient, sometimes too petient :)

    I do believe the timing was good. If it was introduced with version 7 it will cause bigger impact, less time to assist etc.


    Anyhow, it is an open and free software. I am grateful for what I get and if it broke my system(s) once or twice is fine, I learned couple of new things along the way ;)

    Veeam is a nice backup software. There is a free, community edition for up to 10 workloads/servers/instances/whatever.

    Debian is supported. You need to setup an agent in every machine/server you want to backup.

    Veeam has an extensive KB so I wonder why you are asking here for Veeam backup?

    You have to treat OMV as any other debian based server nothing more nothing less...

    With the latest mergerfs plugin you do not have to shorten the path..


    I have similar setup.

    I named the disks d1, d2, etc.

    D1= parity, content

    D2=content, data

    D3=data

    D4=data

    Dx=..... etc.


    Go to shared folders and share the D1, D2 etc.

    In mergerfs you add the paths D1,D2 etc. make sure you setup a pool give it a name and from the drop down menu select the disks/filesystems

    Choose a create policy ( I have most free space..)


    Then go to services and share the Pool under NFS and/or SMB/CIFS then from the clients you can access the pool...

    I hope it helps.

    Yes.

    exactly like that. you can even select from the pull down menu.