Config: deprecated notification for projects without config file

[humitos]

When we detect a build project is built without a Read the Docs configuration file (.readthedocs.yaml) we show multiple notifications:

• a static warning message in the build detail's page
• a persistent on-site notification to all maintainers/admin of the project
• send a weekly email (at most)

This is the initial step to attempt making users to migrate to our config file v2, giving them a enough window to do this and avoid breaking their builds in the future.

Note: I didn't put too much effort on the copy of the notifications. I'd appreciate some input here, @agjohnson.

---

Static warning message

---

On-site notification

---

Email

I don't have a rendered version because I'm using the dummy email backend, but it works fine.

Closes #10348

[humitos]

@agjohnson I updated the code here with all the suggestions.

Note that the scheduled Celery task contains a db-intense query. Well, it's not just one intense CPU query, but they are multiple small ones that may affect the db. I'd suggest to take one web-celery instance, update the code with this PR, run a specific queue (--queue="config-file-notifications") and trigger the task on it before deploying it to production, so we can see how it behaves. I can do this manually tomorrow, so we send the notifications when they are scheduled to be sent 😉

[humitos]

I did a quick test of that chunk of code in production using 35k projects as limit and it took 205s, which increasing the CPU load of the db in a noticeable way. After that, I tested it with 55k projects and it took 295s without noticeable MAX CPU increase in the graphs. I think we will be fine.

Note: we have around ~550k projects

[humitos]

If we are happy with this blog post readthedocs/blog#219, we can merge it and change all the links that point to the config file v2 documentation to point to this blog post that explains in a simpler way how to update/create the config file.

[agjohnson]

Just some small tweaks, nothing that needs to block this. I think we'll be tweaking the task query a little bit going forward, but for now it might just incur some false negatives if a project has a lot of active versions. But this will only be annoying to the maintainer, and would still accomplish notifying users that we need to update their configuration.

[humitos]

Note that the scheduled Celery task contains a db-intense query. Well, it's not just one intense CPU query, but they are multiple small ones that may affect the db.

The query seems to not be a problem for our database. I just executed it in production and checked the CPU usage and it's fine. It's around the normal in EU mornings, so we are fine I guess.

However, it takes forever to calculate the initial list of projects we need to contact. I think we can reduce this by removing the spam projects from this query. This will also help us to reduce the number of emails we send and avoid killing our email reputation too. I will add this now and continue with the tests here.

[humitos]

OK. The query ran and finished on production:

In [38]: deprecated_config_file_used_notification()
Projects: 82872
Seconds: 1741

This is 30m to get all the projects that we need to contact. Using spam_score = 300 this gave us 82k (from 250k) projects to contact.

[humitos]

This is getting closer.

Tune query to be one notification per user, instead of one per user per project

This is done, but I'd like to have more eyes here since it was not trivial. I think it may be possible to make it more db performant, but that will complicate the query making it more appealing for mistakes.

I did a test running these queries in production and I found that we have ~82k projects affected by this and ~68k users to contact. Some of these users have multiple projects affected. I estimate the task requires around 1h30m to complete with this amount of users based on my tests.

Include cutoff date in the notification message

I added them as a starting idea. There are more work to do here, tho, but we need to finish the blog post first.

[agjohnson]

Just a couple of notes before I forget

[humitos]

OK. I took some decisions here and updated this code:

• we are sending onsite notifications to about 60k users
• we are not sending emails just yet because we want to test this a little more before sending massive emails (it's commented for now)
• we are deploying the code for emails notifications so we can send some emails from production and test everything is in place
• next week's deploy will include email notifications to be sent weekly
• we can send the emails notification manually if we feel comfortable just by running the task from the django shell
• if we need to make some last-minute adjustment, we can hotfix since this code is not going to be auto-executed until tomorrow

Let me know if there is anything you want to change here and I will do it. Hopefully, before this code is executed tomorrow.