Docker Template XML Schema

[Squid]

I'm going to try and stop this back and forth debate

 

At the end of the day, templates being updated has been troublesome.  We're trying an experiment to see how things go without updating them.

 

IMO, Templates very, very rarely change and I don't see that changing all that much in the future, and the number of templates that needed to be set to not update was very steadily increasing.

 

But, if this change in 6.10 proves to be troublesome again then we'll revisit the whole thing again and try a different solution.   In the meantime, we're not putting in updates to the templates...

[Glassed Silver]

35 minutes ago, ich777 said:

TBH I really don‘t want that a template changes on it‘s own and or a maintainer can easily change things in my template that I changed on purpouse…

 

It happened once for a OpenVPN-Client template IIRC that out of no where pointed to a completely different container where the source has no where to be found or at least it was some really suspicious source.

 

I think the users should take care of that themselve if a container breaking change is introduced.

 

I‘m really not a huge fan of self changing templates or better speaking maintainer changable templates.

How about queuing changes, displaying them as suggested and the user gets to confirm and apply or deny them?

 

Best of both worlds and I have to spend less time troubleshooting.

[JonathanM]

4 minutes ago, Glassed Silver said:

How about queuing changes, displaying them as suggested and the user gets to confirm and apply or deny them?

 

Best of both worlds and I have to spend less time troubleshooting.

How do you handle the HUGE number of people with auto updating for their containers?

 

(I'm not one of those BTW, I make sure the forums aren't buzzing with issues about a specific container before I hit update)

[ich777]

20 minutes ago, Glassed Silver said:

How about queuing changes, displaying them as suggested and the user gets to confirm and apply or deny them?

Think about it, most won‘t read it and click OK or Change or whatever button is in place anyways….

 

20 minutes ago, Glassed Silver said:

Best of both worlds and I have to spend less time troubleshooting.

Do you change your templates that often or what is the exact issue in your containers?

 

I barely change my templates and if I do so they won‘t break the container because I also integrate a new variable or whatever into the Dockerfile itself that it is by default there and won't break functionality…

 

If you really want auto updates or whatever I think the easiest solution would be to create a option to enable or disable auto updates in general (also respect templates that have it turned off) somewhere in the GUI so that users can decide…

 

but by default I would let that global option turned off.

[ich777]

14 minutes ago, JonathanM said:

I'm not one of those BTW, I make sure the forums aren't buzzing with issues about a specific container before I hit update

Thaha I‘m the complete opposite of that and when the maintainers from Gitea introduce a new variable or something that‘s not well documented so that my instance (where everything is hosted I do) won‘t work anymore I start raging at their Discord. 😂

[Glassed Silver]

3 hours ago, JonathanM said:

How do you handle the HUGE number of people with auto updating for their containers?

 

(I'm not one of those BTW, I make sure the forums aren't buzzing with issues about a specific container before I hit update)

What's the problem? Templates don't change a lot, but when they do, I want to catch and handle it, semi-automatically if needed.

 

I have dozens of containers. I agree that changed templates yeeting custom configs in them is bad, that's why I propose that template updates and user defined stuff should be merged git-style, but obviously that should be opt-in.

 

I don't get why others want to tout their personal preference as the only way, I'm trying to think of both schools of thoughts, but whatever.

 

In Portainer you can subscribe to a docker-compose.yml hosted elsewhere and override env variables with your own configs. when the yml changes, your overrides remain intact. (unless of course the name of the variable were to change, but that's a complete other can of worms, and I've never experienced that myself)

 

In the end no solution is perfect, everything will involve user administering. But I really don't understand why my suggestion is so disagreeable when I say it should be optional. Fine you don't want to use it, don't.

[ich777]

6 hours ago, Glassed Silver said:

In Portainer you can subscribe to a docker-compose.yml hosted elsewhere and override env variables with your own configs. when the yml changes, your overrides remain intact. (unless of course the name of the variable were to change, but that's a complete other can of worms, and I've never experienced that myself)

