Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • fusiondirectory-plugins fusiondirectory-plugins
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 63
    • Issues 63
    • List
    • Boards
    • Service Desk
    • Milestones
  • Deployments
    • Deployments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • fusiondirectoryfusiondirectory
  • fusiondirectory-pluginsfusiondirectory-plugins
  • Wiki
  • deployment features

deployment features · Changes

Page history
added more subtask authored Sep 20, 2017 by bmortier's avatar bmortier
Hide whitespace changes
Inline Side-by-side
deployment-features.md
View page @ 41b49e07
......@@ -3,16 +3,42 @@
#### Time frame
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.
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.
#### 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 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
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.
### options
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
Clone repository
  • FusiondirectoryIPAM
  • LSC
  • LdapAlias
  • Modifying group member types
  • RestWebservice
    • addUpdateUser
    • addUpdateUserMultivaluated
    • createUser
    • deleteUser
  • SupannSupport
  • UserReminder
  • deployment features
  • fd lsc backend
  • fd lsc zimbra
  • filters acl
View All Pages