... | @@ -3,16 +3,42 @@ |
... | @@ -3,16 +3,42 @@ |
|
#### Time frame
|
|
#### Time frame
|
|
|
|
|
|
Add a way to specify for a computer or a group of them the authorized time frame for deployment.
|
|
Add a way to specify for a computer or a group of them the authorized time frame for deployment.
|
|
|
|
|
|
|
|
#### Actual fonctionality
|
|
|
|
|
|
|
|
None
|
|
|
|
|
|
|
|
#### Demanded fonctionality
|
|
|
|
|
|
Trying to schedule or trigger deployments outside of this frame should be forbidden.
|
|
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 fail, and trying at 9PM to schedule an installation for 11PM should fail as well.
|
|
|
|
|
|
For instance if boundaries are 8PM -> 10PM
|
|
|
|
|
|
|
|
* Trying to trigger an installation at 7PM would fai
|
|
|
|
* 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.
|
|
This should be checked by both FusionDirectory at the time of scheduling and Argonaut Server at the time of deploying.
|
|
|
|
|
|
|
|
#### 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 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 could be done as part of argonaut plugin or as a new plugin.
|
|
This should be done as part of the argonaut plugin
|
|
|
|
|
|
|
|
### Description
|
|
|
|
|
|
#### Retry jobs
|
|
#### Retry jobs
|
|
|
|
|
|
There should also be a way to retry failed jobs in the deployment queue. Right now when a job has failed we can read the error text and we can abort it. We should also be able to retry it.
|
|
There should also be a way to retry failed jobs in the deployment queue.
|
|
|
|
|
|
|
|
#### Actual fonctionality
|
|
|
|
Right now when a job has failed we can read the error text and we can abort it.
|
|
|
|
|
|
|
|
#### Demanded fonctionality
|
|
|
|
|
|
|
|
We should also be able to retry a failed job.
|
|
|
|
|
|
This should trigger a new job with the exact same parameters.
|
|
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. |
|
We may add back a way to start jobs from the queue and use the same form for retrying a failed job. |
|
|
|
\ No newline at end of file |