Change #1079350 merged by jenkins-bot:

[operations/deployment-charts@master] Add chart-renderer namespace

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

Change #1079345 merged by CDanis:

[operations/puppet@production] Add chart-renderer deployment server profile

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

Change #1079350 had a related patch set uploaded (by CDanis; author: CDanis):

[operations/deployment-charts@master] Add chart-renderer namespace

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

Change #1079345 had a related patch set uploaded (by CDanis; author: CDanis):

[operations/puppet@production] Add chart-renderer deployment server profile

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

Oups, looks like I forgot to remove the Diffusion mirrors at the time I have deleted the Gerrit repository. Thank you for the cleanup @Aklapper !

I deleted https://phabricator.wikimedia.org/diffusion/GSER/ / rGSER and https://phabricator.wikimedia.org/diffusion/GSTN/ / rGSTN in Diffusion which have been throwing a 403 for years in our server logs, trying to mirror non-existing https://gerrit.wikimedia.org/g/mediawiki/services/service-runner/ ...

Any updates on this?

Hi @VirginiaPoundstone! Thanks for the detailed questions! I'll try to answer them one by one :)

Change 287148 abandoned by Hashar:

[operations/puppet@production] Set conservative retry limits & delays

Reason:

Last update in 2016 and T134456 got marked resolved a few days after this proposed change.

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

Had a quick chat with @JAllemandou to think through some open questions we need to answer across teams.

@Eevans In that case, I'll change the data model to drop it! Will update this thread when it's done.

In T343855#9226451, @Htriedman wrote:

@Eevans Understood! I'll make that change to the schema soon.

As far as returning a single DPPageviews vs. an array wrapped in DPPageviewsResponse: I was waiting on changing that until we discussed/decided unequivocally that only one response was necessary. Do you all think it makes sense to re-implement the ability to return all page_ids for a given (project, country, year, month, day) tuple if page_id is not included?

@Eevans Understood! I'll make that change to the schema soon.

Speaking here only with respect to the data model:

Hi all! I've made updates to the codebase to better comply with @Eevans' feedback, resulting in a greatly simplified interface. I've listed the following design changes below:

In T343855#9190791, @JAllemandou wrote:

It feels wrong to me to be willing to return all page views on a date: the result set would be enormous and wouldn't be API convenient.

It feels wrong to me to be willing to return all page views on a date: the result set would be enormous and wouldn't be API convenient.
As for per-title indexation, we have that already done for the current version of pageview, so I assume it'd be feasible?

To summarize a meeting between @Htriedman and myself:

Some of them are just artifacts of starting from a fork of one of the legacy services. For example, we'll want to adopt a new (better) convention for keyspace and table naming; Names like "local_group_default_T_dp_pageviews".datawere generated by the RESTBase codebase. Likewise, the "_domain" attribute (which is always set to analytics.wikimedia.org for these services) was done to appease RESTBase, and isn't something we should be perpetuating. Easy changes, mostly cosmetic.

Apologies for the amount of time that has passed, I only just noticed this ticket.

In T343855#9111286, @Htriedman wrote:

1. Ensure that (a) historical data is loaded into cassandra (currently this is ~15-20 GB of data) and (b) that new data will be loaded into cassandra on a daily basis (~15-20 MB per day).

Hi all! It's been a few weeks without activity, so I'm following up on this request.

I'll call this Resolved for now; though no doubt we'll want to extend and improve the service (including the potential for using it from the k8s/orchestrator service) in future, but we're done as initially conceived.

Mentioned in SAL (#wikimedia-operations) [2023-08-10T13:45:10Z] <oblivian@deploy1002> Finished scap: Backport for [[gerrit:945534|Add wikifunctions object cache (T297815)]] (duration: 09m 09s)

Mentioned in SAL (#wikimedia-operations) [2023-08-10T13:37:38Z] <oblivian@deploy1002> oblivian: Backport for [[gerrit:945534|Add wikifunctions object cache (T297815)]] synced to the testservers mwdebug2001.codfw.wmnet, mwdebug1001.eqiad.wmnet, mwdebug2002.codfw.wmnet, mwdebug1002.eqiad.wmnet, and mw-debug kubernetes deployment (accessible via k8s-experimental XWD option)

Mentioned in SAL (#wikimedia-operations) [2023-08-10T13:36:00Z] <oblivian@deploy1002> Started scap: Backport for [[gerrit:945534|Add wikifunctions object cache (T297815)]]

Change 945534 merged by jenkins-bot:

[operations/mediawiki-config@master] Add wikifunctions object cache

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

Change 945621 merged by Giuseppe Lavagetto:

[operations/puppet@production] mediawiki::wanrouter_cache: add wikifunctions placeholder

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

Change 945621 had a related patch set uploaded (by Ahmon Dancy; author: Ahmon Dancy):

[operations/puppet@production] mediawiki::wanrouter_cache: add wikifunctions placeholder

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

Change 945534 had a related patch set uploaded (by Giuseppe Lavagetto; author: Giuseppe Lavagetto):

[operations/mediawiki-config@master] Add wikifunctions object cache

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

Change 944248 merged by Giuseppe Lavagetto:

[operations/puppet@production] mediawiki::wancache: add the wikifunctions pools and routes

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