Hello dear community
Let me start with adding some nuance to the title: profile images (stored in /edx/var/edxapp/media/profile-images) aren’t ‘gone’ - they’re still there, but the naming convention/mechanism in Lilac seems to have changed. Consequence: file names are not found, even though the database of users was migrated from Ironwood. We also can’t find the image names anywhere in the database.
Does anyone have any pointers?
Hello @Glotzbach,
I haven’t reproduced it but from the code-base, I can say that the issue is real.
In edx-platform it does not store information about the user’s profile image in DB. Instead, it uses PROFILE_IMAGE_SECRET_KEY to generate unguessable URLs.
Now, if we talk about the issue then this PROFILE_IMAGE_SECRET_KEY has been renamed to PROFILE_IMAGE_HASH_SEED with this commit.
A quick workaround for you will be to rename the secret key back to PROFILE_IMAGE_SECRET_KEY in your edx-platform (Assuming that you have copied your settings from the previous release).
cc: @Diana_Huang
Hi @jramnai
As I was informed
We’ve taken the value of PROFILE_IMAGE_SECRET_KEY from Ironwood and used it as PROFILE_IMAGE_HASH_SEED in Lilac
And our profile images now show again.
Many thanks!
Thank you very much @jramnai for sharing this information.
I think this PR is incompleted. Because I found that PROFILE_IMAGE_SECRET_KEY remained unchanged in some other places such as configuration repository. @Diana_Huang could you confirm and help us to finish it please?
and I was totally unaware of this fact that profile images are kept on the filesystem (OpenStack native installations) so they must be transferred to the new server during upgrade process. Do you agree that it should be a step of the readthedocs upgrading manual or at least there should be a note about this? @nedbat
Yup, I can help with fixing this in configuration. I’ll try to have a PR up to switch things over in the configuration repo tomorrow.
Configuration has been updated. I also added the fix to the Lilac master branch.
Hello @Diana_Huang,
Thanks for the fix on Lilac and master.
But I can see that this profile key has been renamed in open-release/juniper.master, so with this juniper and koa both have this culprit. So, the fix should be added on the juniper and koa, too (I know Open edX doesn’t support these releases).
And I am not sure that how it will help people when they are upgrading from older releases (as they will be having the old name in the profile key and copying the configs to the new release).
Just a concern.
While you’re right that we don’t support releases older than the current one, since this change made it into lilac.master it would only be fair for us to mention it in the upgrade instructions. Any chance you can send us a PR? That would expedite the process greatly.
In any case, thanks for bringing this to our attention.
@jramnai
I’ve written a code snippet that helped me to rename all our old images. I ran it on my koa instance and transferred the renamed images to my new lilac instance. although it’s been written for my own usage, it might be usable for the community after a little modification.
rename_profile_images.py (2.7 KB)
This change was made into the juniper release though incomplete as the configuration repo was not updated at that time. So, it is totally unfair if we don’t mention this thing to the community.
At least we should inform people that this piece of work is broken in juniper and koa release which is fixed in lilac so that in the future, people who face this problem can refer to the doc.
I will be happy to help, will send one.
This is really nice but most of the times when we do upgrade we do copy our configs from the old release to the new one and I guess most of the people in the community follow the same. And there are chances that people do use AWS S3 to store profile images.
By “this change” I had meant the configuration one. I don’t mean to split hairs, though. You’re right that the way this whole thing happened was less than ideal. It’s just that you’ll find, if you haven’t already, that this is not the only example of edx/configuration being out of sync with edx-platform. As a community, we’ve all just learned to live with it - most of us just run our own forks, and some of us try and contribute the changes upstream.
The good news is that this is poised to improve. The move to Tutor as the community supported deployment mechanism together with the Core Contributor program should reduce the incidence of these sync problems for Maple and beyond.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.