awx
awx copied to clipboard
ansible
Feature request: additional Tower survey types
ISSUE TYPE
- Feature Idea
COMPONENT NAME
- UI
SUMMARY
Feature request to add a listtype option in tower survey to correctly parse a list that you pass for a variable. As it stands now you have to pass a list in yml format and for user experience it would be nice if you could pass a list just comma separated or how you do it when you specify a --limit
ENVIRONMENT
- AWX version: 3.2
- AWX install method: Linxus
- Ansible version: lastest
- Operating System: RHEL 7
- Web Browser: Chrome
STEPS TO REPRODUCE
No steps needed as it's a feature request.
EXPECTED RESULTS
ACTUAL RESULTS
ADDITIONAL INFORMATION
Just to be clear - you want the survey to explicitly want to pass in a extra_var of type "list"?
That is correct. Currently you have to pass a list like so ['foo','bar']. Instead of like foo, bar or foo bar
Current as it stands you have a text field, but if you want to pass a list it has to be yml format. It would would be nice if the survey had an option like typelist instead of text that would construct your item as a list instead one single var. Hope that makes sense.
Hi, In the same way it could be useful to have a boolean type. Actually booleans are passed at string type and we need to cast variable in ansible job.
Also note 'volatile password option', https://github.com/ansible/awx/issues/1274
Additional type - 'File':
Semantics: have a 'file' survey type this uses a file upload widget in the survey taker the uploaded file is stored as a base64-encoded extra var in the specified variable
This needs to set appropriate limits to not DoS the system.
The implications of not having a boolean type are quite significant - we can't use any existing bool variables in Surveys that otherwise work completely fine via other common Ansible var handling methods. E.g., if I build an AWX Workflow from playbooks that use some variables and a boolean one among them - I can place all those variables into the Workflow's Survey - except for the boolean one. So, I need to build an intermediate step in the beginning of the Workflow just to initiate and inject the boolean value into the process. With the way Ansible handles variables vs. facts and the variables priority - if I accidentally do put the boolean var into the Survey as-is, I'm setting myself up for a huge trouble as this String value silently "overrides" any handling of the normal boolean flow, which I won't catch unless I explicitly test both true and false scenarios. Lots of lost time and frustration.
Is there any progress on this? I am also in need of a boolean survey type. Having to cast a string to a boolean is error prone. A checkbox would also be a better UI than a "true"/"false" dropdown.
Uploading files(FileType in Survey) is one of must haves for AWX, since other automation engines(i.e. Jenkins) allow to do this.
Have the same request. I would need to upload file to the survey, I'm now doing a 2 step flow (first upload a file via SFTP manually, and then request in the survey the url from that file). Would be great to have all integrated in the same survey. If not we would need to create a parallel website to upload files and execute the playbook via api.
On top of boolean which is highly desirable, it would be a nice to have a Regular Expression type so we can validate specific patterns directly from the user inputs (eg: IP Address).
from https://github.com/ansible/awx/issues/3149:
Additional type: datetime Chooser: a calendar + time picker Result: iso8601 extended datetime, in UTC.
ISSUE TYPE
- Feature Idea
COMPONENT NAME
- UI
SUMMARY
Feature request to add a listtype option in tower survey to correctly parse a list that you pass for a variable. As it stands now you have to pass a list in yml format and for user experience it would be nice if you could pass a list just comma separated or how you do it when you specify a --limit
ENVIRONMENT
- AWX version: 3.2
- AWX install method: Linxus
- Ansible version: lastest
- Operating System: RHEL 7
- Web Browser: Chrome
STEPS TO REPRODUCE
No steps needed as it's a feature request.
EXPECTED RESULTS
ACTUAL RESULTS
ADDITIONAL INFORMATION
You can do something like this in your role/playbook to convert a comma or space delimited string into a simple (flat) list:
in the survey: foo,bar,baz
playbook/role: with_items: "{{ variable.split(',') }}"
However, I do not know if this would work with a list of lists, IE: item.pass=foo, item.username=bar, item.thing=baz. that's where I am at the moment and I'm trying to figure out a way to pass a list with multiple items through a survey into a role and execute a loop via with_items
Hello, We would like to see a boolean type for Tower surveys as well ! Thanks,
Boolean type is a requirement for our deployment use case. In the meantime we are using a multiple choice selection and comparing strings in our playbooks... not ideal.
Hi, another use case for the volatile password option would be for teams with multiple system administrators. With the current implementation it is possible for administrator A to relaunch the job of administrator B, whose credentials were passed as survey variables. This would break the audit trail which is an important factor in high security environments
so is anybody going to add boolean here or is awx just a throw-it-out-there open source gimmick so people can purchase tower and actually get the support they want ?
@mayuresh82,
is awx just a throw-it-out-there open source gimmick so people can purchase tower and actually get the support they want ?
I (and a score of other people, many of whom don't work at Red Hat) spend a considerable amount of our time building and maintaining the AWX open source project, which is a quality project that is totally free for use, expansive in its feature set, and constantly improving. Much of the work we do, and the roadmap we set for development is dependent on feedback we get from our open source community. We also (many of us outside of work hours) provide help and support to the community at large through our mailing list and IRC channel. Here's the 1300+ commits we've landed just since mid January:
~ git log --pretty=oneline 9.1.1..HEAD | wc -l
1316
Here's the last year:
~ git log --pretty=oneline 4.0.0..HEAD | wc -l
4892
Here's the changelog of (again, free) features and improvements we've delivered: https://github.com/ansible/awx/blob/devel/CHANGELOG.md
We haven't gotten to this feature yet. We probably will at some point. If this bothers you, the pull request button's right here: https://github.com/ansible/awx/compare
Hey! Would like this feature as well. Currently working for a very large organization that uses AWX heavily.
as AWX/Tower doesn't support boolean in surveys yet, do I need to convert my variable to a string and evaluate for a matching string, right?
Thanks @wenottingham. Anyway, if I filter the extra-variable passed by the awx survery with the bool filter, my playbook should be able to evaluate it correctly, isn't it? :thinking:
for people who want to have bool var support on AWX job template UI, a workaround is to put the var in EXTRA VARIABLES and tick the PROMPT ON LAUNCH checkbox.
BUT, the bool var accepts True/true/False/false as values, yes/no will still be treated as strings. This is different behavior from Ansible
Currently trying to find a way to limit extra vars with a survey but allow JSON lists and objects. i.e. passing "var":["item1", "item2"] or "var": {"key": "value"}. Currently allowed by the API, but not in a survey since the survey text fields want a string these values need the quotes escaped. BTW prompt on launch on extra_vars doesn't limit what variables can be passed like survey.
How about a "raw" type? One that doesn't do any validation. That might solve all of these issues allowing us to validate any unsupported types in our playbooks but still allow us to limit what extra_vars can be passed.
Is there still any attention on this? It's been 3 years, is it really that hard to implement a boolean type in a survey?
When it rises to the top of the priority queue and work begins, it will be linked off of here. Otherwise it will wait until someone decides to contribute it.
