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
Fixed typos and added informations authored Sep 20, 2017 by Côme Chilliet's avatar Côme Chilliet
Hide whitespace changes
Inline Side-by-side
deployment-features.md
View page @ 13fdee6e
...@@ -4,39 +4,61 @@ ...@@ -4,39 +4,61 @@
Add a way to specify for a computer or a group of computers, the authorized time frame for deployment. 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. Trying to schedule or trigger deployments outside of this frame should be forbidden.
For instance if boundaries are 8PM -> 10PM 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. * 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.
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 #### 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 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 This should be done as part of the argonaut plugin
#### Scheduling Retry jobs #### Scheduling 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.
#### Actual fonctionality #### Present functionality
Right now when a job has failed we can read the error text and we can abort it. 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. 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 ### 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 We may add back a way to start jobs from the queue and use the same form for retrying a failed job.
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