New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable / Disable scheduler job processing + provide Scheduler Status #12
Comments
- refactoring: removed static field OBJECT from all Jsonables, because this leads to misunderstanding - and wrong usage. Now parts using OBJECT.from(...) must use their own field for this. - added services, rest controller - added database tables On behalf of Daimler TSS GmbH.
- update documentation about architecture risk and technical debts and linked issue here. - renamed Start/Stop parts to more dedicated names - e.g. EnableScheduleJobProcessing - sending and handling missing events/messages - added integration test for schedule job processing disable/enable - renamed former named class SchedulerConfig to SchedulingEnabledByConditionConfiguration because no longer name conflict with new config in db On behalf of Daimler TSS GmbH.
- Some bugfixes - Added actions to developer admin UI - works now On behalf of Daimler TSS GmbH.
We provide here now a common way for getting status information in administration - not only for scheduling but also for any other kind of status information. One start entry point: |
Found SecHubAdministrationEnvironment problematic, will rename SecHubServerEnvironment to SecHubEnvironment and make available in shared kernel. Reason: We need the information about sechub server address very often and we have currently no email / notification where we use a special administration url. If we need this we should provide the administration url also inside SecHubEnvironment! Having multiple pods we can add the information inside kubernetes deployments as well in future! |
- add notifications about disable/enable job processing on scheduler - add notification tests into integration test - moved SecHubEnvironment to shared kernel so available everywhere - dropped SecHubAdministrationEnvironment and replaced by SecHubEnvironment, because currently we have no need for a special application - fixed StatusAdministrationRestControllerRestDocTest On behalf of Daimler TSS GmbH.
- refactoring: removed static field OBJECT from all Jsonables, because this leads to misunderstanding - and wrong usage. Now parts using OBJECT.from(...) must use their own field for this. - added services, rest controller - added database tables On behalf of Daimler TSS GmbH.
- update documentation about architecture risk and technical debts and linked issue here. - renamed Start/Stop parts to more dedicated names - e.g. EnableScheduleJobProcessing - sending and handling missing events/messages - added integration test for schedule job processing disable/enable - renamed former named class SchedulerConfig to SchedulingEnabledByConditionConfiguration because no longer name conflict with new config in db On behalf of Daimler TSS GmbH.
- Some bugfixes - Added actions to developer admin UI - works now On behalf of Daimler TSS GmbH.
- add notifications about disable/enable job processing on scheduler - add notification tests into integration test - moved SecHubEnvironment to shared kernel so available everywhere - dropped SecHubAdministrationEnvironment and replaced by SecHubEnvironment, because currently we have no need for a special application - fixed StatusAdministrationRestControllerRestDocTest On behalf of Daimler TSS GmbH.
At the moment a deployment in cluster environment - e.g. kubernetes - has got following problem:
When we a upgrade deployed server versions to next version, the running server instances will be stopped.... so also the JVMs... means also every running SecHub Job inside... After the new deployments these jobs are lost.
The easiest way to handle this, is to integrate a switch option into sechub administration and sechub scheduler.
Usecases:
When sheduling is enabled/disabled a notification to admins shall be sent, so it's clear what happend (when disabled no job processing happens...)
The text was updated successfully, but these errors were encountered: