Yep, that's what I saw during the beta cluster instance setup, too. It's how I ended up with just -c <configFile>.yaml as override_cmd in that service definition.
As for your last question, I'm guessing the implementation will fall either to Product Infra or to the Structured Data PHP devs.
@mpopov Thanks for drafting a schema! Some thoughts:
- page_id should be fine.
- tag_id — it seems like you have in mind here either a row ID or some other arbitrary unique identifier, but since page_id is required, maybe we could just use the Wikidata ID string here? (Wikidata ID + image SHA1 digest uniquely identify a label suggestion in the underlying table.)
- wait_time — is this the time elapsed between submitting the labeling request(s) and receiving a response, or the time between the user opening Special:SuggestedTags and the tags being loaded from the DB and presented? The former may or may not be interesting if we ultimately use Google as our MV provider, since we'll be planning to use batched, asynchronous labeling requests.
- We'll also be storing voting results in the DB, as well as per-provider confidence scores (see here). Perhaps it's redundant to log these in EL? Actually, now that I look at the needs in the description more closely, reversion is the only piece that isn't accounted for in the DB schema.
The above is live on deployment-wikifeeds01.deployment-prep.eqiad.wmflabs, btw.
Yeah. I also had some difficulty getting the service to read the correct config when setting up on the Beta Cluster. This is the config I finally landed on, using an override_cmd to point to the correct config file:
Mon, Sep 16
Wikifeeds is up and running, but appears to be using the config.yaml from the service repo root (symlinked from config.dev.yaml) rather than the config defined in the chart.
blocking on design
Fri, Sep 13
Thu, Sep 12
@bearND @jlinehan When you get a moment, could you please check https://gerrit.wikimedia.org/r/#/c/operations/deployment-charts/+/535533/ and update the description as appropriate based on whether you have the option of voting +2?
Wed, Sep 11
The broken mobileapps test is fixed. If there's no further action required in RESTBase or Parsoid then let's call this resolved.
19 months of silence spells "declined" to me.
No use case, and the PCS media endpoint that this refers to is deprecated.
Stopping /page/definition pregeneration appears to have helped, but we're still seeing a nontrivial number of worker deaths.
Tue, Sep 10
Hi @Jcross, thanks for the heads-up. That sounds OK to me, but I've started a convo on the parent ticket to confirm that'll suffice for production deployment.
Hi @greg, I'm wondering, is there any difference between the requirements for enabling a new extension on a production test wiki and a "real" production wiki? We are hoping to enable this on testcommonswiki ASAP, but not necessarily full commonswiki until closer to the feature launch date.
I'd prefer to keep this open for further discussion, or at least until any superseding tasks are created. As @dr0ptp4kt mentioned, this will be a major focus for Product Infrastructure this FY.
I'd probably be remiss if I didn't point out the existence of: T89971: ApiQueryImageInfo is crufty, needs rewrite
@jcrespo Ah, sorry about that. I don't believe anything here needs to be private.
Probably the most unusual thing going on in this extension, which I should mention specifically here, is the getTitlesWithUnreviewedLabels method in the Repository class, which returns the least recently added or served image. That functionality was added recently in https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/MachineVision/+/534724/.
@jcrespo Sure. Here are a few samples from my local machine:
This seems like essentially a duplicate of T227355: DBA review for the MachineVision extension. I'm going to close this task in favor of it. Please feel free to chime in there, or reopen this if you think it deserves to be a separate task.
The response will be consumed by frontend code within the extension itself, and is supported by an API help page with example queries; there's no need for additional documentation, and any we did create would no doubt swiftly become outdated and misleading.
@Jhernandez I don't think there's anything to link to; this is just to give the Performance team a chance to look over the extension before initial deployment. I know @egardner wanted a chance to update some of the frontend JS code before that happens. I think we'll be ready to ping Performance by late this week or the beginning of next week.