RemoteExecution » History » Version 4
Kyle Baker, 12/15/2014 01:19 PM
| 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 | |||
| 12 | h2. Targeted Persona |
||
| 13 | |||
| 14 | 2 | Kyle Baker | [[Personas-SystemEngineer| Samuel - System Engineer]] |
| 15 | 1 | Kyle Baker | |
| 16 | h2. Status |
||
| 17 | |||
| 18 | 3 | Kyle Baker | h3. Use Cases |
| 19 | 1 | Kyle Baker | |
| 20 | Owner - David Caplan |
||
| 21 | Status - In Progress |
||
| 22 | Expected Delivery - TBD |
||
| 23 | Blockers - None |
||
| 24 | |||
| 25 | h3. Requirements |
||
| 26 | |||
| 27 | Owner - Mike Mccune / David Caplan |
||
| 28 | Status - Not Started |
||
| 29 | Expected Delivery - TBD |
||
| 30 | Blockers - Waiting on User Stories |
||
| 31 | |||
| 32 | h3. Wireframes |
||
| 33 | |||
| 34 | Owner - Kyle Baker |
||
| 35 | Status - Not Started |
||
| 36 | Blockers - Waiting on User Stories & Requirements |
||
| 37 | Last updated TBD - -- |
||
| 38 | |||
| 39 | h3. Development Stories |
||
| 40 | |||
| 41 | Owner - Foreman (TBD) Katello (TBD) |
||
| 42 | Status - Not Started |
||
| 43 | Expected Delivery - TBD |
||
| 44 | Blockers - Waiting on Wireframes |
||
| 45 | |||
| 46 | h2. Documentation |
||
| 47 | |||
| 48 | 3 | Kyle Baker | h3. Bugs/RFEs |
| 49 | |||
| 50 | 4 | Kyle Baker | -- |
| 51 | |||
| 52 | 3 | Kyle Baker | h3. Use Cases |
| 53 | 1 | Kyle Baker | |
| 54 | * Challenges around Errata Management (Maintenance window). We have not plumbed errata management with a remote execution framework. |
||
| 55 | * General purpose scheduling. Can CloudForms do this function? |
||
| 56 | * GoferD approach may have legs |
||
| 57 | * What about Ansible (agent less) Satellite 5 can operate almost completely autonomously. |
||
| 58 | * From my original use cases from 7-13 |
||
| 59 | ** As a user I would like to create a script or manifest of remote commands and apply it to one or more systems |
||
| 60 | ** As a user I would like my remote command scripts to leverage smart variables |
||
| 61 | ** As a user I would like to be able to edit the remote command manifest and re-apply it to one or more systems |
||
| 62 | ** As a user I would like to copy the remote command manifest, modify the copy and apply it to one or more systems |
||
| 63 | ** As a user I would like the ability to archive/version a remote command manifest as content |
||
| 64 | ** As a user I would like to ability to undo the changes evoked by the execution of a remote command manifest (within reason) |
||
| 65 | ** As a user I would like monitor the operational status of an evocation of remote commands (# of successful completions, # of failures) |
||
| 66 | ** As a system I want the application of remote commands to retry on failure on a per system basis |
||
| 67 | ** 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 |
||
| 68 | ** As a user I need to browse remote command manifests in the system from the CLI/API |
||
| 69 | ** As a user I need the ability to evoke remote commands from the CLI/API |
||
| 70 | ** As a user I would like to schedule the evocation of remote commands at any granularity |
||
| 71 | ** 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) |
||
| 72 | ** As a user I want Satellite 6 to log all invocations of remote commands including their disposition |
||
| 73 | |||
| 74 | h3. Requirements |
||
| 75 | |||
| 76 | * User stories will be broken down of the into specific actionable tasks to design and develop against. |