mirror of
https://github.com/ansible/awx.git
synced 2026-01-09 23:12:08 -03:30
Cleanup TODO file
This commit is contained in:
parent
bc19dc90ac
commit
48a29df4ec
72
TODO.md
72
TODO.md
@ -1,59 +1,33 @@
|
||||
TODO items for ansible commander
|
||||
================================
|
||||
|
||||
4/2 NOTES
|
||||
=========
|
||||
CC TODO
|
||||
=======
|
||||
* supervisord to start celery, modify ansible playbook to set up supervisord <- ChrisC
|
||||
* make job rest triggerable & job status readable. now happens just by creating a new job <-- MPD
|
||||
* do we need something other than default playbook (ProjectOptions) <-- me, later
|
||||
* way to send cntrl-c to kill job (method on job?) <-- ChrisC, low priority
|
||||
* documentation on how to run with callbacks from NOT a launchjob <-- ChrisC
|
||||
* interactive SSH agent support for launch jobs/creds <-- ChrisC
|
||||
* michael to modify ansible to accept ssh password and sudo password from env vars
|
||||
* way to send cntrl-c to kill job (method on job?) <-- ChrisC, low priority
|
||||
* default_playbook should be relative to scm_repository and not allow "../" out of the directory
|
||||
|
||||
CH notes
|
||||
========
|
||||
need to add api/v1/group/N/all_hosts
|
||||
need to add api/v1/host/N/all_groups or make sure it's in the resource
|
||||
figure out how to mark each object generically w/ whether it can be edited/etc
|
||||
enable generic filtering
|
||||
sorting?
|
||||
if you delete a subgroup, hosts go up to parent
|
||||
verify unique_together on inventory and host name
|
||||
* do we need something other than default playbook (ProjectOptions) <-- MPD later
|
||||
* make a way to start a job via the API (create a new job) <-- MPD
|
||||
* make job rest triggerable & job status readable. now happens just by creating a new job <-- MPD
|
||||
* figure out how to mark each object generically w/ whether it can be edited/etc
|
||||
* if you delete a subgroup, hosts go up to parent
|
||||
* verify unique_together on inventory and host name
|
||||
|
||||
make a way to start a job via the API (create a new job)
|
||||
* finish REST around permissions <-- MPD
|
||||
|
||||
future feature of being able to create job templates -- supported in db by JobTemplate
|
||||
|
||||
REST TODO
|
||||
---------
|
||||
* credentials objects & permissions
|
||||
* tags (later)
|
||||
* audit trails (later)
|
||||
* jobs triggering <-- important
|
||||
* related resources on everything that makes sense <--- important
|
||||
* expose log data from callback (decide on structure)
|
||||
|
||||
|
||||
api/v1/ <-- discoverable
|
||||
api/v1/me
|
||||
|
||||
{
|
||||
id: 2
|
||||
foo: 3
|
||||
related: [
|
||||
'bar' : 'http://api/v1/users/5/bar',
|
||||
'baz' : 'http://api/v1/users/10/baz',
|
||||
}
|
||||
}
|
||||
* related resources on everything that makes sense <--- MPD, important
|
||||
* make /api and /api/v1 have useful content in it
|
||||
|
||||
LATER
|
||||
-----
|
||||
|
||||
* UI layer, CLI client (and libs)
|
||||
=====
|
||||
* clean up initial migrations
|
||||
* init scripts (supervisord), Apache proxying, etc
|
||||
* does inventory script need any caching (??)
|
||||
* support multiple project launch options (different flags, etc)
|
||||
|
||||
|
||||
@ -62,26 +36,20 @@ TWEAKS/ASSORTED
|
||||
|
||||
* security check - playbook must be fully pathed when executed by commander and relative to project
|
||||
directory. Project directories must be unique and be (also no ../, etc). default_playbook MUST be a relative path (no starting with . or / or containing ..).
|
||||
* when creating a project, write a '.acom' file, this file contains a JSON list of valid project GUIDs that are allowed to use it. This can be created automatically by the system if it does not already exist, but not overwritten by the system.
|
||||
* idea: when creating a project, write a '.acom' file, this file contains a JSON list of valid project GUIDs that are allowed to use it. This can be created automatically by the system if it does not already exist, but not overwritten by the system.
|
||||
* document multi-org content limitations with regard to access security and sensitive vars
|
||||
* when app starts it creates a default organization and all superusers are automatically added to it
|
||||
* API discovery resource at /api and /api/v1
|
||||
* audit/test read only fields like creation_date
|
||||
* ability to import inventory from script (adds variables and merges, does not override, does not remove anything)
|
||||
* ability to import inventory from inventory files (upgrade case)
|
||||
* ability to import inventory from script (adds variables and merges, does not override, does not remove anything) -- merge control, possibly via script
|
||||
* ability to import inventory from inventory files (upgrade case) -- write a inventory script that is ansible-inventory API compatible maybe?
|
||||
* when associating inventory objects, objects should share common inventory records (user_can_attach method should check)
|
||||
|
||||
QUESTIONS
|
||||
---------
|
||||
|
||||
* if creating a project, do we want to have an appliance style path for them, like
|
||||
/storage/projects/GUID ??? may want to keep somewhere else ?
|
||||
|
||||
MISC
|
||||
----
|
||||
|
||||
when associating inventory objects, objects should share common inventory records (user_can_attach method should check)
|
||||
* if creating a new project, do we want to have an appliance style path for them, like /storage/projects/GUID ??? may want to keep somewhere else ?
|
||||
|
||||
|
||||
|
||||
PAGINATION, FILTERING, SORTING -> CH
|
||||
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user