New xml template in 6.2 beta.


Recommended Posts

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.

 

 

 

 

Link to comment

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.

 

Hi sparklyballs. In my testings, the new parts of version 2 of the XML schema will be invisible for pre 6.2 users. If you create a XML in 6.2, things like Name, Type, Help text won't work, but all the other things will be exported to the older format.

 

For now, every time you create a template in the Docker Manager, it will automatically translate the configs to the older format, so I really don't think it will be hard to maintain retro-compatibility. Of course things like Name, Type, Help text won't work, but all the other things will be exported to the older format.

 

I had already talked to Squid and advised him to keep CA away from the new format until he iron out all problems. But I can promise you it will be better for users and developers in the long term.

Link to comment

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.

 

Hi sparklyballs. In my testings, the new parts of version 2 of the XML schema will be invisible for pre 6.2 users. If you create a XML in 6.2, things like Name, Type, Help text won't work, but all the other things will be exported to the older format.

 

For now, every time you create a template in the Docker Manager, it will automatically translate the configs to the older format, so I really don't think it will be hard to maintain retro-compatibility. Of course things like Name, Type, Help text won't work, but all the other things will be exported to the older format.

 

I had already talked to Squid and advised him to keep CA away from the new format until he iron out all problems. But I can promise you it will be better for users and developers in the long term.

 

 

i may have misunderstood, but you're saying that dockerman converts new style tags into old style...

you may have to explain that further because i'm reading that new dockerman converts new tags into old format.

 

i'm concerned that people on older unraid won't have new dockerman

Link to comment

The problem is that if an author makes a change in a template then they have to remember to make that exact same change in both the old and the new sections.  Failure to do both sections could possibly result in vastly different operations depending upon whether the user is running 6.1 or 6.2.  And as per my defect report the dry run section of dockerMan is basically unusable.

 

While the additional features of 6.2 is awesome, the actual implementation necessitates a duplication of work for the authors, and the potential for errors doubles accordingly.  (and trust me, there are already a ton of templates out there with technical errors in them)

 

As far as CA is concerned, once the appfeed supports v2 is is a relatively minor problem for it to support the new features.

 

This is more going to be an ongoing nightmare for the maintainers to support both v1 and v2 due to the duplicated sections instead of merely expanding the v1 sections

Link to comment

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.

 

Hi sparklyballs. In my testings, the new parts of version 2 of the XML schema will be invisible for pre 6.2 users. If you create a XML in 6.2, things like Name, Type, Help text won't work, but all the other things will be exported to the older format.

 

For now, every time you create a template in the Docker Manager, it will automatically translate the configs to the older format, so I really don't think it will be hard to maintain retro-compatibility. Of course things like Name, Type, Help text won't work, but all the other things will be exported to the older format.

 

I had already talked to Squid and advised him to keep CA away from the new format until he iron out all problems. But I can promise you it will be better for users and developers in the long term.

 

 

i may have misunderstood, but you're saying that dockerman converts new style tags into old style...

you may have to explain that further because i'm reading that new dockerman converts new tags into old format.

 

i'm concerned that people on older unraid won't have new dockerman

What he's saying is the 6.1 ignores the new sections with the attributes and 6.2 ignores the old 6.1 sections if the new 6.2 sections are there.

 

Hence what I said about doing everything twice

Link to comment

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.

 

Hi sparklyballs. In my testings, the new parts of version 2 of the XML schema will be invisible for pre 6.2 users. If you create a XML in 6.2, things like Name, Type, Help text won't work, but all the other things will be exported to the older format.

 

For now, every time you create a template in the Docker Manager, it will automatically translate the configs to the older format, so I really don't think it will be hard to maintain retro-compatibility. Of course things like Name, Type, Help text won't work, but all the other things will be exported to the older format.

 

I had already talked to Squid and advised him to keep CA away from the new format until he iron out all problems. But I can promise you it will be better for users and developers in the long term.

 

 

i may have misunderstood, but you're saying that dockerman converts new style tags into old style...

you may have to explain that further because i'm reading that new dockerman converts new tags into old format.

 

i'm concerned that people on older unraid won't have new dockerman

What he's saying is the 6.1 ignores the new sections with the attributes and 6.2 ignores the old 6.1 sections if the new 6.2 sections are there.

 

Hence what I said about doing everything twice

 

which is my biggest problem with it.

Link to comment

Hey, I'm sure all the template authors gfjardim reached out to before implementing something that affected them all gave the feedback that this was the way to go and he used their input when adding this, must have just left you guys out of that thread accidentally.

Link to comment

Hey, I'm sure all the template authors gfjardim reached out to before implementing something that affected them all gave the feedback that this was the way to go and he used their input when adding this, must have just left you guys out of that thread accidentally.

 

Sure I did. I did read thousands of times users that had to crawl this forum asking what a volume mapping was, what a port mapping was, etc. When I started the Docker Manager plugin I asked input for developers about the XML schema, and little to none feedback was given. The Push Request stayed on hold 7 months before it got merged, no input from you or Squid were made about the new schema, and now you came here to joke about hundreds of hours I've spend trying to make things better?

 

Of course it's not a perfect world, but now that it's on place we can discuss what to add/modify/improve, that's why unRAID 6.2 is still in beta.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.