Squid

Docker Template XML Schema

Recommended Posts

 

we (linuxserver.io) have 50 + containers , i don't even know how many i personally have as well. that's a helluva lot of work to make those kinds of changes via cumbersome webui interaction.

as squidly rightly said, in the real world we are going to be doing manual edits because it's just the easiest way to manage all our templates.

 

Yes, I know it's a lot of work, but the current format + CA own elements is a hell to support, to begin with. Plus, they don't survive the Docker Manager edit, so user templates lack a lot of info. A possible future step is to include something like CA into unRAID itself, so we need to make the changes right now to make it future proof.

 

And if you don't want to change your templates you don't have to, the Docker Manager will remain backward-compatible with them, so no muss no fuss there.

 

Not to mention not all our contributors use unRAID, so wouldn't be able to use "Dry Run" when helping out creating templates

 

In a collective of developers like LS, some tasks can always be delegated, if I'm not mistaken.

I can see where integrating the categorizer into dockerMan would have advantages, since every maintainer (plugin or container) has to ultimately use it.

 

I don't believe that you'd integrate the additional tags required for plugin operation, but that's not a big deal.  Those maintainers can still use the categorizer.

 

But, in the case of containers I would personally integrate all of the commonly used unofficial tags (ie: project).  <Changes> you'd probably have a complaint about, since its not markdown, but rather full HTML with syntax changes - (see the link for it).  Changing that formatting would cause nothing but grief since it is VERY commonly used by all the maintainers.

 

Moving Beta into Categories isn't a big deal, and CA would be able to deal with it as necessary.

 

The MinVer and MaxVer were created mainly for plugins, and in the absence of those tags (of which no one uses them with the exception of my own plugins), CA automatically applies MinVer of 6.0 for containers (6.1 for plugins) and MaxVer of the user's unRaid version.  (Additionally, CA's moderation system has the ability to override ANY tag that a maintainer might choose)

 

Since the categorizer is public domain, you can pretty much do anything you want, and legitimizing my unofficial tags is always a plus.

 

The only caveat that I see however is that since CA is not integrated into unRaid, officializing the <Category> tag does tie my hands should the need (however remote) for an additional entry into that.

Share this post


Link to post
Share on other sites

The only caveat that I see however is that since CA is not integrated into unRaid, officializing the <Category> tag does tie my hands should the need (however remote) for an additional entry into that.

 

That's not a show stopper, we could always add that to Docker Manager if necessary.

Share this post


Link to post
Share on other sites

Sorry if this is not the right thread. I am updating my Unraid templates to point the Home Assistant templates to a new repo (migrated from balloob/home-assistant to homeassistant/home-assistant).

 

As part of the process I am cleaning up how Docker generates my images and I want to migrate from 2 repositories (home-assistant, home-assistant-dev) to 1 repository with two tags (latest, dev). However, I can't seem to find a way to specify a tag in a template. Is this possible?

Share this post


Link to post
Share on other sites

Don't you just add the tag to the repository . balloob/homeassist:dev

 

 

Sent from my SM-T560NU using Tapatalk

 

 

Share this post


Link to post
Share on other sites

Can I use Status:Beta|Stable in "<Category>" tag with CA, or do I need to use the "<Beta>" tag? (any different for 6.1.9 and 6.2?)

 

Also, is the <Description> tag removed from 6.2? Is there an new way to have different information on CA (overview), and then you add the docker (where description was before).

