-
Notifications
You must be signed in to change notification settings - Fork 0
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
wkhtmltopdf woes #23
Comments
for the record, here's the Odoo log from the time we hit the button to generate a PDF from a timesheet until the PDF was downloaded. |
also, these are the libs linked to the
|
If needed we could compile our own Basically, it boils down to converting their Docker build functions to Nix
But possibly a better option could be to piggyback on |
Issue is fixed on the x86 machine Basically the error string The odoo motherfckr has a system paramenter called To be able to see the system parameters you gotta have enabled the "developer tool". -- https://odoo.sucks/web?debug=assets,tests#action=8&model=ir.config_parameter&view_type=list&cids=&menu_id=4 You can access this variable from the application > settings > technical > system parameters When printing the timesheet, Odoo was calling the stylesheet and the JS file from Moreover, very likely odoo didn't even rewrite the url, imagine how it had been badly engineered. On this note, lucky me - I forked your repo and merged the x86 branch to the main one. Now I am cloning mine to the martel's org setting the repo as (private) so as to have the credentials pvt. Then will create an AMI starting form the actual x86 machine and creating a new instance with lower specs starting from that image --> importing recent data and deliver it for testing. Also keep in mind that, even after this tweak, the outputs were not the same:
Attached you can find the 2 samples. Hell yeah! |
@m3dd3fx good catch, excellent work!! It looks like this Tracing Odoo system calls in the dev VM $ sudo strace -f -s 10000 -p 3994 -p 4064 -p 4065 -p 4069 -o dump.txt confirms your analysis. Here's the params Odoo passes to
The header, body and footer file args are temp HTML files Odoo writes before calling
which contains this HTML <!DOCTYPE html>
<base href=https://odoo.martel-innovate.com>
<html style="height: 0;">
<head>
<link type="text/css=" rel="stylesheet"
href="/web/content/38829127-cd253c1/web.report_assets_pdf.css"
data-asset-xmlid="web.report_assets_pdf" data-asset-version="cd253c1"/>
<link type="text/css" rel="stylesheet"
href="/web/content/38829125-b64992f/web.report_assets_common.css"
data-asset-xmlid="web.report_assets_common" data-asset-version="b64992f"/>
... Notice the base URL set to the value of the Now in the dev VM we've got an unpatched
But it does try to convert the HTML body file to PDF. In doing so, it connects to
$ dog odoo.martel-innovate.com
CNAME odoo.martel-innovate.com. 5m00s "ae9ff73d8d87e40b1b6945133012c365-2011518872.eu-central-1.elb.amazonaws.com."
A ae9ff73d8d87e40b1b6945133012c365-2011518872.eu-central-1.elb.amazonaws.com. 1m00s 3.125.20.6
A ae9ff73d8d87e40b1b6945133012c365-2011518872.eu-central-1.elb.amazonaws.com. 1m00s 3.121.61.170 to download the stylesheet files, but it fails
most likely b/c these files have a different version tag---e.g. Here's the whole trace: |
So where does all that leave us? I think we should go live with the patched |
I agree to go over with the x86 machine since we don't care about spending some cents more x hr. t3.medium (2cpu 4G Ram) - $0.0418 / hr Our task now requires us to deploy a stable vers of odoo asap (probably Massimo wants to announce it @ the plenary in zh) |
At the moment Odoo can call
wkhtmltopdf
to generate timesheet reports, timesheet data gets output correctly in the PDF but the Martel template doesn't get applied so the report looks dull.Also there's some potential issues with the
wkhtmltopdf
versions we use. The one we had in K8s is an x86 binary compiled withwkhtmltopdf
's own patched Qt lib (https://github.com/wkhtmltopdf/wkhtmltopdf) as reported by the tool$ kubectl -n martel exec -it odoo-community-6f47c5586-47fth -- sh $ wkhtmltopdf --version wkhtmltopdf 0.12.6.1 (with patched qt)
Notice there's no official
0.12.6.1
version, so this must be a patched Debian thingie. Also notice the Odoo guys say you shouldn't be using that version with Odoo 14 which actually requires version0.12.5
:This is why we build that version for Odoo box. Our build works both for x86 and ARM64 architectures but it links an external Qt lib instead of compiling in the one the
wkhtmltopdf
guys patched. Now they say you should use either the patched or unpatched version depending on your use case since some features available in the unpatched version aren't available in the patched one and vice-versa. It looks like we need the patched version though. In fact, when tryna print a PDF from a timesheet, we get this error message in the Odoo logs:which is probably why the PDF contains all the timesheet data but without the formatting in the Martel template.
We've also tried using an x86 binary on an x86 machine. This binary contains a patched version and so
wkhtmltopdf
doesn't moan about unsupported features anymore---i.e. the above message is gone from the Odoo logs. But still the Martel template doesn't get applied to the PDF, the error message in the Odoo logs now isSo it looks like we've made some progress and now it could be just a matter of Odoo not passing in the template file when calling
wkhtmltopdf
orwkhtmltopdf
not being able to access that file.Bless this mess!
The text was updated successfully, but these errors were encountered: