# OSMF OPS meeting

Thursday 25 July 2024, 19:00 London time, unless rescheduled
[Time in your timezone](https://www.timeanddate.com/worldclock/fixedtime.html?msg=OSM+Foundation+OPS+meeting+-++Thursday+25+July+2024&iso=20240725T19&p1=136&ah=1)
[Countdown](https://www.timeanddate.com/countdown/generic?p0=136&iso=20240725T19&msg=OSM%20Foundation%20OPS%20meeting%20-%20%20Thursday%2025%20July%202024)
[Online calendar](https://framagenda.org/apps/calendar/p/fce4xrpFGx7fMxz8)
[Subscription to future events](https://framagenda.org/remote.php/dav/public-calendars/fce4xrpFGx7fMxz8?export)
Frequency of meetings: every two weeks, on Thursday at 19:00 London time, unless rescheduled.
[Video room](https://osmvideo.cloud68.co/user/dor-x99-y3m)

## Participants
* Tom
* Paul
* Grant
* Sarah

## New action items from this meeting
* Grant to move the requirements regarding deployment of new production services that were mentioned during the 25 July meeting to the ops site in a "Policy" communication format. [Topic: Deployment of new production services]
* Grant to determine the Cloudflare API call to block IPs, in order to deal with scrappers [Topic: Cloudflare keep enabled?]
* OPS to make a reasonable evaluation whether to go with Cloudflare, Fastly or none. [Topic: Cloudflare keep enabled?]
* Paul to follow up with Copernicus and see if we can get rendering servers from them. [Topic: State of the Map Europe 2024]

# Agenda

## Deployment of new production services

Policy on reacting to requests to deploy new services in production without sufficient notice and on running of new unmanaged services.

* Agreed launch schedule ahead of time including Operations team.
* Ops require 7 day window for us to "production" deploy, complex sites may require additional time.
* Communicate to the Ops Group, not individuals.
--

Topic related to OSM 20 birthday website. Grant was asked to productionise it in very short notice. Suggestion to create a policy regarding requests to deploy new services in production and on running of new unmanaged services.

<u>On thic case and the machine hosting the OSM 20 birthday website</u>
* Grant was asking when can he productionise the OSM 20 birthday website, and on Monday was told that people were still working on it and they wanted the website to be deployed the next day.
* Plugins were added to the birthday website until the time it went live.
* The OSM 20 birthday website is currently hosted on fume which is intended as the location for community.openstreetmap.org
* Assumption of no long-term plans to use it, after the OSM 20 birthday.
* The plugins aren't being updated and WordPress isn't being updated because it's disabled from Chef, as they have a lot of unmanaged changes that still need to be moved back into Chef.
* They might not have thought of the time required and not understand the technical implications, like the website needing back-up.
* There might be a problem with communication.

<u>Suggestion regarding this case</u>: Move the birthday website a couple of weeks after the birthday.

<u>Policy suggestions</u>
Set the right expectations from the start:
* Schedule needed to be known in advance.
* Give at least one week notice for deploying new services in production, sometimes more depending on the service, instead of couple of hours.

<u>Points to be turned into a ticket and a policy</u>
* Agreed launch schedule ahead of time, including Operations team.
* Ops require a 7 day window to "production" deploy, complex sites may require additional time.
* Communicate to the Ops Group, not individuals.

<u>Other points mentioned during discussion</u>
* There was also disagreement by OPS about the website being done in WordPress. OPS now have a ticket about a policy regarding WordPress websites.

**'''Action item: Grant to move this to the ops site in a "Policy" communication format.'''**

Post-meeting additions: https://github.com/openstreetmap/operations/issues/1125

## Proposed CPU upgrades for odin / ysera
https://github.com/openstreetmap/operations/issues/1105#issuecomment-2227267807

Xeon Gold 5120 -> Xeon Gold 6148 (40% improvement?)
https://www.cpubenchmark.net/compare/3154vs3176/Intel-Xeon-Gold-5120-vs-Intel-Xeon-Gold-6148
Xeon Gold 6148 is ~£140 each

"2nd Gen Intel® Xeon® Scalable Processors and Intel® Xeon® Scalable Processors
Dual Socket Socket P (LGA-3647) supported, CPU TDP supports Up to 205W TDP, Dual UPI up to 10.4 GT/s"

General agreement on upgrade. Paul and Grant will finalise on which CPU to upgrade to. We will upgrade ysera.

## Cloudflare keep enabled?

Practical Issue:
* Site deployment are more difficult, deploys need to be synced. Also require cache purge.
* Scrapers are not being blocked at moment because their access is masked by Cloudflare.

We should evauate the different options benefits / negative points.

---

We have Cloudflare enabled - it's doing proxying. Performance: the website loads really fast, API feels sluggish.

* Cloudflare might tell us at some point that the free plan is not suited to us, due to the data volume.
* Fastly is also an option, as it also has DDOS protection.

<u>Practical Issues</u>
* Site deployment are more difficult, deploys need to be synced. Also require manual cache purge. We need to ensure that all 3 front-ends switch at the same time.
* Scrapers are not being blocked at the moment because their access is masked by Cloudflare. That might explain why the API seems a bit more sluggish and the difference in response size that we're seeing in CGI map.

<u>On suggestion of sticky or semi-sticky mapping from client IP to machine</u>
* Probably won't work.
* Issue: We relied previously relied on the fact that browsers would typically load all the assets from the same machine that they loaded the page from. They're unlikely to use a different I{ address to load the subsidiary assets, whereas Cloudflare doesn't know that. So if somebody loads the page and then asks the asset, they go to a different back end, get a 404, because that backend hasn't deployed yet and they cache that 404 for a while.

<u>Related to Cloudflare cache rules</u>
We have limited ability to control Cloudflare settings, as we're using the free tier. We have 10 cache rules and currently using one.
* Cloudflare is caching 404s.
* Rules can be on the following request parameters: cookie referrer, SSL, URL, user agent, request headers, cookie value, file extension.
* We're interested in response parameters. There is a Cloudflare setting "browser cache TTL", to "determine the length of time cloudflare instructs a visitor's browser to cache files", however it does not affect for how long Cloudflare caches the 404.
* Tiered caching enabled on Cloudflare, which does cross-cache queries via the closest server to your servers and that becomes the primary cache server.
** Not worth it with tiles.
** Might work for DDOS attack.

<u>Related to Cloudflare IP access rules</u>
* They don't disclose a limit on them.

<u>Related to Cloudflare block rules</u>
* Has reasonable number of block rules.

<u>Cloudflare</u>
* They don't seem to put access restrictions for particular countries.
* Privacy concern raised by some community members, also raised for Fastly.

<u>On having Cloudflare or a CDN being in front of everything at the moment</u>
* In principle happy, ignoring scrapper and deployment issues.

<u>Other points mentioned during discussion</u>
* We need a CDN in front, for attacks.
* Could use Fastly, as it also has DDOS protection, and have pin or semi pin between backend and IP.

<u>Related to scrappers</u>
* People are not supposed to use generic user agents for requests - OPS has a policy.
* Suggestion: Figure out if there are any obvious candidates for blocking scrappers and manually add them.

<u>On performance issues</u>
* Performance issues started on the night before the DDOS attack, when we did the RAM changes on the server.
** An index might need rebuilding, or it is necessary to restart the daemons, to flush out dead connections (recommended by mmd).
** One of the tables does seemed to be doing a lot more index scans.
** Ability to turn it on all the time?

**'''Action items'''**
* Grant to determine the Cloudflare API call to block IPs, in order to deal with scrappers.
* OPS to make a reasonable evaluation whether to go with Cloudflare, Fastly or none.

## SOTM Europe 2024

Paul talked to Copernicus https://www.copernicus.eu/en. They were a sponsor of the conference https://stateofthemap.eu/, they are located in Warsaw and Frankfurt, and use our standard tile layer. They also have a cloud provider (CloudFerro) and Paul to follow up and see if we can get rendering servers from them.

## Upgrade CPUs in Ironbelly
''Related to ticket [https://github.com/openstreetmap/operations/issues/1124#issuecomment-2255620898 - openstreetmap/operations Upgrade CPUs in ironbelly] (Issue #1124)''

Ok with the upgrade.

## Open Ops Tickets
Review open, what needs policy and what needs someone to help with...
https://github.com/openstreetmap/operations/issues
https://github.com/orgs/openstreetmap/projects/1
https://github.com/orgs/openstreetmap/projects/1/views/2?filterQuery=-is%3Aclosed

## Action items
* ~~[2024-07-11](https://hackmd.io/oU9CCUivSPyNUWrp7FP2tQ) Grant to find equivalent storage options for Karm and Eddie [Topic: DB server drives]~~
* ~~[2024-07-11](https://hackmd.io/oU9CCUivSPyNUWrp7FP2tQ) OPS to consider whether to add extra filters. [Topic: DDOS]~~
* ~~[2024-06-27](https://hackmd.io/Gxa-ukx6SuKKNlu7lokf6A) Grant to send an announcement about the OAuth status on Monday. [Topic: OAuth]~~
* ~~[2024-06-27](https://hackmd.io/Gxa-ukx6SuKKNlu7lokf6A) Paul to see if we're still appropriately balanced on the CDN and then OPS to decide on upgrading the RAM of Odin. [Topic: rhaegel usage?]~~
* [2024-06-27](https://hackmd.io/Gxa-ukx6SuKKNlu7lokf6A) OPS to do capacity planning for tile.openstreetmap.org [Topic: rhaegel usage?]
* ~~[2024-05-30](https://hackmd.io/IM0d3VWhTqWcY-FPwgXy-A) OPS to add the SDRP requirement to the Editor Policy draft and see what feedback we receive. [Topic: Editor Policy] # On the 2024-06-13 agenda~~
* [2024-05-02](https://hackmd.io/6VQhtcbqRYKDSwx1i-fpWg) OPS to revisit the OpenMapTiles application. # 2024-06-13 They haven't responded to the questions. Paul to email them again.
* ~~2023-05-18 Paul to start an open document listing goals for longer-term planning. [Topic: Longer-term planning]~~

## OPS pads for 2024 meetings
* [2024-03-21](https://hackmd.io/pnBMmOtbQHmweS2XqC8E6g)
* [2024-04-04](https://hackmd.io/O2KUiG9RQXSk9vMAgPA7Dw)
* [2024-04-18](https://hackmd.io/_FT8I1sSRL2UNVDM94IbQA)
* [2024-05-02](https://hackmd.io/6VQhtcbqRYKDSwx1i-fpWg)
* [2024-05-16](https://hackmd.io/XFtol8teRoinL34n7h2bcA)
* [2024-05-30](https://hackmd.io/IM0d3VWhTqWcY-FPwgXy-A)
* [2024-06-13](https://hackmd.io/rDX4FuDfRa-0Trc0IKFJ5Q)
* [2024-06-27](https://hackmd.io/Gxa-ukx6SuKKNlu7lokf6A)
* [2024-07-11](https://hackmd.io/oU9CCUivSPyNUWrp7FP2tQ)
* [2024-07-25](https://hackmd.io/iyFjUWl1RY6D_pevem8ciA)
* [2024-08-08](https://hackmd.io/su12wMb9TR2kd1I5lLJ8vw)
* [2024-08-22](https://hackmd.io/ky2mjfvdTnaJFk9K98TL_g)
* [2024-09-05](https://hackmd.io/A15F6GBrTgKfcXQkaTzDiQ)
* [2024-09-19](https://hackmd.io/yqkAQF6FT2OzmLqNR7I7_g)
* [2024-10-03](https://hackmd.io/Bd98MgqETlyqM1YDoUkq6Q)
* [2024-10-17](https://hackmd.io/wIMfTi0jSVi07XoCN3RFrg)
* [2024-10-31](https://hackmd.io/dqE6-AIvSjmPU31IJ2MtCA)
* [2024-11-14](https://hackmd.io/gru50cHsSvetMprTz7gJ7Q)
* [2024-11-28](https://hackmd.io/mei-vI-bRmSxkWAfWX-jlw)
* [2024-12-12](https://hackmd.io/PXNLnaX_R4OvqQWSyXzzHw)
* [2024-12-26](https://hackmd.io/u3nFsnpQSpCitJL2xe5Hzg)

**[Minutes published on the OSMF website](https://osmfoundation.org/wiki/Working_Group_Minutes#2024)**

### Automatic addition of OPS meetings to your calendar
If you want future OPS meetings to be automatically added to your calendar,
you can subscribe to the following [iCalendar link](https://framagenda.org/remote.php/dav/public-calendars/fce4xrpFGx7fMxz8?export). Instructions on how to do
that depends on which calendar software/service you use. The link is provided
for your convenience.

Note that:
* This might not work when Framasoft servers experience problems.
* You might get delayed updates, depending on how often the calendar service
from your side syncs/checks for updates.