|Open||None||T53494 Use Beta cluster as a true canary for code deployments (epic)|
|Open||None||T87220 Minimize differences between beta and production (Tracking)|
|Open||None||T211677 Support IPv6 in beta|
|Open||None||T211575 Enable IPv6 on tools.wmflabs.org|
|Open||None||T220306 Add IPv6 monitoring|
|Open||None||T37947 Enable IPv6 on CloudVPS|
|Open||aborrero||T209460 CloudVPS: our ideal future model|
|Open||aborrero||T207536 Move various support services for Cloud VPS currently in prod into their own instances|
|Open||None||T207543 Move labmon (Graphite, StatsD) into a Cloud VPS|
We have dedicated hardware for this, in the case of labmon1002, a fairly new server which was put into works some months ago.
I'm unaware of any debate to move away from the current model.
+1 to this task.
The rationale it the same as the parent tasks and is not new: anything that crosses the VPS instance -> production barrier is unsafe and undesired. Imagine e.g. a Graphite or statsd vulnerability; especially given that these are not products that were designed to run over unsafe networks or the Internet and haven't been scrutinized as much.
That said, I wouldn't say that the requirement is to move to a VPS per se. If, for instance, at some point in the future bare metal servers in the labs realm become possible, that could be a possibility too. The ask (at least my ask!) would be for this instance-supporting service to live outside of the production realm (and 10/8 space etc.), and I don't have strong opinions on where else they should live :)
Yeah, can't just waste hardware, but at the same time I'm not sure this shouldn't be done purely on that basis. Is that hardware particularly special? Maybe there is another use for it?
That's what this task is for :)