Is there some documentation for migration?

@Lydia_Pintscher Do we want to serve the querybuilder under query.wikidata.org? or under some other domain?

So looking at the traffic layer change a little more....

I gather this is in stalled/waiting to be verified?
I'd be pro leaving it in verified if that is the case so it is not forgotten about (it's not actively blocked on something).
Or is this in stalled waiting as it isn't deployed?

Looking at the first few these edits seem to always leave some descriptions behind which then need to be cleared up https://www.wikidata.org/w/index.php?diff=1292704464&oldid=1292658459&title=Q25945246

Comparing the request pattern for strings vs the math datatype highlights the issue.

Interestingly for one of the pages you link to the page_prop now appears, for the other it does not.

I'm going to go ahead and close this inactive ticket per the comment above.
T233520#6416660 was recently reopened but I dont think also having this open serves us at all.

I'm going to go ahead and close this inactive ticket per the comment above.
T233520#6416660 was recently reopened but I dont think also having this open serves us at all.

Resolving this and the final tiket tackling this issue will be T266823

I just +2ed the last change mentioned in my above comment.
Which means we should be able to actually retire wikibase-codensiffer after the next release, which will either be v33 or v32.1

@thiemowmde do you remember from your analysis if there were any others that it would make sense to move?
Per T253624#6373219 it looks like the requirements there are met and all the sniffs needed to retire wikibase-codesniffer are now in the mediawiki code sniffer (or will be in the next release)

2:21 PM <bblack> addshore: https://phabricator.wikimedia.org/T266702#6588396
2:23 PM <addshore> bblack: <3 ty
2:42 PM <ema> addshore: we also already do something similar for wdqs https://gerrit.wikimedia.org/r/plugins/gitiles/operations/puppet/+/refs/heads/production/hieradata/common/profile/trafficserver/backend.yaml#154
2:42 PM <ema> /bigdata/ldf -> wdqs1005.eqiad.wmnet/bigdata/ldf
2:42 PM <ema> everything else to wdqs.discovery.wmnet
2:42 PM <addshore> aaaah nice
2:43 PM <ema> the very important thing is that we don't rewrite the uri_path
2:43 PM <ema> like in /bigdata/ldf -> wdqs1005.eqiad.wmnet/bigdata/ldf
2:43 PM <ema> we don't want to deal with uri rewrites at the caching layer if at all possible
2:46 PM <ema> addshore: so /sparql -> wdqs_service/sparql is great :)
2:46 PM <addshore> ack, thats probably all perfect :)
2:47 PM <addshore> I may copy these logs into the ticket so that I don't loose the links

In T266702#6588396, @BBlack wrote:

We can route different URI subspaces differently at the edge layer, based on URI regexes, as shown here for the split of the API namespace of the primary wiki sites:

https://gerrit.wikimedia.org/r/plugins/gitiles/operations/puppet/+/refs/heads/production/hieradata/common/profile/trafficserver/backend.yaml#263

In T266702#6586844, @Dzahn wrote:

Took this to say I will take care of the puppet part to get these on miscweb. But that may be a subtask and I should have waited for the list. (?)

Looks like this is still occurring in 1.36.0-wmf.14 too on a variety of wikis

A note on this ticket that per T264710#6586070 we are going to further decouple the deployment of the UI and the blazegraph backend.

I'm going to decline this task for now.
The release strategy hike may end up deciding to do in this direction, but the reasons this ticket was created originally are far gone now.
T235639: Decouple Query Service UI deployment from Query Service deployment was merged into T241291: Simplify WDQS Packaging which is also now done.
The next step is further decoupling this deployment per T264710#6586070 and we can move on from there in the future.

Sounds like a fine solution from our side for now.
I'll let serviceops do with this ticket as they wish (keep it or close it) and I'll get on to creating some tickets for:

1. Moving wdqs UI to static sites
2. Deploying the querybuilder ui to static sites

• I supsect we can easily get the number of edits per user from the analytics cluster. Perhaps we can just copy that the the user table every now and then?

