Posts
-
Toolforge Jobs Framework
This post was originally published in the Wikimedia Tech blog, authored by Arturo Borrero Gonzalez.
This post continues the discussion of Toolforge updates as described in a previous post. Every non-trivial task performed in Toolforge (like executing a script or running a bot) should be dispatched to a job scheduling backend, which ensures that the job is run in a suitable place with sufficient resources.
-
Toolforge GridEngine Debian 10 Buster migration
This post was originally published in the Wikimedia Tech blog, authored by Arturo Borrero Gonzalez.
In accordance with our operating system upgrade policy, we should migrate our servers to Debian Buster.
As discussed in the previous post, one of the most important and successful services provided by the Wikimedia Cloud Services team at the Wikimedia Foundation is Toolforge. Toolforge is a platform that allows users and developers to run and use a variety of applications with the ultimate goal of helping the Wikimedia mission from the technical side.
-
Wikimedia Toolforge and Grid Engine
This post was originally published in the Wikimedia Tech blog, authored by Arturo Borrero Gonzalez.
One of the most important and successful products provided by the Wikimedia Cloud Services team at the Wikimedia Foundation is Toolforge, a hosting service commonly known in the industry as Platform as a Service (PaaS). In particular, it is a platform that allows users and developers to run and use a variety of applications with the ultimate goal of helping the Wikimedia mission from the technical side.
-
Iterating on how we do NFS at Wikimedia Cloud Services
This post was originally published in the Wikimedia Tech blog, authored by Arturo Borrero Gonzalez.
NFS is a central piece of infrastructure that is essential to services like Toolforge. Recently, the Cloud Services team at Wikimedia had been reviewing how we do NFS.
-
Last couple of talks
In the last few months I presented several talks. Topics ranged from a round table on free software, to sharing some of my work as SRE in the Cloud Services team at the Wikimedia Foundation. For some of them the videos are now published, so I would like to write a reference here, mostly as a way to collect such events for my own record. Isn’t that what a blog is all about, after all?
-
Debugging ip token set RTNETLINK error
At the Wikimedia Foundation they configure basically all servers with IPv4/IPv6 dual stack, at least in the control plane interface (those used for SSH management, etc). IPv6 is not supported yet on the Cloud Services dataplane (openstack), but it will in the “near” future.
An elegant solution for this IPv4/IPv6 dual stack configuration in the control plane is to embed the IPv4 address into the IPv6 address, something like this:
-
Openstack Neutron L3 failover issues
In the Cloud Services team at the Wikimedia Foundation we use Openstack Neutron to build our virtual network, and in particular, we rely on the
neutron-l3-agentfor implementing all the L3 connectivity, topology and policing. This includes basic packet firewalling and NAT.As of this writing, we are using Openstack version Train. We run the
neutron-l3-agenton standard linux hardware servers with 10G NICs, and in general it works really well. Our setup is rather simple: we have a couple of servers for redundancy (note: upstream recommends having 3) and each server runs an instance ofneutron-l3-agent. We don’t use DVR, so all ingress/egress network traffic (or north-south traffic) flows using these servers. Today we use a flat network topology in our cloud. This means that all of our virtual machines share the same router gateway. Therefore, we only have one software-defined router. -
Netfilter virtual workshop 2020 summary
Once a year folks interested in Netfilter technologies gather together to discuss past, ongoing and future works. The Netfilter Workshop is an opportunity to share and discuss new ideas, the state of the project, bring people together to work & hack and to put faces to people who otherwise are just email names. This is an event that has been happening since at least 2001, so we are talking about a genuine community thing here.
It was decided there would be an online format, split in 3 short meetings, once per week on Fridays. I was unable to attend the first session on 2020-11-06 due to scheduling conflict, but I made it to the sessions on 2020-11-13 and 2020-11-20. I would say the sessions were joined by about 8 to 10 people, depending on the day. This post is a summary with some notes on what happened in this edition, with no special order.
-
How to use nftables from python
One of the most interesting (and possibly unknown) features of the nftables framework is the native python interface, which allows python programs to access all nft features programmatically, from the source code.
There is a high-level library, libnftables, which is responsible for translating the human-readable syntax from the
nftbinary into low-level expressions that the nf_tables kernel subsystem can run. Thenftcommand line utility basically wraps this library, where all actual nftables logic lives. You can only imagine how powerful this library is. Originally written in C,ctypesis used to allow native wrapping of the shared lib object using pure python. -
Debconf 2020 online, summary
Debconf2020 took place when I was on personal vacations time. But anyway I’m lucky enough that my company, the Wikimedia Foundation, paid the conference registration fee for me and allowed me to take the time (after my vacations) to watch recordings from the conference.
This is my first time attending (or watching) a full-online conference, and I was curious to see first hand how it would develop. I was greatly surprised to see it worked pretty nicely, so kudos to the organization, video team, volunteers, etc!
What follows is my summary of the conference, from the different sessions and talks I watched (again, none of them live but recordings).
-
A better Toolforge: a technical deep dive
This post was originally published in the Wikimedia Tech blog, and is authored by Arturo Borrero Gonzalez and Brooke Storm.
In the previous post, we shared the context on the recent Kubernetes upgrade that we introduced in the Toolforge service. Today we would like to dive a bit more in the technical details.
-
A better Toolforge: upgrading the Kubernetes cluster
This post was originally published in the Wikimedia Tech blog, and is authored by Arturo Borrero Gonzalez and Brooke Storm.
One of the most successful and important products provided by the Wikimedia Cloud Services team at the Wikimedia Foundation is Toolforge. Toolforge is a platform that allows users and developers to run and use a variety of applications that help the Wikimedia movement and mission from the technical point of view in general. Toolforge is a hosting service commonly known in the industry as a Platform as a Service (PaaS). Toolforge is powered by two different backend engines, Kubernetes and GridEngine.
-
seville kubernetes meetup 2019-10-24 - summary
Yesterday I attended a meetup event in Seville organized by the SVK (seville kubernetes) group. The event was held in the offices of Bitnami, now a VMware business.
The agenda for the event consisted in a couple of talks strongly focused on kubernetes, both of which interested me personally.
-
What to expect in Debian 11 Bullseye for nftables/iptables
Debian 11 codename Bullseye is already in the works. Is interesting to make decision early in the development cycle to give people time to accommodate and integrate accordingly, and this post brings you the latest update on the plans for Netfilter software in Debian 11 Bullseye. Mind that Bullseye is expected to be released somewhere in 2021, so still plenty of time ahead.
subscribe via RSS