-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migrate from 5.0 to 5.5 #46
Comments
Could you provide more details? |
I am making the assumption that this is not just me, so purposefully left the details out. The basic problem is that if I replace my current version 5 taiga docker repository with the 5.5 one it fails. Perhaps I need to do an export and reimport it or something. I am wondering if anyone else has tried to get to 5.5. and how they have done that. |
I had and still have issues upgrading from 5.0 to 5.5. The first error occurred during the server container startup, telling me about some slack migration errors. I solved it by removing Now, the container starts as expected. However, I can't log in properly. Taiga tells me my username or password is wrong, which isn't the case since I use a password manager, and before the update, everything worked fine. So I checked the logs and found that: The above exception was the direct cause of the following exception:
.
.
.
django.db.utils.ProgrammingError: column users_user.verified_email does not exist
LINE 1: ...rs_user"."email_token", "users_user"."new_email", "users_use... It seems like a database migration error. I can roll back without any issue, but I'm still curious about what happens there. And, of course, in the long term, I want to upgrade. I thought of a not verified email since I had no Taiga email set up. So I went through the process and set everything up, but I got the same issue. Since I'm the only one using Taiga, I don't know which emails aren't verified. There are other users like Bitbucket, GitHub, etc. in the admin panel but I don't want to delete them since I don't know if I mess things up. That's my journey, so far, in upgrading from 5.0.15 to 5.5.5 (it seems it doesn't matter if I use an older 5.x version). |
|
Hmm... maybe this one #45 could be somehow related? |
|
The problem is that 5.1/5.2/5.3/5.4 versions were not provided |
That was my idea too. Since somewhere in between the databases changed their structure. A proper migration should fix this, at least in theory.
And that's my issue at this point. I'm not able to update in minor version steps.
I'm not sure about this. I delete all containers and volumes first, before using docker-compose to build my stack. So it touches only the database and the media folder located on my hard drive. But maybe I'm getting it somehow wrong. |
The issue is with migrations. They are absent (the upgrade causes |
What's interesting theris wiki do not say anything about breaking changes from 5.0 to 5.5. It can simply mean that migrations are not triggered during |
Its been a while since I worked with Django. I think I had some issues back then with migration as well. But I think they were related to drastic changes in my database due to development.
I don't know how the taiga folks version policy but a minor bump usually means an added feature (column) but no breaking changes. And from that point of view, it's no breaking change since a migration can probably fix any issue. So, it seems @Dzordzu might have a point here. However, if it's an automated process, having those minor version bumps shouldn't be too much work either, right? |
If the migrations are the issue - and there are no middle versions, then we need logs from migrating between 5.0 to 5.5 |
I checked the Dockerfile: RUN cp /opt/taiga-conf/taiga/local.py /usr/src/taiga-back/settings/local.py \
&& cp /opt/taiga-conf/taiga/docker.py /usr/src/taiga-back/settings/docker.py \
&& cp /opt/taiga-conf/taiga/celery.py /usr/src/taiga-back/settings/celery.py \
&& j2 /opt/taiga-conf/locale.gen.j2 > /etc/locale.gen \
\
# NOTICE: In case that "collectstatic" would not be found, it means in Django that the Taiga was not loaded
# and only basic Django application is configured because of an error, so Taiga commands are not loaded in that case
\
&& cd /usr/src/taiga-back/ && python manage.py collectstatic --noinput \
&& mkdir -p /var/log/nginx /var/lib/nginx \
&& touch /var/run/nginx.pid If I remember correctly you need to apply a migration before See here. I changed from those guys to your repo since I like your all in one solution more. Maybe that helps. |
Why the database migrations would be depending on static fles? Do you have
any clue? That would mean to execute collectstatic on each container
restart, right after migrations. Anyway I could try to check it.
…On Wed, Oct 7, 2020 at 7:47 PM Sandro Wrzalek ***@***.***> wrote:
I checked the Dockerfile:
RUN cp /opt/taiga-conf/taiga/local.py /usr/src/taiga-back/settings/local.py \
&& cp /opt/taiga-conf/taiga/docker.py /usr/src/taiga-back/settings/docker.py \
&& cp /opt/taiga-conf/taiga/celery.py /usr/src/taiga-back/settings/celery.py \
&& j2 /opt/taiga-conf/locale.gen.j2 > /etc/locale.gen \
\
# NOTICE: In case that "collectstatic" would not be found, it means in Django that the Taiga was not loaded
# and only basic Django application is configured because of an error, so Taiga commands are not loaded in that case
\
&& cd /usr/src/taiga-back/ && python manage.py collectstatic --noinput \
&& mkdir -p /var/log/nginx /var/lib/nginx \
&& touch /var/run/nginx.pid
If I remember correctly you need to apply a migration before python
manage.py collectstatic --noinput.
See here
<https://github.com/devinsolutions/docker-taiga/blob/master/docker-compose.advanced.yml>.
I changed from those guys to your repo since I like your all in one
solution more. Maybe that helps.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#46 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFOAJBVFGTUKCMSSJF3I4XTSJSSS5ANCNFSM4Q7DQ4WQ>
.
|
I add my logs, maybe that helps as well:
|
Do you mean in their setup? However, that could lead to other issues since those guys populate the database on the first run manually. So you might get errors when trying to migrate a non-existent database. |
I think I found the issue, I'm now testing it, probably I will release a fix as soon as I confirm that this is the case. |
…ompatible with recent versions of Taiga
I found an issue, it was serious. The migrations were not always executing - so application installation was successful, but upgrade not. Again I think there should be some tests coverage for that, I created an issue already to add some tests executed by CI. I just tagged a RC version for you for testing: https://github.com/riotkit-org/docker-taiga/releases/tag/1.4.1-RC1 CI will produce images with a few minutes: https://quay.io/repository/riotkit/taiga?tab=tags |
When you will say that the image resolves your issue I will tag a new stable version without RC and we can close the issue. |
The upgrade worked for me. I'm on 5.5.5. now and the logs showed that the migrations applied. =) Thanks for your quick response! |
Wow. It was the quickest fix I've ever seen. And what's astonishing - it works. Thanks! EDIT: It's not sarcastic. You've done amazing job. Within very few hours after spotting the issue, you've fixed it and deploy. And it's your volountary work, not some kind of the job |
@Dzordzu Thanks, I do so on daily basis for non-profit org. and open source 😉 My wage labour will start in 2 hours, but before it starts I have a moment for voluntary 😛 Regarding the issue - I see there are 2 people who tested, I'm tagging a stable version and closing the issue, thanks. |
Awesome thanks for the amazing help guys - you both exceed my talents for sure! Can't wait to try it! |
Placeholder for how to do this - presently, simply pulling the new version fails. Anyone else done this and know how?
The text was updated successfully, but these errors were encountered: