| ... | ... | @@ -4,24 +4,44 @@ |
|
|
|
|
|
|
|
Add a way to specify for a computer or a group of computers, the authorized time frame for deployment.
|
|
|
|
|
|
|
|
#### Actual fonctionality
|
|
|
|
#### Present functionality
|
|
|
|
|
|
|
|
None
|
|
|
|
Deployments can be sheduled or triggered at any time.
|
|
|
|
|
|
|
|
#### Demanded fonctionality
|
|
|
|
#### Demanded functionality
|
|
|
|
|
|
|
|
Trying to schedule or trigger deployments outside of this frame should be forbidden.
|
|
|
|
|
|
|
|
For instance if boundaries are 8PM -> 10PM
|
|
|
|
|
|
|
|
* Trying to trigger an installation at 7PM would fai
|
|
|
|
* Trying to trigger an installation at 7PM would fail
|
|
|
|
* Trying at 9PM to schedule an installation for 11PM should fail as well.
|
|
|
|
|
|
|
|
This should be checked by both FusionDirectory at the time of scheduling and Argonaut Server at the time of deploying.
|
|
|
|
|
|
|
|
We need to establish which actions would be forbidden outside of the time frame.
|
|
|
|
Existing actions are:
|
|
|
|
|
|
|
|
* ping
|
|
|
|
* System.halt
|
|
|
|
* System.reboot
|
|
|
|
* Deployment.reboot
|
|
|
|
* Deployment.reinstall
|
|
|
|
* Deployment.update
|
|
|
|
* Deployment.wake
|
|
|
|
* OPSI.update_or_insert
|
|
|
|
* OPSI.delete
|
|
|
|
* OPSI.host_getObjects
|
|
|
|
* OPSI.get_netboots
|
|
|
|
* OPSI.get_localboots
|
|
|
|
* OPSI.get_product_properties
|
|
|
|
|
|
|
|
I think the forbidden actions should be Deployment.*, but maybe System.* as well?
|
|
|
|
|
|
|
|
#### Changes
|
|
|
|
|
|
|
|
This means a new generic deployment tab will be needed on systems to store this information (along with an LDAP schema). This tab should be dynamically available in groups of systems and should be inherited.
|
|
|
|
This time would store a list of frame defined by a start time and an end time.
|
|
|
|
|
|
|
|
This should be done as part of the argonaut plugin
|
|
|
|
|
| ... | ... | @@ -29,14 +49,16 @@ This should be done as part of the argonaut plugin |
|
|
|
|
|
|
|
There should also be a way to retry failed jobs in the deployment queue.
|
|
|
|
|
|
|
|
#### Actual fonctionality
|
|
|
|
#### Present functionality
|
|
|
|
|
|
|
|
Right now when a job has failed we can read the error text and we can abort it.
|
|
|
|
|
|
|
|
#### Demanded fonctionality
|
|
|
|
#### Demanded functionality
|
|
|
|
|
|
|
|
We should also be able to retry a failed job.
|
|
|
|
|
|
|
|
This should trigger a new job with the exact same parameters.
|
|
|
|
|
|
|
|
### options
|
|
|
|
|
|
|
|
We may add back a way to start jobs from the queue and use the same form for retrying a failed job. |
