The webperf node in Beta Cluster would be be similar to the webperf1001 and webperf1002 nodes in production.
It would run coal, navtiming, and the performance site. Where coal and navtiming would consume from beta's kafka brokers, and produce to beta's statsd/graphite hosts. That should happen automatically given Hiera configuration, but would be good to confirm.
The main thing that'd be useful to be able to test is the performance site. E.g. changes to its Apache configuration and other things that require puppet changes, which we can then cherry-pick ourselves to beta's puppet-master.
The navtiming/coal would mostly be dormant, but that's fine.
Aside from the performance site, it'd also be a useful place to be able to test upgrades to XHGui, as well as T195312 in the future.
* {icon check color=green} performance::site - https://performance-beta.wmflabs.org/
* [ ] performance::coal
** Check the web API is up and working.
** Fix the JS to actually use the relative local one instead of hardcoding prod url.
* [ ] webperf::statsv
** Check that /statsv beacons requests to Beta varnishes result in webperf/statsv writing to Beta statsd/graphite.
* [ ] webperf::navtiming
** Check that NavigationTiming data from Beta EventLogging is written to Beta graphite/frontend.navtiming.
* [ ] coal::processor
** Check that NavigationTiming data from Beta EventLogging is written to Beta graphite/coal.
Issues:
* [x] `profile::webperf` fails due to `kafka_config('jumbo-eqiad')` being production-specific. – https://gerrit.wikimedia.org/r/436435
* [ ] `webperf::statsv` and `webperf::navtiming` failing due to repos missing from scap::sources on deployment-tin. – T196034, https://gerrit.wikimedia.org/r/436581
* [ ] `webperf::statsv` and `webperf::navtiming` failing due to host missing from scap::dsh. – <https://gerrit.wikimedia.org/r/436586>
* [ ] ..