Currently the service being used in beta is the production server citoid.wikimedia.org; this should be switched to a master deploy on wmflabs, perhaps citoid.wmflabs.org.
|Declined||None||T92304 Separate citoid service for beta that runs off master instead of deploy|
|Open||None||T100099 Meeting: Automatic deployment of backend services on beta cluster|
|Open||None||T95652 On beta cluster citoid should self update and reload after change is merged|
citoid.wmflabs.org runs off of master, while citoid-beta.wmflabs.org (from deployment-prep) runs off of deploy, so closing this task as invalid.
If @Mvolz meant that Citoid in deployment-prep should run off of master, I agree with that, but that is a larger problem related to services in deployment-prep. We hope to address that once we have a real staging cluster in place - staging would then run deploy, while deployment-prep could run master.
What I was hoping for is a way to catch bugs on http://en.wikipedia.beta.wmflabs.org/ for versions of citoid that are further ahead, not what's currently deployed.
This doesn't necessarily have to be master but it should be before the current deploy.
@Jdforrester-WMF, should we change beta to run off citoid.wmflabs.org instead of citoid.wikimedia.org so it's running off of master instead of deploy?
IMHO, that'd be the right move given the current constraints.
However, note that we have discussed this with RelEng at the Lyon Hackathon and there is consensus to move towards services being run off of master in Beta (cf. T100099: Meeting: Automatic deployment of backend services on beta cluster)
So apparently we have this now? https://wikitech.wikimedia.org/wiki/Nova_Resource:Citoid.services.eqiad.wmflabs
But, it's currently failing to provision:
I've gotten email notifications to that effect two days in a row: "Puppet is failing to run on the "citoid" instance in the Wikimedia Labs