upgrade from AWX 1.0.5.24 fail
the page still show "awx is upgrading"
tried with
docker-compose pull && docker-compose up --force-recreate
it should breaks and couple of users reported issues already regarding this upgrade. They recommend to export & import data between awx from older version to a newly fresh installed version
Ref :
This is now at https://github.com/ansible/awx/blob/devel/DATA_MIGRATION.md.
I’ve tried doing this from 1.0.4.0 it was failing with -receive -all . With 1.0.5.20 -receive was successfully exported but import/send failed , and only imported the Organizations . None of the projects/templates/ inventories/etc were SENT.
Send / receive only works for certain version ?
Thx
Can you send some details as to what it was failing on when you ran —receive —all on 1.0.4.0?
Also send some details as to what was failing on the send with 1.0.5.20.
-John
Hi John - the issue was fixed after removing - one of the workflows (which was causing some issues). It was missing a value when I retrieved it from cli ( I didn’t get to take a copy of it) . Will do more testing on the workflows with send /receive .
However , a couple issues I need some clarity.
1) It seems upgrading from 1.0.4.0 to - 1.0.6.11. SCM update was ran to pull down playbooks / templates . This was apparently failing for all Git clone since the encrypted password was not exported . However , one of the SCM update was successfully ran , and created the playbook . I would have expected all templates to be imported without going through Projects/SCM/git - since it’s already stored in dB . Yes , credentials will need to be re-created after performing tower-cli send .
However , this behavior was not seen on 1.0.1.167 -> 1.0.6.11. All templates / playbooks were successfully imported (receive) . Question - is SCM update a pre-requisite for pulling down playbooks with tower-cli (send) , and if so - how was the encrypted password being imported - this should fail?
2) we sourced some 18000 hosts from script which dumps flat file in git . Importing this number of hosts, took forever. We had to remove the inventory prior to running tower-cli receive all .
3) all the imported users from ldap are treated as Local accounts - missing ldap label . Ldap configuration was applied post tower-cli send . Was able to login via ldap after deleting my local user . Confirming if ldap setting must be configured first before issuing tower-cli send ? I will do another tower-cli send to see if it fixes the problem - this time with ldap applied .
Thanks