I don't know if it's possible to move data between the analytics cluster and production (IIRC it's not) but that's a good idea in general to have a pipeline from these two so we can update some tables from analytics cluster (like QueryPage special pages and querycache table)

True!

In T263298#6564942, @Ramsey-WMF wrote:

@Lydia_Pintscher and @Samantha_Alipio_WMDE - given that WMDE is drafting new stuff for the REST API, I'd defer to you on ideas for how this kind of change should apply in more general use cases. On our side, we're fine with a param on wbeditentity

In T59745#6556199, @1234qwer1234qwer4 wrote:

Um, is this supposed to be fixed? Currently, PLBot still redirects a lot of the items emptied by a merge.

In particular, it is notable that a lot of events are happening just in the minute after 22:00 UTC

We could also consider:

• bundling docker-compose?
• running docker-compose in a docker-container? (although doing this as part of a dev environment prototype gave me a headache last time)

Each service should define volumes for this sort of thing probably.
Example in mwdd-v1 https://github.com/addshore/mediawiki-docker-dev/blob/4d380cf638bc60b5b6c22853a199639a3eb70b0b/docker-compose/mw.yml#L42-L43
No different to the requirement for persistent data for dbs for exmaple https://github.com/addshore/mediawiki-docker-dev/blob/4d380cf638bc60b5b6c22853a199639a3eb70b0b/docker-compose/db-replica.yml#L39-L40

Not sure what some good defaults for the dev environment are, but higher than 30 sounds sane.
In reality this should probably be a little higher than production timeouts? (as production is expected to be faster?)
Also documenting how to easily change these would be a +

If the usecase for this is only for being able to pass in environment variables such as MW_LANG and other mediawiki related settings then I do not think that should be in the scope of the development environment.

I smell a fish and suspect that this is the same issue as in T235554#6435256 T235554: net::ERR_HTTP2_PROTOCOL_ERROR 200 on Docker MediaWiki hosted on Cloud VPS maybe?

I think some progress has been made here in tickets such as:

• T262369: mediawiki-docker test feature
• T262365: mediawiki-docker destroy feature
• https://gerrit.wikimedia.org/r/c/mediawiki/tools/cli/+/597156 (env command)

pretty sure this is fixed in https://gerrit.wikimedia.org/r/c/mediawiki/tools/cli/+/622790 ?
And a further improvement tracked in T260656

In T260656#6500715, @jeena wrote:

Is this accomplished by https://gerrit.wikimedia.org/r/c/mediawiki/tools/cli/+/622790?

Looks like https://github.com/joho/godotenv/pull/108 might be merged now, so this can probably be updated now?

I agree that some of these things should live in .env and be used an env vars.
I think any further mediawiki customizations should be done in LS.php directly though.
This minimizes the complexity and responsibilities of the development environment.

Description could be slightly improved, is this mw docker destroy?

I think quibble is a nice to have, but should be pushed further down the line.
I like the layout of the commands discussed in the description and also the "automagic" switching to the appropriate container based on if "php" is specified or "npm" for example, switching between some php image, or fresh for example.
This is different to mwdd-v1 and I like it (it exposes the idea of "fresh" https://github.com/addshore/mediawiki-docker-dev/tree/4d380cf638bc60b5b6c22853a199639a3eb70b0b#mediawiki-fresh )

It might be nice to add a bit of extra logic somewhere in this stack to make this automatically discoverable and configured no matter which one of the commons dev environments you use, rather than switching from one hard coding to another.

Hmm, I'm not sure if this is the sort of thing that should be documented with the development environment at all?
config and setting up extensions doesn't really relate to the dev environment (or in my opinion should not).
The instructions on how to install and configure WikibaseLexeme are at https://www.mediawiki.org/wiki/Extension:WikibaseLexeme

A note on how mwdd v1 handles this currently.

I haven't been following along with the progress of the feature, but as I understand it lots of work has been done, should this RFC be closed now?

Another key usecase that came up was retrieving data for one or more known entities, but expanding the statement properties and values to include label data.
Ultimately this is just a search or a lookup, with more data that is just contained within the matched entity.
Not something we have an API for currently, but something that can be done with 2 calls, or something that may be covered in a future graphql api

In T114772#6542420, @Ladsgroup wrote:

@Ladsgroup do me this issue of display seems like a smaller part of the whole rename problem anyway?

Specially given that most of it is in the gadget, I assume it's not our job but we need to make sure the validation of frontend code at least accepts aliases.

@WMDE-leszek Looks like this was not picked up in story time again, were there more open questions? (Sorry I could not attend)

Okay, it looks like the one reamaining open question is around this example:

So we always want to store a canonical site id for the JSON and various other indexes (rather than changing it as renames happen).
Do we always want to display the canonical one in the UI? or would we prefer to show something else?
This is probably something that needs a little product consideration cc @Lydia_Pintscher
Once we have that answer I think we want to write some ACs ready for pickup and perhaps strip down some of the old description leaving a potential example of service implementation.

In T263298#6539196, @Cparle wrote:

Ok @Multichill I've talked with @Addshore and we think possibly the simplest thing is to introduce a param that you can pass with the api call to ask it to throw an error if there's a duplicate. Does that work for you?