Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

docker-entrypoint.sh not backwards compatible prior to 8.0.14 #26

Closed
ptrdlbrg opened this issue Jun 26, 2020 · 2 comments
Closed

docker-entrypoint.sh not backwards compatible prior to 8.0.14 #26

ptrdlbrg opened this issue Jun 26, 2020 · 2 comments
Labels
fix Categorize as fix for automatic release notes

Comments

@ptrdlbrg
Copy link

I pulled down the master branch and built an Ignition 8.0.13 image by providing the download URL in the Docker build arguments. Unfortunately, when I ran it the 8.0.13 container, I got the following output and error:

Provisioning will be logged here: /usr/local/share/ignition/logs/provisioning.log
Waiting for commissioning servlet to become active...
Performing commissioning actions...
ERROR: Unexpected Response (400) during Commissioning phase: Edition Selection
HTTP/1.1 400 Bad Request
Referrer-Policy: strict-origin-when-cross-origin
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Cache-Control: must-revalidate,no-cache,no-store
Content-Type: text/html;charset=iso-8859-1
Content-Length: 410

<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8"/>
<title>Error 400 Malformed body sent</title>
</head>
<body><h2>HTTP ERROR 400 Malformed body sent</h2>
<table>
<tr><th>URI:</th><td>/post-step</td></tr>
<tr><th>STATUS:</th><td>400</td></tr>
<tr><th>MESSAGE:</th><td>Malformed body sent</td></tr>
<tr><th>SERVLET:</th><td>CommissioningServlet</td></tr>
</table>

</body>
</html>

This is because versions prior to 8.0.14 didn't support the edition commissioning step. So it seems that all Ignition 8.0 versions prior to 8.0.14 won't work with the current docker-entrypoint.sh which performs that edition commissioning step.

I know you put a lot of work into getting 8.0.14 working and adding other new features, as I saw the significant changes to the docker-entrypoint.sh script. You also rolled out those changes very quickly. So I'm not complaining, I'm just making it clear that those changes aren't backwards compatible in case other people hit that problem too.

I think we can get them to be backwards compatible, if that's something you'd like. Either the entrypoint script can explicitly check the ignition version and behave differently based on that, or it can do some HTTP GET requests to determine what commissioning step is next and only apply steps that are expected.

If you'd like me to attempt to make that change and submit a pull request then I can do that. I just thought I'd report it first and allow you to decide what to do from here.
@thirdgen88 thirdgen88 added the fix Categorize as fix for automatic release notes label Jun 26, 2020
@thirdgen88
Copy link
Owner

@ptrdlbrg, thanks for the heads up.. I did make some changes to the compare_versions function in the entry point to be able to be leveraged for such a case. For example, the finalize step already pivots based on > 8.0.14.. I just plain missed the fact that the edition step is new.. I'll update things and issue another local build so that way the Dockerfile maintains its backwards compatibility (which is certainly the intention). Stay tuned!

@thirdgen88
Copy link
Owner

@ptrdlbrg, please let me know if you have any other issues. I put in a pivot to effectively revert the behaviors for the commissioning flow if you're on <8.0.14. There were some other minor changes in how things initialize with 8.0.14 in addition to the edition phase, and some follow-up testing today revealed those as well when testing against 8.0.13. I've verified ability to build against 8.0.13, and re-verified a build against 8.0.14 with Maker/Full edition.

I've also put up #27 since it would be helpful for me to be able to have a framework to code in automated tests for these various configuration permutations (as well as backward compatibility for previous versions, like we tripped on today).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
fix Categorize as fix for automatic release notes
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@thirdgen88 @ptrdlbrg