I’m wondering if the AWX team has a suggestion on when/how often to grab the latest release? I had to rebuild after the 1.0.2 backwards-incompatible release, so it’s made me more cautious about just grabbing the latest release regularly. I’m currently on 1.0.2.327 and it’s working well. Thoughts?
I’m also interested in this. I understand that AWX is offered ‘as-is’ and that for anything mission-critical you should pony up to RedHat for a Tower license, but (often?) requiring starting over with an empty database for new releases also makes using the tool at all a bit difficult for anything beyond some very casual poking around.
Seeing as Tower has to of course handle database upgrades between releases, it feels like a deliberate crippling of the open source product to drive people toward the commercial solution. I would have hoped that having RedHat support for the commercial solution would have been incentive enough.
-R
This is really just an unfortunate circumstance that results from our development workflow and how we use the devel branch. Even for us internally, there is never a guarantee that any commit of devel will upgrade to any other commit of devel. We frequently have to wipe and recreate our databases during the development cycle. You will never be able to run off the HEAD of devel and have reliable upgrades.
That said, the the “best” way to have reliable upgrades when using awx would be to look for merge commits that are from tower/release branches, like this one https://github.com/ansible/awx/commit/9dbcc5934ee1a5774cec58b8f4ce08bea777dd7e and only update awx to those commits.
Another reminder: the primary purpose of Tower is stability, and the
primary purpose of AWX is to move fast, even at the risk of
occasionally breaking things.
Tower upgrades are different because we have much stronger assurances
about customer environments, and because we're on the hook to fix
those issues if they go wrong. We *cannot possibly* provide such
assurances for AWX -- and providing an upgrade path without such
assurances would be irresponsible. We refuse to make promises about
upgradability that we won't be able to keep.
One possible workaround for AWX users is to export data from the old
AWX instance using the Tower API/CLI, and then import that data to the
new AWX instance.
Thanks - that’s a neat idea. I’ll give that a shot.
Hi Greg,
could you please provide link about tower-cli export/import? I looked in tower-cli documentation and could not find anything.
Cheers,
I would be interested to find about exporting data out using tower api prior to upgrading to later tag . Thx
The tower-cli importer/exporter feature (goes through the API) is up as a pull request. Here is a message I sent about it
I was able to import credentials, but beyond that, no luck. Trying to import items that refer to credentials fails because the API wants the Primary Key of the credential, not the name.
For example, I get this error when trying to import a Project:
Failed to create project ansible-playbooks MASTER : The Tower server claims it was sent a bad request.
POST http://10.x.x.x/api/v2/projects/
Params: None
Response: {“credential”:[“Incorrect type. Expected pk value, received unicode.”]}
The API wants the PK of the credential, not the text name. So the import feature would need some way to look up by name, retrieve the PK, and insert that PK value into the json prior to making the API POST.
Just wanted to post in here that there’s been a lot of progress on the Tower CLI client PR that Alan Rominger mentioned earlier in the thread.
https://github.com/ansible/tower-cli/pull/479
I’ve done a couple of test migrations, and with the exception of permissions and system settings, it’s been successful. Pretty cool stuff if you’re looking for an upgrade path.