This is working fine on 6.1.9, but not on 6.2b21 :(

 

Template if someone would like to take a look (it is in CA also):

https://github.com/bjonness406/Docker-templates/blob/master/Bjonness406/PlexRequestsNet.xml

 

 

Share this post


Link to post
Share on other sites

Can I use Status:Beta|Stable in "<Category>" tag with CA, or do I need to use the "<Beta>" tag? (any different for 6.1.9 and 6.2?)

After it was determined (not by myself - although admittedly I was neutral on the change) to deprecate the <Beta> tag CA supports both methods.  dockerMan itself makes no use of the Category entry (and also doesn't implement it 100%), so it's irrelevant

 

Also, is the <Description> tag removed from 6.2? Is there an new way to have different information on CA (overview), and then you add the docker (where description was before).

This is working fine on 6.1.9, but not on 6.2b21 :(

Othersl decided to deprecate the description tag and instead utilize (and unilaterally change the specification without any consultation and then try to tell me that they know the specifications of CA's tag's better than myself) of the <Overview> tag in 6.2 which was previously a CA specific tag (and designed for its needs)

 

Net result is that the operation you are seeing is correct:  Only the overview displays under 6.2 (and in CA)

 

Share this post


Link to post
Share on other sites

 

 

Also, is the <Description> tag removed from 6.2? Is there an new way to have different information on CA (overview), and then you add the docker (where description was before).

This is working fine on 6.1.9, but not on 6.2b21 :(

Othersl decided to deprecate the description tag and instead utilize (and unilaterally change the specification without any consultation and then try to tell me that they know the specifications of CA's tag's better than myself) of the <Overview> tag in 6.2 which was previously a CA specific tag (and designed for its needs)

 

Net result is that the operation you are seeing is correct:  Only the overview displays under 6.2 (and in CA)

Ahh :(

I liked the previous <overview> and <description> a lot more, looks more clean, and I don't see the point of changing it.

 

Share this post


Link to post
Share on other sites

One of the new features enabled by CA's rewrite of its rendering engine is user-selectable Branches to install.

 

If the template supports this, when the user installs (or defaults) a supported template, they will be presented with a pop up asking them which branch of the application to install.

 

Add this in to the template:

<Branch>
    <Tag>tag#1</Tag>
    <TagDescription>This is the description of tag #1</TagDescription>
</Branch>
<Branch>
    <Tag>tag #2</Tag>
    <TagDescription>This is the description of tag #2</TagDescription>
</Branch>
and so on...

 

When the user selects a branch, the tag (if any) that is already included in the <Repository> entry will be overwritten with the selected tag prior to the xml being sent to dockerMan.

 

The user will also be presented with a Default option which will send to dockerMan the xml with an unaltered <Repository> entry with whatever tag is already present in it (if no tag is present, dockerMan automatically appends :latest as a tag)

 

I don't really recommend adding more than a few branches to any container, as the user can ultimately still change the branch themselves in dockerMan, limited screen real estate, and who wants to add the 100 or so branches that something like MySQL offers to a template.

Additionally, this feature is not going to be back-ported to legacy mode in CA (ie: if you hit Update Applications, you will not see the popup)

 

This feature will be available within CA sometime the week of September 5

 

Advanced

 

Each branch also has the ability to replace any of the xml tags from the main template.

 

EG: If the default tag requires an environment variable of LAN=1, but the branch requires VMLAN=1, then you would have the xml set up something like this:

 

.
.
.
<Environment>
  <Variable>
    <Name>LAN</Name>
    <Value>1</Value>
  </Variable>
</Environment>
.
.
<Branch>
  <Tag>SomeTag</Tag>
  <TagDescription>This is the description</TagDescription>
  <Environment>
    <Variable>
      <Name>VMLAN</Name>
      <Value>1</Value>
    </Variable>
  </Environment> 
</Branch>

Note that ANY of the template schema can be replaced by the branch this way (including the repository - If replacing the repository, specify the full repo including the tag, as the tag identified by the <Tag> entry will not get appended in this case

 

Also note that if the template is a v2 template (ie: has the <Config Name..... > entries, you should include both the <Config entries AND the v1 legacy sections to be replaced for compatibility for 6.1.x

 

For a couple of examples, look here: https://github.com/Squidly271/docker-test-repo

Share this post


Link to post
Share on other sites

Briefly looking at the docker xml template scheme for 6.2 I have issues with the current proposal.

 

the new scheme as it is at the moment doesn't work in pre 6.2 versions.

 

if docker authors want to be fully 6.2 compliant, and not leave those wishing to stay on 6.1 behind, we will end up having to write two sets of tags for every path, variable, device or port mapping.

 

it's my experience that when you increase the complexity, you exponentialy increase the chances of mistakes. miss out one mapping, or make a mistake on either set of tags, you end up with a container that will only work properly on either post or pre 6.2, but not both.

If you use dockerMan to create templates, then there is no problem as its generated files are both v1 and v2 compliant.  Manually creating the xml is a recipe for disaster.  Going forward however this really isn't going to be a big deal as less and less users use 6.1.x / 6.0

Share this post


Link to post
Share on other sites

To clarify further, a number of maintainers and myself were very vocal in questioning the switch to use of attributes vs extending v1 elements as that design choice didn't particularly make a whole lot of sense.  (Along with redefining the specifications on a few existing attributes)  Unfortunately the powers that be decided that attributes were going to be the way forward

Share this post


Link to post
Share on other sites

Briefly looking at the docker xml template scheme for 6.2 I have issues with the current proposal.

 

the new scheme as it is at the moment doesn't work in pre 6.2 versions.

 

if docker authors want to be fully 6.2 compliant, and not leave those wishing to stay on 6.1 behind, we will end up having to write two sets of tags for every path, variable, device or port mapping.

 

it's my experience that when you increase the complexity, you exponentialy increase the chances of mistakes. miss out one mapping, or make a mistake on either set of tags, you end up with a container that will only work properly on either post or pre 6.2, but not both.

If you use dockerMan to create templates, then there is no problem as its generated files are both v1 and v2 compliant.  Manually creating the xml is a recipe for disaster.  Going forward however this really isn't going to be a big deal as less and less users use 6.1.x / 6.0

You were trolled by a bot  ;Dhttps://lime-technology.com/forum/index.php?topic=47482.0

Share this post


Link to post
Share on other sites

Briefly looking at the docker xml template scheme for 6.2 I have issues with the current proposal.

 

the new scheme as it is at the moment doesn't work in pre 6.2 versions.

 

if docker authors want to be fully 6.2 compliant, and not leave those wishing to stay on 6.1 behind, we will end up having to write two sets of tags for every path, variable, device or port mapping.

 

it's my experience that when you increase the complexity, you exponentialy increase the chances of mistakes. miss out one mapping, or make a mistake on either set of tags, you end up with a container that will only work properly on either post or pre 6.2, but not both.

If you use dockerMan to create templates, then there is no problem as its generated files are both v1 and v2 compliant.  Manually creating the xml is a recipe for disaster.  Going forward however this really isn't going to be a big deal as less and less users use 6.1.x / 6.0

You were trolled by a bot  ;Dhttps://lime-technology.com/forum/index.php?topic=47482.0

>:(  >:(  >:(

 

Although what's funnier is that @Sparklyballs pointed out that post to me and also missed the fact that he wrote it in the first place...  (That and you took the time to actually search out the originating thread  :o )

Share this post


Link to post
Share on other sites
(That and you took the time to actually search out the originating thread  :o )

Select body text of post, right click, search with google, first hit. 5 seconds max. Took longer to copy the thread URL into the reply.  ;D

Share this post


Link to post
Share on other sites

(That and you took the time to actually search out the originating thread  :o )

Select body text of post, right click, search with google, first hit. 5 seconds max. Took longer to copy the thread URL into the reply.  ;D

Well, I guess 5 seconds of your life to make me look like a fool is time well spent  ;D  As I've stated, you are my new nemesis  ;)

Share this post


Link to post
Share on other sites

Minor change in XML requirements going forward.

 

Either <Description> or <Overview> is required.  Any template (plugin or docker) missing both of these (or empty) will automatically be dropped from CA.  You don't need both either one of them (standard v2 templates have both, v1 only has Description).  

 

If the maintainers can't be bothered to create a description for the app, I can't be bothered to have the app available in CA.  As of this writing, there are 7 apps from various repositories that fall into this category.

 

Any release of CA after 7/22/17 will incorporate this requirement change.

  • Upvote 1

Share this post


Link to post
Share on other sites

And further refinements / enforcements:  Certain template errors which were originally being fixed by CA are now being reclassified as fatal.

 

These include:

 

Multiple <Repository> entries.  IE: CA used to pick one off the top of its head, and I've now decided that is the wrong way to go about things.

Multiple <PluginURL> entries.  Same as above

 

Anyone can always look at the statistics pop up in CA and click the link for template errors and see what templates have what wrong with them.  CA has numerous tests and fixes for various common mistakes that authors make on their templates, and the stats display will show everything that is happening under the hood.

 

 

 

  • Upvote 1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Copyright © 2005-2017 Lime Technology, Inc. unRAID® is a registered trademark of Lime Technology, Inc.