I've got everything noted in an etherpad for now: https://etherpad.wikimedia.org/p/labels

@calbon I took a pass through and made a couple of suggestions. Overall, I think this looks great!

In T263910#6505937, @Ladsgroup wrote:

If there are scores missing from the stream, feel free to hit the endpoint but I suggest waiting for scores from the stream before hitting ores so that way you filter at least 99% of them and then hit us for the 1% (which I'm pretty sure the stream is much better than 99% but let's assume it's so bad that's two 9s)

@Aklapper we already have solid unit and integration tests in place for Wikilabels. This ticket is proposing adding an additional testing framework (which has a large number of dependencies) for UI testing only, which I just don't see the value in right now. Additionally, we have plans to deprecate Wikilabels in the near future over concerns with the UI. Both of these reasons are why which is why this ticket was declined.

Invalid now due to major changes in the codebase.

Marking this as resolved. Draft Quality/Draft Topic/Article Topic are all included now on https://www.mediawiki.org/wiki/ORES

Marking this as resolved as we understand the limitations that celery brings with the current design of ORES and it will not be included during the next iteration.

Going to mark this as resolved since we have good idea of what is needed to migrate and will not be moving ORES in it's current form to k8s.

Adding some notes:

In T182331#6253315, @Halfak wrote:

Some notes from the deployment pipeline meeting:

• ORES K8s and COW - https://phabricator.wikimedia.org/T182331
  • Takes advantage of CoW on a single machine
  • Containerization might mean that we significantly increase memory usage
  • This might add complexity and reduce capacity to ORES; i.e., sudden bursts of requests for uncommonly used wikis
  • Alex: loosing excess capacity is not a big loss ( more efficeincy); adding capacity in k8s is easier
    • ORES relying on CoW will cause migration and pain issues in future; i.e., the kernel does not break user space; however, memory allocations may change in future
    • Tricks like apertium are using: loading and dropping models on demand
    • Actual RSS 210GB, with CoW 56GB. We have a lot of uwsgi and celery running. Currently, we have tuned the software to the hardware. If we need more capacity now, we need to add equipment (weeks to months). With K8s, room for growth.
    • Other benefits: standardized deployments, rollback being easier (no mess with scap handling virtualenvs), automatic garbage collecting of images. also a lot more control of CI -- less work inside of puppet. More self-serve.
  • Aaron: we could say that we want to move *new* models to k8s -- want to ensure that we're using time efficiently
    • We have a backpressure system to determine whether or not we're running out of capcity (via queue and redis)
    • We need, though, to be able to handle random bots crawling uncommonly requested wikis -- how long does that scaling take?
      • Alex: seconds.
      • Aaron: if dynamic scaling is fast then that could give us more capacity that changes a lot -- how much is already built and how much would we have build ourselves for this scaling?
      • Alex: we can help the scaler by feeding it RpS to help it work better, but most components are there. We're not there yet; we're working with a contractor; it's on our roadmap. We should have that before end of September (hedging a bit).
• Aaron: we're worried about being trailblazers. Multi-container deployment in particular.
  • Tyler: PipelineLib exists. Not being used by other repos. No reason it shouldn't work. Re. deployment, there is not a lot of magic there that could fall apart (Helm and K8s -- not a trailblazer there).
  • Alex: Only trailblazing is the creation of two different container images from the same repo.

ORES CI-tests on Travis were introduced in https://github.com/wikimedia/ores/pull/253

This issue is no longer valid after moving to Prometheus

This is certainly do-able by hooking in to our custom EntityDiffBuilder class. We would just need to develop an algorithm and corresponding JS components.

Declining as Jade has changed quite a bit since this ticket was written and there is not a ton of value in implementing this for now.

@kevinbazira did the "badwords" and "informals" lists ever get merged?

Marking this as invalid as the codebase has changed considerably over the past year.

We have project-level documentation here: https://www.mediawiki.org/wiki/ORES

Declining this as we've discovered ORES will not fit on k8s in it's current design

We have https://ores-support-checklist.toolforge.org/