-
Notifications
You must be signed in to change notification settings - Fork 21
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we're going to start doing orgs, a single org should be created for each demo category. (eg. Windows, Linux, Cloud, etc.) with teams in that org as necessary. I've added some other comments on specific lines but overall I think we need more discussion before merging.
- roles | ||
|
||
controller_organizations: | ||
- name: "Helpdesk Org" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need a new org? Wouldn't helpdesk just be a different team perhaps in the "windows" org?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was going by the idea that typically helpdesk is a tier 1 support that lives in its own org. They do level 1 triage for all types of issues and typically route the incident to the appropriate SME team (Windows/Network/DB etc).
I'm good with this being a team, long as we can apply the execute only permissions for the job template and ensure that they don't have visibility to the inventory.
controller_user_accounts: | ||
- user: level1 | ||
is_superuser: false | ||
password: Ansible!23 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd like to see if we can make this dynamic. Perhaps using the password from the controller credential to keep things consistent.
@@ -80,6 +93,34 @@ controller_templates: | |||
- 'Yes' | |||
- 'No' | |||
|
|||
- name: "WINDOWS / Patching Report" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is duplicating an existing job template. Is there a reason not to use the existing template?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here, the point is that all the vars are hardcoded and is run in check mode(no survey). The demo readme shows the scenario. For instance if a manager or a Level1 helpdesk person needs to look at the patching report, the only access they have is to execute this job template within their account on AAP. The idea is to showcase how automation can help elevate lower tiers of support or create self-help automation reports for managers without needing an admin in the path.
@nleiva and I experienced some issues with multiple orgs since this project operates from a single inventory and credential. I am going to close for now and we can revisit RBAC at another time. |
This PR adds a new organization and a user with execute only access to run a patch report. There is a small README to help demo this feature.
I'm not sure if the patching report logic only displays the components that require patching (it appears that way to me). It might make sense to update the patching report to include component being requested for with a "Compliant" status if they don't require patching. FYI, the template I'm using for running the patching report is as follows ::