The cron was disabled in prep for the DB upgrade. See T138460#2437836

So can it be at least ran manually now, please?

It was disabled because work running on the database slave would interfere with the upgrade. Running the report from a master database might be too much for it to handle.

As I comment on T138460#2454534, the slave is available from this very moment, after I fixed several data integrity issues.

We can either enable the crons back or wait for the db-master failover, I will be waiting for your feedback.

Can/Should this (the weekly report script) be run manually now but not enable the crons (there's other things there) until after the failover?

@greg That's exactly what I was asking earlier...

In T139950#2455764, @Danny_B wrote:

@greg That's exactly what I was asking earlier...

but now it is possible! :) I'd be willing to do it, but I'll leave it to @mmodell

Can/Should this (the weekly report script) be run manually now but not enable the crons (there's other things there) until after the failover?

I do not know if you are asking me or your team. In case it is me:

I would suggest re-enabling everything if the failover is going to take a few days (and given the understandably slow pace this maintenance is going, I would recommend it). I am blocked on you at T138460 to setup a date for the failover. The only "but" is that it will have to be disabled again when the failover happens (or moved to another slave).

You have the last word, just ping me on IRC with a decision (but please no unpuppetized things, not matter if temporary).

@jcrespo: I thought we were ready to go ahead with the failover and then we could reenable the cron jobs afterward.

@greg, @Danny_B: I'll run the job manually for now

Why don't you just enable the report separate from the other maintenance things?

It's a separate thing anyways..

190     # project changes mail (T85183)
191     # disabled due to maintenance: T138460
192     phabricator::logmail {'projectchanges':
193         ensure       => absent,

Ok, I just ran the community_metrics script manually.

In T139950#2463954, @Dzahn wrote:

Why don't you just enable the report separate from the other maintenance things?

It's a separate thing anyways..

190     # project changes mail (T85183)
191     # disabled due to maintenance: T138460
192     phabricator::logmail {'projectchanges':
193         ensure       => absent,

Sure I have no problem with that, though the other cron jobs are also important.

Change 299093 had a related patch set uploaded (by Dzahn):
phabricator: re-enable community metrics mail

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

And the weekly stats?

The weekly stats should have been sent when I ran the script manually.

@mmodell Obviously haven't as https://lists.wikimedia.org/mailman/private/phabricator-reports/2016-July/thread.html shows.

I think the archive of that list is private? Is only the archive and the access privat, or is the "can write a mail to the list" access restricted too? Could be the reason.

The stats generator can obviously send to the list. List archive is accessible to anybody who is maillist member (anybody can sign in).

Change 299093 merged by Dzahn:
phabricator: re-enable community metrics mail

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

For the record: It was not generated today as well.

And none of those previous manual attempts mentioned above generated that.

Cf. T85183: "Project creation/edits log" cronjob email for Phab admins and rOPUP1cc6c30e95ae: phabricator: send maintenance mail to list not individuals

Change 299663 had a related patch set uploaded (by Dzahn):
phabricator: re-enable project-changes email

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

Change 299663 merged by Dzahn:
phabricator: re-enable project-changes email

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

i also ran the command manually and it got send to the mailing ist now