If you are using a compose file that changes that often, it is not a good image maintainer. The image might change often but the compose file shouldn’t.
I'm developing the stack myself and during development the images and the compose file changes a lot. And I want to redeploy with ease into the testing environment.
You just cannot acknowledge that there may be use cases where Portainer is the better fit, can you?
ryecoaaron - thanks for the continued development of this plugin. I like the backup option and I am doing some testing...
I see that the backup process stops the container before backing up. I assume is to ensure locked files are all included in the backup. Is that correct?
I currently using a rsync job to another OMV server - compose and appdata/config folders. I think can now change this to backup the docker backup as this included both of the folders I am currently backing up.
Can you confirm if anything else is included in the plugin backup function?
Today I saw the update for Portainer 2.18.4 and realized that this command didn't work either. So, I went to this forum (which I don't frequently visit, only if there are update issues). I was shocked to see 59 pages full of complaints about this change and was frightened beyond belief.
I'm developing the stack myself and during development the images and the compose file changes a lot. And I want to redeploy with ease into the testing environment.
You just cannot acknowledge that there may be use cases where Portainer is the better fit, can you?
I'm sorry but I don't really get the angst here in the last sentence...
I think the omv-extras dev (ryecoaaron) has done so much to incorporate feature requests into the plugin over the last few weeks. - but not to create a clone of portainer! I think he is really just trying to understand your use case to see if it is something that could be included or not.
He gets it (most of us get it too) that portainer is a different product offering and everyone who wants to, can easily continue to use it. No problem.
For me, I thought I would continue to use portainer so I have it installed in the omv plugin. I have found that I don't need it so I don't have the compose/container running.
I also get that you have a developer use case - and probably portainer is a better option.
Peace
That’s what he did? Why so aggro?
Not aggro nor flaming, if that's what you're implying.
Just gave a simple explanation of how to continue to use Portainer.
And with replies like your's, that doesn't add no sort of a solution or help to a situation, that this thread is already 60 pages long.
As mentioned, I did not want to start a war. I was truly interested in finding out about the motivation for that plugin and the dislike for Portainer.
But I got the feeling that this question was not welcome here (the tone got a bit rough very quickly).
As everyone can use whatever he/she likes (OMV compose or Portainer) everyone can be a happy guy.
I didn't want to offend anyone nor have I taken offence. Have a good one! 
I didn't want to offend anyone nor have I taken offence. Have a good one!
This subject is being very controversial from the first moment. It seems you need to scrupulously measure your words when posting on this thread
Don't worry, you just gave your opinion and shared your experience, no problem.
Can you confirm if anything else is included in the plugin backup function?
By default, all subfolders that exist in the folder where the compose files are located are included, this includes compose files (file and env) and container volumes defined by relative paths (these are always in that subfolder). This is the folder you define in Services>Compose>Settings in the Compose Files (Shared Folder field).
Also included are all volumes in each composition file that are not set to :ro (read only) in the composition file. By default, any volume smaller than 1GB in size is excluded.
You can vary the default size in the GUI in Services>Compose>Settings in the Max Size field.
You can vary the selection of containers to include or exclude in the backup in the definition of the scheduled task to perform in the Filter field.
You can customize any volume within a composition file to be included or excluded in the backup:
These two conditions prevail over the others except if the volume is read only, in which case it will not be copied.
- Typing # BACKUP at the end of the line that defines a volume will include that volume in the backup
I've been out of the forum for a couple of days, which means I've missed a bit, this plugin is changing at a rapid pace I know when you me were testing the backup/restore, ryecoaaron did say that '# BACKUP' would Backup even if the volume was larger than the max value in setting, is this still the case?
is this still the case?
Yeah. That's been the case since this backup feature for the plugin was conceived. Writing # BACKUP on the volume line in the compose file overrides everything else except the ro feature of a volume. If the volume is read only it will not be copied in any case, it wouldn't make sense to include it.
You just cannot acknowledge that there may be use cases where Portainer is the better fit, can you?
Sure I can. Portainer is awesome at managing containers on remote servers. Portainer supports kubernetes. Portainer has many more options than the plugin. Portainer has a builtin exec window. I was just trying to understand your use case. My bad.
As mentioned, I did not want to start a war. I was truly interested in finding out about the motivation for that plugin and the dislike for Portainer.
But I got the feeling that this question was not welcome here (the tone got a bit rough very quickly).
It doesn't help that you are creating an imaginary hatred for portainer. I don't hate portainer at ALL. I've mentioned the motivation for writing the plugin many, many times in this thread.
The plugin will default to root:root and 700 for directories and 600 for files.
Does that affect volumes with relative paths in any way? By default they are in subfolders of the same folder.
Does that affect volumes with relative paths in any way? By default they are in subfolders of the same folder.
Nope. It will only change the permissions on the compose file, env file, and the directory they are in. It isn't doing any kind of recursive change. The plugin has always been setting the permissions on these three things. I just made it possible to change them. Look at the changes to the 10compose.sls changes - https://github.com/OpenMediaVa…ade1ad99a49ea4303e47836d6
Nope. It will only change the permissions on the compose file, env file, and the directory they are in. It isn't doing any kind of recursive change. The plugin has always been setting the permissions on these three things. I just made it possible to change them. Look at the changes to the 10compose.sls changes - https://github.com/OpenMediaVa…ade1ad99a49ea4303e47836d6
OK thanks.
I'll try and explain this the best way I can, please ask questions if need be. I don't remember seeing this bought up before, and it might be a very unusual problem, without an easy fix, I also think it might be a OMV one rather than this plugin.
I've created a new container from within Files tab, here are the steps to reproduce, all from within Files Tab
1. Press Down
2. Press Delete, Yes
3. Click undo changes, Yes
Files tab still list container name.
Compose folder does not have container name directory.
But you can still click edit and make a change and save it.
The plugin will then recreate the container folder in the Compose folder, you can then click 'Up' and all is well.
Actually looking at it, it would seem as though the plugin should not delete folder until Apply changes have been confirmed.
Also is there a reason why the 'Save' button can not be live as soon as you enter the edit window? Or at least be live if the character count >1?
I know I asked this before, but it was when loads of questions was coming your way. Almost all the actions that work on a highlighted name in Files tab, keep the highlight on after completing the action i.e 'check', I know they use a pop out box, and edit does not, but could the name stay highlight after using edit?
Display MoreI've created a new container from within Files tab, here are the steps to reproduce, all from within Files Tab
1. Press Down
2. Press Delete, Yes
3. Click undo changes, Yes
Files tab still list container name.Compose folder does not have container name directory.
But you can still click edit and make a change and save it.The plugin will then recreate the container folder in the Compose folder, you can then click 'Up' and all is well.
That is expected. The Delete button will delete the stop the compose, delete the compose file and env, delete the directory (not recursively), and then delete the database entry. If you undo that change, the database entry will be brought back which is all that is needed to recreate the dir and files it just deleted.
Actually looking at it, it would seem as though the plugin should not delete folder until Apply changes have been confirmed.
I can't. By that time, the database entry would be gone and the saltstack code would know to delete it. I don't want the code to delete everything in that directory and recreate all compose files every time saltstack runs.
Also is there a reason why the 'Save' button can not be live as soon as you enter the edit window? Or at least be live if the character count >1?
What do you mean by "live"? When you click the save button in the edit window, it is writing to the database and then executing the saltstack code which should rewrite the compose and env files.
I know I asked this before, but it was when loads of questions was coming your way. Almost all the actions that work on a highlighted name in Files tab, keep the highlight on after completing the action i.e 'check', I know they use a pop out box, and edit does not, but could the name stay highlight after using edit?
Whenever the changes are applied right away (from the add or edit box), it doesn't keep the highlighted name. I can't change that behavior unless I change the plugin back to not applying the add or edit right away.
That is expected. The Delete button will delete the stop the compose, delete the compose file and env, delete the directory (not recursively), and then delete the database entry. If you undo that change, the database entry will be brought back which is all that is needed to recreate the dir and files it just deleted.
I can't. By that time, the database entry would be gone and the saltstack code would know to delete it. I don't want the code to delete everything in that directory and recreate all compose files every time saltstack runs.
Right, I understand that. I'm going to have lookup 'saltstack' as this seems to control a lot of what OMV does or allows.
QuoteWhat do you mean by "live"? When you click the save button in the edit window, it is writing to the database and then executing the saltstack code which should rewrite the compose and env files.
In the above example, when I undo changes, the container still shows in the Files tab, but to recreate the container folder and yml files in the Compose folder, I have to click edit and save. And you can only click save after making some sort of change i.e adding or removing a space.
I just thought if the folder was not in the Compose folder and the file window >1 character then the Save button could be used straight away.
QuoteWhenever the changes are applied right away (from the add or edit box), it doesn't keep the highlighted name. I can't change that behavior unless I change the plugin back to not applying the add or edit right away.
OK, fair enough, I'd rather have the auto apply.
Don’t have an account yet? Register yourself now and be a part of our community!
