Hi all, finally had time to perform some tests, here my conclusions:
@suman your help needed
Tests:
This mean 99% you didn’t have a Rockstor update since July (Pincard was added on june-july) and this Django migration from 1.6.* to 1.8.* raised your error (Django migration assumes all previous migrations already applied)
My suggestion: have a new Rockstor install and import your disks/configurations
M.
I did this @Flyer I got a fresh install for 3.8.15 and updated to -14 and got the error for couple of days, however since I mentioned my last reboot I didn’t get the error message again. I am not sure it just fixed itself or it will pop up again. I will let you guys know.
Hi @Mahmoud87,
if you get users page and can create a Pincard you won’t get that error anymore (having users page rendering means it’s all ok, having a Pincard creation too confirms it again because if it doesn’t fail => Pincard table exists)
M.
Reinstalling from a 3.8.15 .iso and updating from there resolved the issue for me. Before I had been installing from a 3.8.14 .iso previously. So pretty much exactly what @Flyer said.
Hi guys,
finally can confirm (@suman tell me if I’m wrong) my idea about not updated systems & new 3.8.15 Rockstor:
Rockstor has a group on initial SQL scripts creating DB tables on new installations ( https://github.com/rockstor/rockstor-core/blob/master/conf/storageadmin.sql.in & https://github.com/rockstor/rockstor-core/blob/master/conf/smartdb.sql.in ), both got updated while moving to Django > 1.8 and Rockstor initrock (running on every Rockstor restart) got its update on
https://github.com/rockstor/rockstor-core/blob/master/src/rockstor/scripts/initrock.py#L395-L399
with 2 fake migration (fake migration on Django = trace it, but don’t perform it)
So old Rockstors on 3.8.14 not already having Pincard table (and other tables too) currently moving to last Rockstor 3.8.15.x are without required tables.
We should patch with a conditional migration instead of a fake migration, but not updating Rockstor for a long time is not good 
(like not updating every system)
M.
Hi @rockmar. It’s understandable why you wanted to start with 3.8-12, but could you install from 3.8.15 iso so that you get all necessary db schema changes the old way and then update to the latest? Any system being updated to 3.8.15-X should be updated from 3.8.15. When making django 1.8 migration I did think of the possibility of some users being on older versions. To provide a smooth upgrade path from <3.8.15 to latest would involve putting a lot of convoluted logic and then deprecating it later may introduce more problems as well. Or we could put out a stable update with the only change that enforces users to first update to 3.8.15 before updating further. But this won’t help users on testing channel, so we would need to put similar check for that code path too. This method also proved to be convoluted. So I decided to keep the code clean at the risk of breaking long updated paths.
I do want to offer an easy solution for those who are updating from <3.8.15 to latest, whether it’s stable channel or testing channel. For stable channel users, the solution is very simple, just update!
For testing channel users, update to 3.8.15-1 first with this one command yum update rockstor-3.8.15-1. Since there’s an updated kernel, you must reboot after the update. Then you can update to the latest from the UI. If you run into errors using this method, please report them.
I say we don’t bother with this @Flyer. I have experimented with possible solutions to do such thing and it’s not smooth at all. Testing channel users that are updating from an old(<3.8.15) version should just do the following
yum update rockstor-3.8.15-1
I @suman, agree with you about that “it’s not smooth at all”, had some tests trying to have a conditional migration, found it’s possible with some hacks using migrations.RunPython(checkingfunc) where our checkingfunc actually runs something like this:
from django.db import connection
cursor = connection.cursor()
cursor.execute("select * from information_schema.tables where table_schema = 'public' and table_name ILIKE '%TABLE_TO_CHECK_EXISTS%'")
table_exists = True if len(cursor.fetchall()) > 0 else False
But this would require a rewrite for every migration.
Can we instead have an hack to force updates to be sequential? 3.8.15-1 will never update directly to 3.8.15-22, but will perform 3.8.15-2, 3.8-15-3, etc
This should grant users having all required steps on updates
M.
This is a good idea and I’ve been thinking about implementing a generic enhancement to the update logic that’ll come in handy in the future. It would work as follows. Say we release an update x and we want to ensure that the system’s current version be at least p. Then update x fails if the system’s version is < p, with an appropriate error message. Our software update logic reads the error message and triggers another update to p. After a successful update to p, another update is triggered to bring the system to the latest version x.
What do you all think about this idea?
Wouldn’t it be better for update just traverse through every versions on it’s way ?
Let’s say you’ve got a .14-3 and are going for newest version, system then will lookup for how to upgrade to .14-4 then update to .14-5 and so on …
That way difs between versions are kept to the minimum … and if upgrade craps out we will know exatly how to solve it because there will be a lot of people with same problem … solutions will be simple.