# Makemigrations from 1.0.5 to 1.0.6 **URL:** \ **Category:** AWX Project\ **Tags:** awx\ **Created:** [April 27, 2018, 8:30pm UTC](https://forum.ansible.com/t/makemigrations-from-1-0-5-to-1-0-6/27400 "2018-04-27T20:30:29Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![Martin\_Juhl](https://avatars.discourse-cdn.com/v4/letter/m/8c91f0/32.png) [@Martin\_Juhl](https://forum.ansible.com/u/Martin_Juhl)\ **Post date:** [April 27, 2018, 8:30pm UTC](https://forum.ansible.com/t/makemigrations-from-1-0-5-to-1-0-6/27400/1 "2018-04-27T20:30:29Z")
Hi guys When trying to upgrade from 1.0.5 to 1.0.6… I get the following error: [root@akiva migrations]# sudo -u awx /opt/awx/bin/awx-manage migrate Traceback (most recent call last): File “/opt/awx/bin/awx-manage”, line 11, in sys.exit(manage()) File “/opt/awx/embedded/lib/python2.7/site-packages/awx/ **init**.py”, line 109, in manage execute\_from\_command\_line(sys.argv) File “/opt/awx/embedded/lib64/python2.7/site-packages/django/core/management/ **init**.py”, line 364, in execute\_from\_command\_line utility.execute() File “/opt/awx/embedded/lib64/python2.7/site-packages/django/core/management/ **init**.py”, line 356, in execute self.fetch\_command(subcommand).run\_from\_argv(self.argv) File “/opt/awx/embedded/lib64/python2.7/site-packages/django/core/management/base.py”, line 283, in run\_from\_argv self.execute(\*args, \*\*cmd\_options) File “/opt/awx/embedded/lib64/python2.7/site-packages/django/core/management/base.py”, line 330, in execute output = self.handle(\*args, \*\*options) File “/opt/awx/embedded/lib64/python2.7/site-packages/django/core/management/commands/migrate.py”, line 86, in handle executor.loader.check\_consistent\_history(connection) File “/opt/awx/embedded/lib64/python2.7/site-packages/django/db/migrations/loader.py”, line 298, in check\_consistent\_history connection.alias, django.db.migrations.exceptions.InconsistentMigrationHistory: Migration network\_ui.0001\_initial is applied before its dependency main.0027\_v33 0\_emitted\_events on database ‘default’. This is using the RPMs that I created… so this might be a bug in packaging… but to me it seems like an upgrade issue??? Hope that someone can give me some input… Thanks /Martin ---
**Author:** ![Graham\_Mainwaring](https://avatars.discourse-cdn.com/v4/letter/g/db5fbb/32.png) [@Graham\_Mainwaring](https://forum.ansible.com/u/Graham_Mainwaring)\ **Post date:** [April 27, 2018, 9:13pm UTC](https://forum.ansible.com/t/makemigrations-from-1-0-5-to-1-0-6/27400/2 "2018-04-27T21:13:45Z")
Martin, Upgrades between AWX versions are not expected to work. However, we have recently added an import/export capability to tower-cli/awx-cli, which allows you to export your job templates and other objects (not including credential secrets) to a JSON file, which you can then re-import to a freshly installed 1.0.6. Thanks, -Graham ---
**Author:** ![Martin\_Juhl](https://avatars.discourse-cdn.com/v4/letter/m/8c91f0/32.png) [@Martin\_Juhl](https://forum.ansible.com/u/Martin_Juhl)\ **Post date:** [April 27, 2018, 9:22pm UTC](https://forum.ansible.com/t/makemigrations-from-1-0-5-to-1-0-6/27400/3 "2018-04-27T21:22:43Z")
Hi Graham Thanks for the info… nice to know… I will try to do a workaround (something like export-\>wipe-\>import)… Should an “awx-manage flush” be enough to wipe the database? /Martin ---
**Author:** ![Dong\_Yang](https://avatars.discourse-cdn.com/v4/letter/d/59ef9b/32.png) [@Dong\_Yang](https://forum.ansible.com/u/Dong_Yang)\ **Post date:** [April 29, 2018, 1:31am UTC](https://forum.ansible.com/t/makemigrations-from-1-0-5-to-1-0-6/27400/4 "2018-04-29T01:31:06Z")
Hi , Tower cli is really easy to use . Does this upgrade path work for 1.0.1\* to 1.0.6.\*? ---
**Author:** ![T.J\_Yang](https://avatars.discourse-cdn.com/v4/letter/t/a6a055/32.png) [@T.J\_Yang](https://forum.ansible.com/u/T.J_Yang)\ **Post date:** [April 29, 2018, 12:25pm UTC](https://forum.ansible.com/t/makemigrations-from-1-0-5-to-1-0-6/27400/5 "2018-04-29T12:25:32Z")
Hi dns92301, please follow this issue [https://github.com/MrMEEE/awx-build/issues/17](https://github.com/MrMEEE/awx-build/issues/17) ---
**Author:** ![Martin\_Juhl](https://avatars.discourse-cdn.com/v4/letter/m/8c91f0/32.png) [@Martin\_Juhl](https://forum.ansible.com/u/Martin_Juhl)\ **Post date:** [April 30, 2018, 9:38am UTC](https://forum.ansible.com/t/makemigrations-from-1-0-5-to-1-0-6/27400/6 "2018-04-30T09:38:18Z")
This (the awx-cli) is definitely not the best upgrade path right now… as far as I can see i’m loosing: Users (export is blank), and therefore user permissions Log/History Inventory Groups Credential passwords LDAP/Auth config Would be easier if the migration stuff would work… :)… It was working for all of the 1.0.5.\* releases… expect of 1.0.5.31-1.0.5.32… I don’t know ANYTHING about Django/DB stuff… But is it really that much more effort, to write it so that it’s at least migratable from the last minor??? (asking, not critisising) /Martin ---
**Author:** ![Markus\_Teufelberger](https://avatars.discourse-cdn.com/v4/letter/m/76d3ee/32.png) [@Markus\_Teufelberger](https://forum.ansible.com/u/Markus_Teufelberger)\ **Post date:** [May 2, 2018, 2:50pm UTC](https://forum.ansible.com/t/makemigrations-from-1-0-5-to-1-0-6/27400/7 "2018-05-02T14:50:05Z")
> Upgrades between AWX versions are not expected to work. However, we have recently added an import/export capability to tower-cli/awx-cli, which allows you to export your job templates and other objects (not including credential secrets) to a JSON file, which you can then re-import to a freshly installed 1.0.6. It would also be nice if the “Ansible\_Tower” modules at [http://docs.ansible.com/ansible/latest/modules/list\_of\_web\_infrastructure\_modules.html](http://docs.ansible.com/ansible/latest/modules/list_of_web_infrastructure_modules.html) could receive a bit of love and be extended to being able to fully configure an AWX instance/access all API objects. That way one could store the configuration for AWX in an Ansible role, throw away the old installation and configure the fresh, new one instead of dealing with some exported JSON files… Feels a bit weird to have a server for a configuration management software resort to some custom process for configuration.