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
Update deployment features authored Sep 20, 2017 by MCMic's avatar MCMic
Show whitespace changes
Inline Side-by-side
deployment-features.md
View page @ 4eee93e9
### Description ### Description
#### 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.
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.
This means a new generic deployment tab will be needed on systems to store this information (along with an LDAP schema). 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.
This should be checked by both FusionDirectory at the time of scheduling and Argonaut Server at the time of deploying.
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.
#### Retry jobs
There should also be a way to retry failed jobs in the deployment queue. 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.
\ No newline at end of file This should trigger a new job with the exact same parameters.
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