Awx: Feature idea: programmatic job/workflow templates & surveys in SCM
ISSUE TYPE
- Feature Idea
COMPONENT NAME
- API
- UI
SUMMARY
We already pull playbooks from source control - it would be neat if the job template & workflow definitions (including surveys, potentially even roles) could be sourced from there as well.
(Probably a very large discussion of how this would work, and what to support, is required.)
ENVIRONMENT
- AWX version: any
ADDITIONAL INFORMATION
wenottingham
All 25 comments
Very good point!
In comparing AWX with Jenkins+Ansible+Pipeline(plugins), it is IMHO a very strong point for the Jenkins solution to be able to source-control the pipeline code (including any ansible steps).
And us having >50 playbooks (most based on a role), having a way to manage+auto-generate Job/Templates for >80% of those playbooks, could be highly useful
lhoss
on 8 Nov 2017
Very good point!
hemskgren
on 13 Dec 2017
I would be very interested in this feature.
perzizzle
on 6 Feb 2018
Hi Guys, any timelines when this feature is coming out ?
ghost
on 13 Jun 2018
I'm also interested to test this new feature !
powertim
on 19 Oct 2018
+1
ghost
on 31 Dec 2018
+1 I think this is a really good idea, I was searching for something similar. In general I find we end up with too much manual configuration of jobs in AWX, having it sourced from Git would provide much needed version control (rollback capabilities) and simplify the process of moving between awx instances.
@wenottingham have you given much more thought to this feature? Is the implementation significant?
If implementation is significant, wonder if a easier starting point might be the ability to have the tower-cli synchronize a git repo to a org for example. Kinda infrastructure as code approach.
abedwardsw
on 7 Jan 2019
What do you mean by significant? I suspect there's a decent amount of design that needs to go into it to make sure it's sufficiently future proof, and doesn't clash horribly with tower-cli and other things.
wenottingham
on 7 Jan 2019
by significant I was wondering if this is a large change requiring weeks of effort. it sounds like it is. ;-) . Would be a great feature if/when someone has time to implement.
abedwardsw
on 7 Jan 2019
Having a role/playbook to interact with AWX using the https://docs.ansible.com/ansible/latest/modules/tower_job_template_module.html is a workaround, but then I'd probably need to lock down user interaction on the server (and/or an easier way to export the current templates into such tasks).
This approach (maintaining AWX config separately from AWX to be able to configure a server from scratch) is necessary anyways, since AWX does not really support upgrades from one version to the next (it can do it, it might fail, you're on your own).
MarkusTeufelberger
on 29 Apr 2019
Hi, are there any plans to pursue this?
amarza-rh
on 4 Mar 2020
If work happens on this, it will appear here. Not planned for the very near term.
wenottingham
on 4 Mar 2020
I have been bumping into this feature's necessity more often, as I'm trying to do more CI work around testing my Tower content. I'd really like to be able to test job templates in one environment, then promote them to another, ideally via source control.
I've followed that pattern using Jenkins pipelines with Jenkinsfiles, and it would be really awesome if I could do something similar, but with simpler tower.yml YAML syntax (maybe something similar in style to travis CI's .travis.yml style or GitHub Actions' workflow file style).
Obviously the content would need to be tailored towards job templates specifically, but it is very cumbersome to have to match job templates in new or different environments manually.
This could potentially make upgrades and/or backups simpler, in terms of being able to dump job templates to disk, and restore them from disk (ideally, anything configurable in Tower's UI would be able to be dumped to a config file, but that's way beyond the scope of job template files!).
geerlingguy
on 6 May 2020
@wenottingham @geerlingguy I have been using https://github.com/kedark3/ATCasC - Ansible Tower Configuration as code within my Team (Satellite) to keep version controlled Job/Workflows, and using GitLab CI pipeline to promote them to test Tower->prod Tower. Ping me if you're interested to learn more about our process.
kedark3
on 6 May 2020
Automations, through a tool like Tower/AWX, is primarily comprised of the Playbooks, Templates and Metadata/Variables. All the Playbooks and such are in source control. Well done there. The Templates are in the Tower/AWX instance and in the database... Boooo! Having the ability to export those templates into a raw/usable format is the first step to having the ability to import a template into another instance.
For example: I have a production setup of tower across (6) servers and I have a stage setup of tower across (3) other servers. Sometimes we wanna run tests on some of the current automations in the STG instance when performing upgrades. Right now there is no quick/programatic way to accomplish. < - - BOOO! Boo * 1000 because we are talking about an automation product.
macnlos
on 14 Jul 2020
@macnlos Where did awxcli export and awxcli import fail to meet your need?
Example export
awx --conf.host http://localhost:8013 --conf.username admin --conf.password admin export --job_templates 8
{
"job_templates": [
{
"name": "Demo Job Template2",
"description": "",
"job_type": "run",
"playbook": "hello_world.yml",
"scm_branch": "",
"forks": 0,
"limit": "",
"verbosity": 0,
"extra_vars": "---",
"job_tags": "",
"force_handlers": false,
"skip_tags": "",
"start_at_task": "",
"timeout": 0,
"use_fact_cache": false,
"host_config_key": "",
"ask_scm_branch_on_launch": false,
"ask_diff_mode_on_launch": false,
"ask_variables_on_launch": false,
"ask_limit_on_launch": false,
"ask_tags_on_launch": false,
"ask_skip_tags_on_launch": false,
"ask_job_type_on_launch": false,
"ask_verbosity_on_launch": false,
"ask_inventory_on_launch": false,
"ask_credential_on_launch": false,
"survey_enabled": true,
"become_enabled": false,
"diff_mode": false,
"allow_simultaneous": false,
"custom_virtualenv": null,
"job_slice_count": 1,
"webhook_service": "",
"webhook_credential": null,
"inventory": {
"organization": {
"name": "Default",
"type": "organization"
},
"name": "Demo Inventory",
"type": "inventory"
},
"project": {
"organization": {
"name": "Default",
"type": "organization"
},
"name": "Demo Project",
"type": "project"
},
"related": {
"labels": [],
"credentials": [
{
"organization": null,
"name": "Demo Credential",
"credential_type": {
"name": "Machine",
"kind": "ssh",
"type": "credential_type"
},
"type": "credential"
},
{
"organization": {
"name": "Default",
"type": "organization"
},
"name": "tesddfd",
"credential_type": {
"name": "Ansible Tower",
"kind": "cloud",
"type": "credential_type"
},
"type": "credential"
}
],
"schedules": [
{
"rrule": "DTSTART;TZID=America/New_York:20200717T141500 RRULE:INTERVAL=1;COUNT=1;FREQ=MINUTELY",
"name": "test<b>bold</b>\">",
"description": "test",
"extra_data": {},
"scm_branch": null,
"job_type": null,
"job_tags": null,
"skip_tags": null,
"limit": null,
"diff_mode": null,
"verbosity": null,
"enabled": false,
"inventory": {
"organization": {
"name": "Default",
"type": "organization"
},
"name": "Demo Inventory",
"type": "inventory"
},
"unified_job_template": {
"organization": {
"name": "Default",
"type": "organization"
},
"name": "Demo Job Template2",
"type": "job_template"
},
"related": {
"credentials": []
},
"natural_key": {
"unified_job_template": {
"organization": {
"name": "Default",
"type": "organization"
},
"name": "Demo Job Template2",
"type": "job_template"
},
"name": "test<b>bold</b>\">",
"type": "schedule"
}
}
],
"notification_templates_started": [],
"notification_templates_success": [],
"notification_templates_error": [],
"survey_spec": {
"name": "",
"description": "",
"spec": [
{
"question_name": "test\"><b>i am bold</b>",
"question_description": "",
"required": true,
"type": "text",
"variable": "no_spaces",
"min": 0,
"max": 1024,
"default": "test\"><b>i am bold</b>",
"choices": "",
"new_question": false
},
{
"question_name": "test",
"question_description": "",
"required": true,
"type": "text",
"variable": "dfdsafds<b>bold</b>\\\"><br>",
"min": 0,
"max": 1024,
"default": "",
"choices": "",
"new_question": true
},
{
"question_name": "test3",
"question_description": "",
"required": true,
"type": "text",
"variable": "../../../api/v2/job_templates/",
"min": 0,
"max": 1024,
"default": "",
"choices": "",
"new_question": true
}
]
}
},
"natural_key": {
"organization": {
"name": "Default",
"type": "organization"
},
"name": "Demo Job Template2",
"type": "job_template"
}
}
]
}
chrismeyersfsu
on 14 Jul 2020
@chrismeyersfsu The structure of this export is not formalized as an API, it is not versioned and as such no process for changing it (like deprecating, backwards compatibility etc). It is not a format expected to be consumed outside of Tower and not a public interface as far as I can tell.
Jobava
on 14 Jul 2020
@Jobava the tower_job_template module is closer to having the properties you describe. However, you can't bridge an export + tower_job_template you mostly need to hand-craft the yaml that is passed to the module.
chrismeyersfsu
on 14 Jul 2020
@macnlos recently we released a new collection which possibly can help you as well. https://galaxy.ansible.com/redhat_cop/tower_configuration
Note: Its a community project, its based on AWX Collections.
kedark3
on 14 Jul 2020
I've followed that pattern using Jenkins pipelines with
Jenkinsfiles, and it would be really awesome if I could do something similar, but with simplertower.ymlYAML syntax (maybe something similar in style to travis CI's.travis.ymlstyle or GitHub Actions' workflow file style).
Totally agree with the concept :
- I just had a few days ago, a close idea, in #7711 (closed since duplicate with this one and #526 )
- There the big change that I see is this :
- above, I can read people caring about "locking" a job definition
- so the solution, I believe, is to define a job at a repo level (is not that required, for a software to be a gitops tool, to be aware of git repos ?)
atlantis.yamlgives an example of that, see https://www.runatlantis.io/docs/repo-level-atlantis-yaml.html- using that pattern, I believe that Job Spec will not have to be "locked", the Job Spec is simply instantiated every time there is a new Job execution (The Job Spec doe not exist, before the job execution)
- the "central" AWX definition of each Job Spec then can be "the defautl job spec when none is defined at the repo level"
I think I know how it should be implemented :
* The Job Template, and also Ansible Tower Workflows, should be on a by-repo basis configurable, * using a `ansible-tower.yaml`, or `awx.yaml` versioned with the source code * just like like there are `drone.yml` `gitlab-ci.yml` `circle-ci.yml` `travis-ci.yml` `atlantis.yaml` etc....
Jean-Baptiste-Lasselle
on 23 Jul 2020
@wenottingham I saw your note in #526 about PR #7099. These capabilities are a first-class concern for my team as we operate multiple AWX instances in a multi-cloud context. What's the best way for us to contribute development efforts towards this feature set?
snooyen
on 11 Sep 2020
The biggest questions in that PR are about the how of how it operates:
- What are the RBAC concerns?
- What permissions are resources created with?
- How is authentication done?
- Who owns them?
- Do they blindly overwrite?
- Is this done via export and import modules? The CLI? A set of tasks?
etc.
wenottingham
on 11 Sep 2020
I'm still formulating my thoughts on RBAC concerns, ownership, and resource creation permissions, but here are some of my initial thoughts having taken the time to get more acquainted with the codebase.
- Is this done via export and import modules? The CLI? A set of tasks?
The implementation proposed in #7099 leverages the awx.awx.*_job_template modules. It seems like this strategy would be difficult to maintain if we're considering future updates to job and workflow_job configurations.
Using the import/export modules is a more flexible option in this regard, but leaves the question of "how is authentication done?" The POC implementation generates an OAuth token for the user that initiated the project update. This seems like a reasonable approach, but extra care needs to be taken to ensure the OAuth token is removed following the operation.
- Do they blindly overwrite?
My first thought is that sync'd assets should probably be namespaced to the project+organization they're associated with. eg <project_name>:<job_template_name>. When performing and asset sync between multiple projects, there could be job templates w/ the same name which would cause conflicts.
Both of these concerns lead me to another question:
- What do asset definitions look like?
If we go the route of using the export/import modules, the raw json output of the export module might be sufficient. However, from a user perspective, that might be cumbersome to define. Seems like most users would prefer a simplified yaml format.
snooyen
on 12 Sep 2020
If you're interested, we do have an open-sourced project for managing Tower configuration as code:
https://github.com/europ/atacac
It works from the raw json output as @snooyen mentioned (but we use yaml instead).
The verbosity of the configuration is easier to manage because the project also describes how to extract an existing Tower configuration into code. So the workflow can be to use the UI to create your Tower assets, then extract it to put it into code, then use the code to further 'sync' the Tower config starting from changes in the local config.
The main problem is still that we can't rely on the raw output as an API because we have no versioning and no guarantees the format won't change. However, we protect ourselves against format changes by further verifying the schema of the configuration before inserting back into Tower.
Jobava
on 14 Sep 2020
@Jobava Yes, it seems like a big challenge for this issue, is that there's no API that allows users to programmatically list all the fields that constitute a job template..
snooyen
on 14 Sep 2020
Related issues
pebbledavec
路
3Comments
mwiora
路
3Comments
gamuniz
路
3Comments
marshmalien
路
3Comments
cs35-owncloud
路
3Comments
Most helpful comment
@wenottingham @geerlingguy I have been using https://github.com/kedark3/ATCasC - Ansible Tower Configuration as code within my Team (Satellite) to keep version controlled Job/Workflows, and using GitLab CI pipeline to promote them to test Tower->prod Tower. Ping me if you're interested to learn more about our process.