Page MenuHomePhabricator

Make it easier to create a new requestctl object
Open, MediumPublic

Description

requestctl actions and patterns are often created in a hurry, to resolve an ongoing incident. But creating them requires writing a YAML file from an empty editor, probably using the wikitech page in another window as a reference for which fields to use.

The tool could make this process easier and faster, shortening future incidents. One possible approach would be to provide an interactive mode, prompting with questions like (for a pattern) "what URL path should be matched? what query parameter?" and (for an action) "should matching traffic be blocked, or rate limited? what HTTP status should be served? what message?" The other approach would be to provide a skeleton YAML file for each type of object, to uncomment and fill out lines as appropriate.

Details

Event Timeline

RLazarus triaged this task as Medium priority.

As a note, I am unsure which team to triage this to during sprint week.

Btw, slightly related, I made an experiment to generate requestctl objects starting from the selected filters in the superset dashboards. I have working draft, if anyone is interested please ping me (not yet ready for prime time but """works""" ;) )

Which team is on paper the owner of requestctl?

Adding @KOfori as well, he might have an answer.

Change 902107 had a related patch set uploaded (by Volans; author: Volans):

[operations/puppet@production] superset: add static html for requestctl

https://gerrit.wikimedia.org/r/902107

I've sent a small improvement proposal in the above patch, let me know what do you think (either in gerrit, here or privately). That's meant to be a temporary helper until a proper integration into requestctl is done.

Change 902107 merged by Volans:

[operations/puppet@production] superset: add static html for requestctl

https://gerrit.wikimedia.org/r/902107

With the new requestctl web UI I think it would be very useful if the current requestctl generator ( https://superset.wikimedia.org/requestctl-generator?q= ) would be adapted to work with the new web UI or (even better) ditched and get the same functionality embedded into requestctl web UI directly just providing the URL of a superset dashboard with filters.

The way we could do this is something as follows:

  • Add the CORS headers to superset to allow making authenticated requests from requestctl.wikimedia.org
    • add Access-Control-Allow-Origin: requestctl.wikimedia.org
    • add Access-Control-Allow-Headers: Authorization, Cookie, User-Agent (this might get refined)
    • add Access-Control-Allow-Methods: GET
  • Add a page to hiddenparma that accepts a superset url as input. We use this input to fetch the url via cross-subdomain ajax, and execute the same logic used in the code for the current requestctl generator. The result is submitted via POST
  • Use the POSTed data to find if there are any matching patterns/ipblocks to the filters created. If that's the case, select them; otherwise offer to create them. Once the user has checked all components of the expression are either available or newly created, an expression creation form is opened, with a pre-filled expression.

As an alternative, which I might actually prefer, all the process would remain server-side if we can grant access to the superset api via an api token or something similar to the web UI. I'll investigate if that's possible.

I am curious: should we keep this open or should this be resolved now given that we have requestctl.wikimedia.org and that takes care of most of the pain points?