Isolated and Control groups are managed strictly from the standalone
setup playbook installer and should not be directly managable from the
api. Especially true since you can't assign or create isolated groups
from within the API itself.
In the future this may change but allowing this in the API could leave
the system in a bad state.
* Before, we had a special group, tower, that ran any async work that
tower needed done. This allowed users fine grain control over which
nodes did background work. However, this granularity was too complicated
for users. So now, all tower system work goes to a special non-user
exposed celery queue. Tower remains the fallback instance group to
execute jobs on. The tower group will be created upon install and
protected from deletion.
* related to https://github.com/ansible/ansible-tower/issues/7931
* The Tower Instance group is special. It should always exist, so
prevent any delete to it.
* Only allow super users to associate/disassociate instances the 'tower'
instance group.
* Do not allow fields of tower instance group to be changed.
* tower/release_3.2.3:
fix unicode bugs with log statements
use --export option for ansible-inventory
add support for new "BECOME" prompt in Ansible 2.5+ for adhoc commands
enforce strings for secret password inputs on Credentials
fix a bug for "users should be able to change type of unused credential"
fix xss vulnerabilities - on host recent jobs popover - on schedule name tooltip
fix a bug when testing UDP-based logging configuration
bump templates form credential_types page limit
Wait for Slack RTM API websocket connection to be established
don't process artifacts from custom `set_stat` calls asynchronously
don't overwrite env['ANSIBLE_LIBRARY'] when fact caching is enabled
only allow facts to cache in the proper file system location
replace our memcached-based fact cache implementation with local files
add support for new "BECOME" prompt in Ansible 2.5+
fix a bug in inventory generation for isolated nodes
properly handle unicode for isolated job buffers
Definition of removal is providing a `credentials` list on launch
that lacks a type of credential that the job template has.
This assures that every category of credential the job template
has will also exist on jobs ran from that job template.
This restriction already existed, but this makes the endpoint
fail instead of re-adding the credentials.
This change makes manual launch congruent with saved launch
configurations.
