Hello Wikitech,
I’m a new SRE on the Search team. As Ryan and I are in the middle of relocating many large shards on our Elastic cluster, I wanted to ask your thoughts about using jumbo frames and/or LACP for our physical Elastic nodes. We’re also moving to new hardware 10Gbps networking, so it seems like a good time to start optimizing our network settings.
Let us know what you think (and please feel free to suggest any other optimizations).
Best,
Brian
The service Etherpad (https://etherpad.wikimedia.org) might be unreachable
during the following maintenance window:
This Thursday, Feb 10th 2022, from 17:00 UTC to 18:30 UTC (9 to 10:30 AM PST).
It will be upgraded to a new version on a new server during this time.
We hope the
actual downtime will be much shorter than that but you should not count on it.
While existing pads should not be affected by this in any way, please
keep in mind that in general this is a service without an SLO
supported on a best effort basis.
Best regards,
Daniel
--
Daniel Zahn <dzahn(a)wikimedia.org>
Operations Engineer
Despite the importance of on-wiki code (gadgets, site scripts and user
scripts) to our projects, there are no guidelines on how to write code in
skins, extensions in a way that supports these users.
The lack of guidelines historically has created unnecessary conflict
between editors and Wikimedia developers. For example, the common task of
changing a class name can cause havoc with certain gadgets that depend on
associated styles.
Another significant pain point, is now that we are tracking JavaScript
errors across our projects, broken gadgets have become more of a problem,
as they make it harder for us to find and triage errors in existing user
workflows.
I have spoken to various developers across MediaWiki extensions and it
seems pretty clear to me that a policy would be helpful for establishing
expected norms.
I've begun drafting a policy based on the discussions I've been having with
Wikimedia engineers on:
https://www.mediawiki.org/wiki/User:Jdlrobson/Extension:Gadget/Policy and
am inviting *Wikimedia developers who build skins or extensions, and gadget
developers* to engage in the existing talk page topics and bring up new
topics. You can also reply directly to me, either personally or publically
if you have any feedback you want me to consider.
Thanks in advance for your participation in this process.
This email is a summary of last week's Wikimedia production deployment of
1.38.0-wmf.20
- Conductor: Ahmon Dancy
- Backup Conductor: Brennen Bearnes
- Blocker Task: T293961 <https://phabricator.wikimedia.org/T293961>
🔢 Stats
Sparklines comparing with the last 5 trains.
- 346 Patches ▁▇▇▇█
- 0 Rollbacks ▁█▁▂▁
- 0 Days of delay ▂█▁▂▁
- 2 Blockers ▂▃▆█▁
🎉 Trainbow Love ✨Thanks to folks who reported or resolved blockers:
- Raimond Spekking
- Samuel
Hi,
I am aware of the various limits in the NewPP report. I'm trying to
determine if we currently we have some max page size (before or after
processing).
The documentation on mw.org and en.wp is a bit confusing on the subject and
personal experimentation shows that substituting templates allows be to go
past the 2MiB page size.
If we don't have such a limit, I'm not exactly sure why do we need the
Post‐expand include size limit? Why is output generated by transclusion
harder on the parser than output directly in the page?
Thanks,
Strainu
Hi Sir/Ma'am
I am new to Open Source contributions.I am keenly interested in
contributing to the Wikimedia Open-Source Organization. I am an
undergraduate with knowledge in Frontend Development with the skill set of
Html,Css,Js,ReactJS(Javascript Library). I have been working on projects
based on Web Development. I would like to begin contributing to the
projects and issues.
Please, can I get some guidance on how to get started with any of
the projects.I am going through some references. But it would be great If I
get a path to follow on which it follows this techstack as provided by me.
Thanks and Regards,
Raag Bhutani
Hey everyone I was working on Videocuttool issue
https://phabricator.wikimedia.org/T297992 and now the issue is resolved but
I am unable to push the patch. I have properly set the ssh key on both my
system as well as gerrit and also did the steps many times but still facing
the problem. It will be great if anyone can help me in it .
Thanks
Regards Shreyaans Jain
Yes, it's much prettier than dbtree. Nice!
On Thu, Feb 3, 2022 at 4:48 PM Aaron Schulz <aschulz(a)wikimedia.org> wrote:
>
> I really like the visual tree on https://orchestrator.wikimedia.org/ . Good work!
>
> On Tue, Jan 4, 2022 at 3:18 AM Manuel Arostegui <marostegui(a)wikimedia.org> wrote:
>>
>> Hello,
>>
>> If you don’t use tendril.wikimedia.org or dbtree.wikimedia.org, feel free to ignore this message.
>>
>>
>> As of today, tendril is now retired and the main page is replaced with a list of replacement for different services tendril used to provide:
>>
>>
>> For checking out our dbtree and replication data:
>>
>> if you are in the NDA LDAP group, use Orchestrator
>>
>> otherwise, use the information page on noc.wikimedia.org. For more detail you can also check eqiad.json or codfw.json
>>
>> If you are looking for slow queries log, go to slow queries dashboard using our standard observability platform (logstash) (NDA required)
>>
>>
>> Tendril has been a great tool for us during the years, but unfortunately it is impossible to maintain with modern MariaDB versions (it uses TokuDB, which is no longer available on MariaDB after 10.1 and needs to be compiled separately) nor its webservice is compatible with modern php versions. Its database is still running on Stretch and on MariaDB 10.1 (which has not been supported for a year already) and it is having serious scalability issues. This would unblock us from removing a lot of legacy home-brew craft and replace them with more modern toolings such as orchestrator.
>>
>>
>> Orchestrator has been in place for a few months now, and provides us with a great way to see and (in the future) manage replication topologies. For now we are using it only for visualization purposes but in the future we’d like it to also help us to handle replication changes (it can be done from the UI or via CLI) and recover topologies automatically if they fail and involve masters or intermediate masters.
>>
>>
>> The slow queries dashboard in logstash offer multiple advantages over tendril. You can set the threshold to see slow queries that took longer to run. You can filter out code paths you’re not interested in or zoom in to relevenet code paths. You can limit it to write queries or read queries only. Also, it provides id of the request making the slow query, so you can cross check it with the rest of logstash or hadoop to identify problematic behavior.
>>
>>
>> If you need it for the transition period, you can still access it in tendril-legacy.wikimedia.org. But it will be shut down in a month. You can follow the work of shutting down tendril in https://phabricator.wikimedia.org/T297605.
>>
>>
>> Thank you.
>>
>>
>> _______________________________________________
>> Ops mailing list -- ops(a)lists.wikimedia.org
>> To unsubscribe send an email to ops-leave(a)lists.wikimedia.org
>
> _______________________________________________
> Ops mailing list -- ops(a)lists.wikimedia.org
> To unsubscribe send an email to ops-leave(a)lists.wikimedia.org
--
Daniel Zahn <dzahn(a)wikimedia.org>
Operations Engineer