But that doesn't always works perfectly fine as you already pointed out and this is not the only issue...

This was also the way on how it worked on Unraid, but that also introduces other issues.

 

6 hours ago, Glassed Silver said:

I don't get why others want to tout their personal preference as the only way, I'm trying to think of both schools of thoughts, but whatever.

6 hours ago, Glassed Silver said:

But I really don't understand why my suggestion is so disagreeable when I say it should be optional.

I don't think that your idea is disagreeable, as @Squid pointed out this is more kind of a experiment and if it doesn't work out it will be changed back how it was and maybe with some additions like a global option to turn updates on/off <- at least this would be my suggestion...

[Squid]

So much for my trying to stop the debate lol

[Glassed Silver]

On 5/1/2022 at 1:22 PM, Squid said:

So much for my trying to stop the debate lol

No hard feelings, but tech heads aren't known to stop tech chatter willy-nilly. 👻

[ssickle]

There is a problem with InfluxDB's template: if someone who's been using this template for a long time hits update in the UI, it'll update the container to 2.3 and potentially cause data loss. Ideally I would like to direct these legacy users to my InfluxDB1 template.  See conversation here where the author says I can take over.

 

I considered the following:

• Removing template via PR on original author repo (afraid this may break some users)
• Checking the moderation.json (only saw depreciating an entire container there)
• Creating InfluxDB2 and InfluxDB1 templates and letting user (different name and tags used, shouldn't show as a dupe luckily)

@Squid could you shed some light on how CA would like to best support this scenario? I don't see a Depreciated tag or anything like that.

[Squid]

As of late, @ich777 and myself have noticed a fair amount of overuse of maintainers setting the Privileged flag on.

 

Privileged effectively gives root access to your server and should only be enabled if the container actually requires it.

 

CA in the side bar will display a warning if Privileged is set and if installing directly from the card, the following will appear

 

Because there are certain containers which do require Privileged to be set, to have CA not display this message then you would add into the XML 

<PrivilegedReq>true</PrivilegedReq>

 

[Squid]

In order to avoid icons not appearing properly on every one's system (and my own pet-peeves), a tag to the xml is now available to override the Icon being used when on Unraid display themes other than the default (there are 4 available display themes)

<Icon-black>some url</Icon-black>
<Icon-white>some url</Icon-white>
<Icon-azure>some url</Icon-azure>
<Icon-gray>some url</Icon-gray>

 

These urls override the <Icon>  when the OS is set to a certain theme and prevent the following from happening.  In other words, a black icon on a transparent or black background (transparent is always preferred) tend to not look good when the OS is on the black theme as seen in the pictures

 

When installing the container, the installed template will automatically have it's xml adjusted so that it looks decent for the user on the docker / dashboard tabs

 

 

[Squid]

As of now, any and all Donation links within any template when the template points to an "Official" container will be automatically removed.  This is being done because there may be confusion on the end-user's part as to what they are actually donating for: The maintenance of the template (very little actually work involved) or the development / maintenance of the application itself.

 

If you (as a template maintainer) also happen to have published within CA an official container then I suggest that you have any donation links etc within your project page

[Squid]

Shortly, any template that does not have either a project or support entry in the template will be removed.  It can't be too hard to either create a thread (or use the app's own support thread) or to even point to the project on GitHub where it's possible for a user to get some help.

 

Also, WebUI entries are still messing people up.  It always refers to the container port.  It has never (and will never) point to the host port defined.   CA has for years been attempting to fix these errors and it does for the most part.  But in the circumstance where it cannot fix it automatically to point to the correct container port then CA will begin to automatically remove those templates.

 

Along the same lines, hardcoded ports and IP addresses in the WebUI will wind up getting the template removed

 

Maybe its because I still have a huge amount of pull requests outstanding (some for years) that are fixing all of this stuff and I'm rather sick of it.