2024-06-27 OPS meeting

# OSMF OPS meeting Thursday 27 June 2024, 19:00 London time, unless rescheduled [Time in your timezone](https://www.timeanddate.com/worldclock/fixedtime.html?msg=OSM+Foundation+OPS+meeting+-++Thursday+27+June+2024&iso=20240627T19&p1=136&ah=1) [Countdown](https://www.timeanddate.com/countdown/generic?p0=136&iso=20240627T19&msg=OSM%20Foundation%20OPS%20meeting%20-%20%20Thursday%2027%20June%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 * Sarah * Grant * Tom * Paul * Guillaume * Branko Kokanovic (Microsoft) ## New action items from this meeting * Grant to send an announcement about the OAuth status on Monday. [Topic: OAuth] * 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?] * OPS need to do capacity planning for tile.openstreetmap.org [Topic: rhaegel usage?] ## Agenda ## Matomo Discuss on access request. Branko to ask LWG whether the privacy policy allows that. Branko (Microsoft) talked with Paul at SotM US 2024 and asked to do some stuff with Matomo. Microsoft started AB testing the SSO and the results are suboptimal. Only 35% of people who encounter the OSM sign-in proceed to complete the sign-up process.The reason for this drop-off is unclear to MS, prompting a request for analytics from the OSMF side. They wish to use Matomo to see the number of visitors and sign-ups, to better understand the sign-up funnel. Also the MS team offered to do other analytics that the OPS lack the time to perform. Currently, OPS do not use Matomo. **Options include:** * Provide answers. * Grant them access to Matomo. **Concerns** * Setting a precedent, as access is not typically granted to others. * Privacy/personal data issues. * Corporate nature of the request. **Information logged by Matomo** * Account creation statistics are logged. * Matomo does not display the full IP address, discarding the last two bytes for IPv4 addresses. * Geolocation is performed before discarding the last two bytes of IPv4 addresses. * Log-ins are shown in real-time. * If a user is logged in, the UserID is anonymised in Matomo, showing only a hashed version. * We do not log user progress through the sign-up process, as this feature is unavailable in the free version of Matomo. **Other Matomo info** * Matomo shows that the copyright page is the top landing and exit page, with a bounce rate close to 100%. * Fewer than 1% of site visitors sign up. * With the removal of the terms page, the sign-up funnel is minimal. Users must fill in the form and confirm their account. Suggestions * Require non-disclosure agreements (NDAs) to be signed. ** An NDA alone is insufficient. Changes would have to be made to the Privacy Policy https://osmfoundation.org/wiki/Privacy_Policy if Matomo access extends beyond internal use. ** It might boil down to trust, as OSMF cannot audit Microsofts's use of the data once access is granted and will not know who within Microsoft is accessing it. *** Access would be granted to individuals, not to Microsoft as an entity. * Get input from the LWG. * Have Microsoft lawyers review our privacy policy and provide an opinion on the appropriateness of granting access under an NDA. ** This review could be done, but it might take several months. ### Decision seemed to be * Microsoft to ask LWG whether our privacy policy allows granting Matomo access to Microsoft * Branko offered to initiate the legal review process within Microsoft in parallel to assess the implications of OSMF granting access to Matomo under an NDA. ----- ## SOTM EU attendance Paul is attending. Tom and Grant are currently undecided. ----- ## OpenMapTiles Postpone to future call. We require additional time to review the detail. They replied. * Opposed to adding anything other than OSM Carto clone. * There are no answers on the status of their licence change or the branding issue. On uniqueness * The cartography is intended to be identical to an existing layer. * Technically it is unique, as vector tiles are inherently different from raster tiles. Other points mentioned during discussion * New vector style might be introduced. Decision: Look at their answer in more detail. ----- ## OAuth Status Brownouts continue. Editors are now generally good-to-go. 1st July go-date seems ok. Grant to push out an announcement. * Tom ran it overnight from midnight to 07:00 UTC. * Potlatch 3 ok now. **Action item: Grant to send an announcement about the OAuth status on Monday.** ----- ## rhaegal usage? rhaegal as tile render server or keep for future vector? Server not needed for vector testing now. Paul to look if servers are currently correctly balanced. Also discussed: https://github.com/openstreetmap/operations/issues/1105 We need to do capacity planning for tile.openstreetmap.org * We had reserved rhaegal for Vector Tiles, but Paul happy with Faffy (dev server). * Preference to not have rhaegal as a raster tile server. On the suggestion to add more rendering capacity in Europe * rhaegal is less powerful than Odin and Ysera, which have queues. When they haven't got a mass dirty event, they're not dropping anything, just using the queues as a buffer. * The increase in load is being driven by the fact that we're using more accurate expiry now. The increase was when we switched to pgsql expiry. * Look at performance of Ysera vs Odin. ### On Odin and Ysera * Odin and Ysera are past their predicted life-span. We had specced them out to last 5 years. * Number of coses: 28 cores. * CPUs: 6-7 years old. Suggestions: * Upgrade Odin and Ysera to the same clases as newer European render servers. * OPS to look at performance of Ysera vs Odin, as Ysera now has more RAM. ** Some improvement ~ 10% extra performance. ** There's an open ticket. Cost: EUR 260+ to upgrade the ram + remote hands cost. * Could double the number of calls in the system and go slightly higher clock rate, but it's probably about a GBP 1000 per machine. ** Not worth it. Other points mentioned during discussion * At worst we're serving about 5% dirty tiles of what hits the back end, and missing virtually none. * Rams equally clocked at both machines. Discussion on graphs Missed tiles: Where we served a 404 because we were not able to render it in time. Dropped tiles: where the tile was dirty, but the queue was really full, so we have failed to queue it. ### Action items * **Paul to see if we're still appropriately balanced on the CDN and then OPS to decide on upgrading the RAM of Odin.** * **OPS need to do capacity planning for tile.openstreetmap.org** ----- ## "OSM PPA" work approval Grant ok to build "OSM PPA" for Debian 12 using GitHub actions? Will use github actions private runner for ARM64 builds until 2025 (Catford hosted cluster of Raspberry Pi 5) Estimate of work required 1 week. Based on https://salsa.debian.org/salsa-ci-team/pipeline (builder) (debootstrap) Florian https://wiki.openstreetmap.org/wiki/User:Flohoff had sent an email. Suggestions * Discuss the design offline. * Use package.io - is a commercial repo, but they do have an open source option. On arm building * Discuss the design * Currently it is a tricky requirement, as if you use emulation with GitHub actions, it is extremely slow (GDAL takes 6 hours to build and hits a timeout). It will probably be similar for Mapnik. * Grant has some scripts for private testing. Other points mentioned during discussion * Build step is some wrapper shell scripts. * The DSC tells it where the source is and it downloads the source from there and builds it. * Estimated amount of work: 1 week. * 5 packages to be built. Some are just available in backports. CGImap is blocking us moving with the six front ends. ### Feedback Tom and Paul in favour of Grant working on OSM PPA, as it will allow us to unblock a lot of Debian moves. ### Action item * **Grant to check whether the free version of package.io will cover us.** ----- ## Editor policy public current draft? No pushback from SDRP. Suggestions * Publish draft for review. Other points mentioned during discussion * Opinion expressed opposing the foundation putting a requirement that someone has to join the SRDP. * Related comment by R. Fairhurst ''email pasted in the chat during the meeting.'' Points to consider * whether requiring to be a member, would be a conflict with the SDRP's mandate and, * whether it would also be at odds with the foundation's mission to support but not control the project. '''Action item: Grant to publish the updated draft for feedback and we will review at next Ops call. Feedback period 2 weeks.''' ----- ## Fastly Fastly wants us to use things like their image tool processing tool "image optimizer" to serve Webp when the browser supports it. * Fastly's aim: For communication purposes. On Fastly's "image optimizer" * Can change the format of your image based on whether or not the client supports webP. * Is not enabled on our account yet, but can be enabled in a couple of minutes. On image file formats * If we're going to serve Webp and PNG, we should be generating webp and then converting it to PNG. * Webp can be faster to generate with mod-tile in some instances than a compressed PNG, depending on the compression. Other points mentioned * Most browsers can handle it well if they are instructed to load a PNG file but are actually served a WebP file. * Most browsers since IE5 do content sniffing. Concern: Would need to be open source, to power www.osm.org. Compute and the image processing stuff are different from the CDN. === On visualisation example mentioned === * Example of what could be created: map showing a percentage of our tiles, as flashing squares. Or a heat map. * Tom had produced a nice map showing tile usage in Prometheus or Grafana. It was based on the metrics that Fastly provide of how many tiles they were serving from each cache. * The visualisation probably does not have to be in real time, but might be nice to have. Issues: * We do not know exactly what they want. * We probably do not have the bandwidth to take such a project on. Fastly: * They might be more interested in where the people were that were requesting tiles rather than what tiles they were requesting. * Could do the sampling and send a percentage of logs. * Do not want access to our logs. * They have some visualisation people. Other points mentioned * Map on Mastodon showing the date shifting, posted by Paul. However, it is not suitable for real time. === Contract === * 9k/month pretend value, excluding the actual bandwidth. ----- ## 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-06-13](https://hackmd.io/rDX4FuDfRa-0Trc0IKFJ5Q) Grant to email SDRP and copy OPS and Guillaume * [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] * [2024-06-27] Branko to ask LWG whether the privacy policy allows giving editor authors access to Matomo. **[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.

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.