I'm not planning to work on it, but maybe someone else in WMCS is?

This hypothesis is now complete. Through a structured survey of Toolforge admins, we evaluated and prioritized sustainability categories based on platform sustainability impact and WMCS scope alignment.

Thanks @Ladsgroup – everything seems to work as expected (successfully logged in with SUL, wikitech, gitlab), at least on Chrome with my personal profile. On the Wikimedia-managed Chrome, neither Wikitech nor GitLab will let me log in. Well, Wikitech let me at first, then on a second attempt is claiming wrong credentials. Probably some browser-related shenanigans, will try clearing the cookies and such.

In T376267#10452640, @Ladsgroup wrote:

I can rename Slst2020@wikitech to another username (e.g. Slst2020 (usurped)@wikitech) and then rename Slavina Stefanova to Slst2020 in wikitech. Would that work for you?

So I have a Wikitech account (Slavina Stefanova) that is not linked to any SUL account right now. I tried to create a SUL account with the same name, but am getting the message "Cannot create account: The username is already in use. Please pick another name." As far as I can tell though, there is no SUL Account with that name. Separately, I have a another Wikitech account (Slst2020), linked to a SUL account with the same name. That Wikitech account is inactive, and I wouldn't care about deleting it altogether. What would be the best way to "solve" this?

@Isaac I know you are following this space quite closely – any new thoughts since your comment from 2023?

In T383344#10445057, @taavi wrote:

Who is "we" here?

We can now test if the v2.12 release makes this possible.

Harbor v2.12 has been released. We need to test if the new enhancements to robot accounts are enough for what we want to do. More generally, we'd like to have maintain-harbor use a robot account instead of the too-widely scoped regular user account it uses right now.

Happy new year!

Hi @Don-vip ! A bit late to this because of holidays and such – is this still happening?

Have you tried using streaming XML parsing for processing the wiki dumps? Most programming languages offer ways to process XML files sequentially without loading them entirely into memory. Since you mentioned you're only interested in article pages, you could filter for namespace 0 during parsing and skip other content entirely. The memory usage stays roughly constant regardless of dump size, typically requiring only whatever the parser's buffer needs. Your actual memory needs would be determined by your text analysis requirements for individual articles, not the dump size.

Has this worked for you in the past, then started failing today?

We pivoted to implementing end-to-end deployment of a continuous job before adding build-related features. The minimal cli already exists, but build features haven't been implemented on the API side yet.

I did this as part of the migration to the standardized path naming a few months ago. Only the current blueprints are left:

Hi @Multichill ! Please edit the task to include all the info needed, see https://phabricator.wikimedia.org/project/manage/4834/, so that your request can be processed. Thanks!

In T380832#10357169, @aborrero wrote:

I think the actual problem was T380844: 2024-11-26 Toolforge DNS incident.

This is related to T380844: 2024-11-26 Toolforge DNS incident

Is this still needed? The 1.28 upgrade went ahead as planned.

we might want to add an endpoint for bulk deletion of deployments so that we can clean them up easily

To me, the ideal feedback UX that I've experienced on other sites (example: https://testdriven.io/ – feedback button in lower right corner) looks something like this:

created the repository https://gitlab.wikimedia.org/repos/cloud/toolforge/components-cli and copied the repository settings from envvars-cli

That's great to hear, thank you!

@Don-vip is this something you'd still want, or could we close this task?

might this be related to the wikitech SUL migration?

done – the deprecation warning is gone now.

tools.automated-toolforge-tests@tools-bastion-12:~$ webservice shell
tools.automated-toolforge-tests@shell-1730880334:~$

In T362069#10291828, @dcaro wrote:

I think this can be considered done no?

Done – thank you!

sstefanova@cloudcontrol1005:~$ sudo wmcs-openstack database quota show mwoffliner
+-----------+--------+----------+-------+
| Resource  | In Use | Reserved | Limit |
+-----------+--------+----------+-------+
| backups   |      1 |        0 |     2 |
| instances |      1 |        0 |    10 |
| ram       |   4096 |        0 |  4096 |
| volumes   |     75 |        0 |    75 |
+-----------+--------+----------+-------+

Yup, it's because I've (still) not deployed this. It's on my todo list now.

This being a recurring maintenance task of sorts, should we maybe include it in clinic duty?

No concern at all – thank you for the update. :)

In T370115#10244109, @taavi wrote:

Would be great if this didn't rely on me.. but done.

@Audiodude I interpreted your request as needing another 4GB of RAM for Trove. If this was not the correct quota increase, please let me know.

Done!