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.

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

Switch all PDF render traffic to new Proton service #1126

Merged
merged 3 commits into from
Jun 4, 2019

Conversation

hknustwmf
Copy link
Contributor

@hknustwmf hknustwmf commented Apr 29, 2019

Removed old pdf.js module that split traffic between electron and proton. Changed configs to route traffic to proton PDF rendering only.

Bug: T210651

@Pchelolo
Copy link
Contributor

Hm. Seems like travis is not working anymore, and it's unrelated to this PR. Could you please figure it out in a separate PR? I believe something like this should work https://github.com/rubygems/rubygems.org/pull/1963/files

v1/pdf.yaml Outdated Show resolved Hide resolved
v1/pdf.yaml Show resolved Hide resolved
@Pchelolo
Copy link
Contributor

There are 2 unit tests for this in /test/features/pdf.js that were ignored because the old renderer was very unreliable. We should bring them back.

.gitignore Outdated Show resolved Hide resolved
@d00rman d00rman changed the title T210651: Switch all PDF render traffic to new Proton service Switch all PDF render traffic to new Proton service Apr 29, 2019
@hknustwmf
Copy link
Contributor Author

hknustwmf commented Apr 29, 2019 via email

@Pchelolo
Copy link
Contributor

Please rebase against #1127

.travis.yml Outdated Show resolved Hide resolved
config.test.yaml Outdated Show resolved Hide resolved
@Pchelolo
Copy link
Contributor

How did the commit 985d008 got in here? :)

@hknustwmf hknustwmf force-pushed the master branch 2 times, most recently from f243bdd to e0e8817 Compare April 30, 2019 22:52
@d00rman
Copy link
Contributor

d00rman commented Apr 30, 2019

Looking good! Now we also need to add the extra parameters that are supported by the Proton service, but were not supported in Electron, just as it was done in PR #1090. Note, though, that in that PR we still use the optional param syntax, which we have since dropped. So, there should be three end points now: /pdf/{title}, /pdf/{title}/{format} and /pdf/{title}/{format}/{type}. The default values, if not supplied, should be format: a4 and type: desktop.

@Pchelolo
Copy link
Contributor

Pchelolo commented May 1, 2019

Looking good! Now we also need to add the extra parameters that are supported by the Proton service, but were not supported in Electron, just as it was done in PR #1090. Note, though, that in that PR we still use the optional param syntax, which we have since dropped. So, there should be three end points now: /pdf/{title}, /pdf/{title}/{format} and /pdf/{title}/{format}/{type}. The default values, if not supplied, should be format: a4 and type: desktop.

nah @d00rman we ate not doing this yet. my idea is to have the public API intact now untill we are completely sure we are switching to the extended functionality. thus the hard-coded formats. It would be good to write a comment about that though

v1/pdf.yaml Outdated Show resolved Hide resolved
.gitignore Outdated Show resolved Hide resolved
@hknustwmf
Copy link
Contributor Author

Add comment to pdf.yaml about the hard-coded parameters to be replaced by endpoint parameters

test/features/pdf.js Outdated Show resolved Hide resolved
Copy link
Contributor

@d00rman d00rman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hknustwmf please address the timeout issue in tests

@d00rman
Copy link
Contributor

d00rman commented May 7, 2019

Nice work @hknustwmf !

@d00rman
Copy link
Contributor

d00rman commented May 29, 2019

@hknustwmf this now needs a manual rebase

@d00rman d00rman self-requested a review May 29, 2019 15:29
Copy link
Contributor

@d00rman d00rman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Un-approving until the rebase happens

v1/pdf.yaml Outdated Show resolved Hide resolved
@d00rman
Copy link
Contributor

d00rman commented May 29, 2019

Still needs a rebase, somehow

@hknustwmf
Copy link
Contributor Author

Still needs a rebase, somehow

Do you want me to combine the commits into 1?

@d00rman
Copy link
Contributor

d00rman commented May 30, 2019

Alrighty, this is looking good now. We still need to hold off on merging until the back-end is fully ready for the transition.

@d00rman
Copy link
Contributor

d00rman commented May 30, 2019

One more thing: let's implement rate limiting given the resources needed to generate PDFs. To do that, you need to add the rate-limiting route filter under the x-route-filters stanza:

x-route-filters:
  - path: ./lib/access_check_filter.js
    options:
      redirect_cache_control: '{{options.cache_control}}'
  - type: default
    name: ratelimit_route
    options:
      limits:
        internal: 10
        external: 5

@d00rman
Copy link
Contributor

d00rman commented May 31, 2019

Now we are solid, thnx @hknustwmf !

@d00rman
Copy link
Contributor

d00rman commented May 31, 2019

Actually, @hknustwmf let's correct the rate-limiting values. Let's set them to 1 for external requests and 5 for internal ones. The limits are per-client, so let's lower them to the minimum.

@hknustwmf
Copy link
Contributor Author

Actually, @hknustwmf let's correct the rate-limiting values. Let's set them to 1 for external requests and 5 for internal ones. The limits are per-client, so let's lower them to the minimum.

Just pushed the changes.

@d00rman d00rman merged commit 1fa9433 into wikimedia:master Jun 4, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
3 participants