Daily performance reports keep asking to rebuild container

[downey (Michael Downey)]

Reproduce:

1. Enable the site setting daily performance report (“Analyze NGINX logs daily and post a Staff Only topic with details”).

2. Update the Docker image:

   cd /var/discourse
   ./launcher rebuild app

Expected Results:

• A report appears in the “Staff” category periodically.

Actual Results:

• An error message appears in the “Website performance reports” topic in the “Staff” category:

Report is only available in latest image, please run:
cd /var/discourse
./launcher rebuild app

[Falco (Rafael dos Santos Silva)]

2 Update the Docker image:

cd /var/discourse
./launcher rebuild app

You need a git pull before the rebuild as seen here:

How do I manually update Discourse and Docker image to latest?

If you self-host Discourse, you occasionally need to run a manual update via the command line to get the latest security releases newest libraries. These updates are not picked up in admin/upgrade, which is why you’ll occasionally need to do this additional step. Discourse itself should be updated about twice a month, by clicking the “Update to Latest Version” button in your admin dashboard ( admin/upgrade). We do beta releases roughly once every week. Every two months we recommend SSH’ing…

[codinghorror (Jeff Atwood)]

Not necessarily I thought the launcher command did an implicit git pull @sam?

[sam (Sam Saffron)]

That change was only made in the last year, very possible @downey has an older git repo.

[downey (Michael Downey)]

Don’t know exactly when the change happened but I thought I’d updated
fairly recently. After doing the first rebuild I could have sworn I saw a
git pull but I didn’t watch carefully enough. As soon as I can take a
little more downtime (probably tonight) will try again.

[downey (Michael Downey)]

I definitely did a full git pull and then ./launcher rebuild app last night … but still getting the same bug every day instead of a performance report.

Can anyone reproduce? Is anyone able to successfully get the performance report?

[Stefan]

I’m having the same issue. My guess is that because ./launcher rebuild says “Your version of Discourse Docker is ahead of origin” when git tries to get the latest version, so the latest version is never pulled?

[sam (Sam Saffron)]

Likely, can you just check out discourse-docker from scratch?

[Stefan]

Actually what I did was git reset --hard origin/master to have the repository in sync again and then another./launcher rebuild (that didn’t trigger the “ahead of origin” message). Now I’l wait to see if I get the reports. Is there any way to trigger those reports manually so that I don’t have to wait?

[Stephen]

Visit /sidekiq/scheduler and trigger Jobs::DailyPerformanceReport AFAIK?

[Stefan]

That worked, thanks! Now I get the report and that’s really nice!

[downey (Michael Downey)]

FWIW, I did the git reset --hard origin/master and then ./launcher rebuild app and still have the same problem.

[downey (Michael Downey)]

Has anyone else seen this problem? (Or can reproduce it if they’re willing to try to enable the option?)

Edit: @Lee_Ars & @Sander78 you were both reporting this in another now-locked topic, are you still having the problem?

Is there somewhere I could look to see if my Docker image is the right version or has the right code to do this?

[Sander78 (Sander Datema)]

Yep, still there. Eventually I turned it off.

[sam (Sam Saffron)]

If you give me access to your host I can have a quick look

[sam (Sam Saffron)]

I don’t want to cause an outage @downey but you have an old pattern in your template:

You have:

volumes:
  - volume:
      host: /var/discourse/shared
      guest: /shared

It should be:

volumes:
  - volume:
      host: /var/discourse/shared
      guest: /shared

  - volume:
      host: /var/discourse/shared/var-logs
      guest: /var/log

This in turn causes 2 things:

1. You are storing logs inside the container… which is bad
2. Permissions are not ideal on that logs

[Dax (Daniela)]

In my case the sysadmin deleted Staff category when we installed discourse (3 years ago).

Now I have create another Staff category (only admins and staff can create/reply/see it).
This category was created before the last upgrade to Discourse Docker Image 1.3.3 (so we have git pull and rebuild all and the upgrade was a success).

By the way in logs I have this error when I trigger Jobs::DailyPerformanceReport in sidekiq:

Have I missed something?

[downey (Michael Downey)]

So this week I did a completely new install on a new box following the standard instructions and script, and this problem is back

[riking (Kane York)]

You need to set the hidden site setting staff_category_id to the ID of the new staff category.

There’s no UI to do this (because it’s hidden, you’re not supposed to change it), so you need to muck with request editing

[downey (Michael Downey)]

You are storing logs inside the container… which is bad
Permissions are not ideal on that logs

So this week I did a completely new install on a new box following the standard instructions and script, and this problem is back

Looking at the “stock” out of the box installation, I see the following volumes that were set up:

volumes:
  - volume:
      host: /var/discourse/shared/standalone
      guest: /shared
  - volume:
      host: /var/discourse/shared/standalone/log/var-log
      guest: /var/log

Anything wrong with that that would be causing this problem to appear?