RemoteExecution » History » Version 1
Kyle Baker, 12/03/2014 11:37 AM
| 1 | 1 | Kyle Baker | h1. Remote Execution |
|---|---|---|---|
| 2 | |||
| 3 | h2. Summary |
||
| 4 | |||
| 5 | This is a template to start with. To create new feature, make up a URL of your preference and set Parent page (bellow the form) to *Features*. Write a summary, owners, current status and keep the page up to date. |
||
| 6 | |||
| 7 | h2. Targeted Release |
||
| 8 | |||
| 9 | Foreman 1.9 / Katello 2.3 |
||
| 10 | |||
| 11 | h2. Trackers |
||
| 12 | |||
| 13 | -- |
||
| 14 | |||
| 15 | h2. Targeted Persona |
||
| 16 | |||
| 17 | System Engineer |
||
| 18 | |||
| 19 | h2. Status |
||
| 20 | |||
| 21 | h3. User Stories |
||
| 22 | |||
| 23 | Owner - David Caplan |
||
| 24 | Status - In Progress |
||
| 25 | Expected Delivery - TBD |
||
| 26 | Blockers - None |
||
| 27 | |||
| 28 | h3. Requirements |
||
| 29 | |||
| 30 | Owner - Mike Mccune / David Caplan |
||
| 31 | Status - Not Started |
||
| 32 | Expected Delivery - TBD |
||
| 33 | Blockers - Waiting on User Stories |
||
| 34 | |||
| 35 | h3. Wireframes |
||
| 36 | |||
| 37 | Owner - Kyle Baker |
||
| 38 | Status - Not Started |
||
| 39 | Blockers - Waiting on User Stories & Requirements |
||
| 40 | Last updated TBD - -- |
||
| 41 | |||
| 42 | h3. Development Stories |
||
| 43 | |||
| 44 | Owner - Foreman (TBD) Katello (TBD) |
||
| 45 | Status - Not Started |
||
| 46 | Expected Delivery - TBD |
||
| 47 | Blockers - Waiting on Wireframes |
||
| 48 | |||
| 49 | h2. Documentation |
||
| 50 | |||
| 51 | h3. User Stories |
||
| 52 | |||
| 53 | * Challenges around Errata Management (Maintenance window). We have not plumbed errata management with a remote execution framework. |
||
| 54 | * General purpose scheduling. Can CloudForms do this function? |
||
| 55 | * GoferD approach may have legs |
||
| 56 | * What about Ansible (agent less) Satellite 5 can operate almost completely autonomously. |
||
| 57 | * From my original use cases from 7-13 |
||
| 58 | ** As a user I would like to create a script or manifest of remote commands and apply it to one or more systems |
||
| 59 | ** As a user I would like my remote command scripts to leverage smart variables |
||
| 60 | ** As a user I would like to be able to edit the remote command manifest and re-apply it to one or more systems |
||
| 61 | ** As a user I would like to copy the remote command manifest, modify the copy and apply it to one or more systems |
||
| 62 | ** As a user I would like the ability to archive/version a remote command manifest as content |
||
| 63 | ** As a user I would like to ability to undo the changes evoked by the execution of a remote command manifest (within reason) |
||
| 64 | ** As a user I would like monitor the operational status of an evocation of remote commands (# of successful completions, # of failures) |
||
| 65 | ** As a system I want the application of remote commands to retry on failure on a per system basis |
||
| 66 | ** As a user I would like to apply a remote command manifest to a system group, a host-group, or under Sat 6 script control, to systems that match Facts |
||
| 67 | ** As a user I need to browse remote command manifests in the system from the CLI/API |
||
| 68 | ** As a user I need the ability to evoke remote commands from the CLI/API |
||
| 69 | ** As a user I would like to schedule the evocation of remote commands at any granularity |
||
| 70 | ** As a user I want the ability to use Kerberos tickets to authenticate the receipt of remote command manifests from Satellite 6 (can piggyback on QPID) |
||
| 71 | ** As a user I want Satellite 6 to log all invocations of remote commands including their disposition |
||
| 72 | |||
| 73 | h3. Requirements |
||
| 74 | |||
| 75 | * User stories will be broken down of the into specific actionable tasks to design and develop against. |