-
Notifications
You must be signed in to change notification settings - Fork 74
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.
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
initialization_custom_script should be better documented #453
Comments
Hey @hotspoons I believe this is less of a documentation issue, this seems to be a problem in the underlying go-ovirt itself. Unfortunately, we didn't have time to look at it yet, tracking this down is a bit tricky. |
Okay thanks @janosdebugs , I opened an issue in the go-ovirt-client GitHub and was embarrassed when I saw your name auto-assigned just as it was here, but there is probably more concrete usable info in that issue as far as a failing test case. I'm not great with go, otherwise I'd volunteer a pull request with a passing unit test off the cuff. But at the core it's just running XML encode on the field in question (though this issue may apply to other fields) before sending the request. |
No worries at all @hotspoons, and sorry for the late reply. Typically, I reply within a week. The two issues are more than ok, this affects both projects, after all. If you want to help, you could try and prove with mitmproxy that the encoding is indeed transported incorrectly. If you can give us a data dump from the request that goes to the engine, that would help. Here's what we have on the mitmproxy setup in our internal docs: mitmproxy is a very useful tool for debugging requests that are going to the engine. In order to debug requests to the oVirt engine you need to perform 3 steps:
You can then start mitmproxy, replacing the reverse target with your engine domain:
|
Okay I used mitmproxy to capture the traffic, and this is what came out (certificates, keys and tokens omitted):
If I take the |
@hotspoons one last question: you did not encode the contents by hand, right? Because it looks like the script is properly encoded. Huge thanks for the help! |
No, it wasn't encoded, you can tell because there are normal shell characters like Second file, when I XML encode the shell script that is a terraform template, I am able to deploy Kubernetes on initialization and everybody is happy: reqres_encoded_shell_template.txt I added you @janosdebugs to my private home lab repo so you can see what is necessary in the original terraform template that ultimately generates the second request: https://github.com/hotspoons/home-lab/blob/main/compute/k8s_master.tftpl |
The weird part is there is some encoding there:
However, other characters are not encoded. I'll look at go-ovirt and what's going on there and update this issue. |
Nevermind, the encoding above comes from your initialization script! |
Because of a 3 layered matryoshka doll of encoding issues, it took me several hours to figure out how to get
initialization_custom_script
to post to oVirt's API without becoming malformed in transit, or failing all together.There are a few problems here:
I'm not sure exactly where the fix for the xml encoding issue should go (either here or the go-ovirt-client - probably the client because anything else using that library would also benefit), but that was an insane snipe hunt to figure how to get the script to oVirt cleanly
The text was updated successfully, but these errors were encountered: