Defect Dojo sync frequency from webui is ignored

[worming004]

Current Behavior

Updating the value of DEFECTDOJO_SYNC_CADENCE(defectdojo.sync.cadence) through web ui have no effect on scheduling. The method to update frequency is by using CRON_EXPRESSION_FOR_DEFECT_DOJO_SYNC through environment variable.

Steps to Reproduce

1. Start new instance of Hyades
2. With admin account, navigate to /admin/integrations/defectDojo
3. Activate DefectDojo Integration, use 60 for frequency
4. Restart api-server
5. The synchronisation happens at 2:00AM

Expected Behavior

2 Ways are fine.

• Web interface can configure the scheduler, the environment variable is removed
• Web interface remove integration with DefectDojo, the documentation only refer a configuration using environment variable

Hyades Version

(using docker images)

All quarkus component: 0.6.0-SNAPSHOT

hyades-apiserver:5.5.0
hyades-frontend:5.5.0

Repository Type

Hyades apiserver

Browser

N/A

Checklist

• I have read and understand the contributing guidelines
• I have checked the existing issues for whether this defect was already reported

[nscuro]

Thanks for reporting. Definitely an unintuitive gap right now. Ideally this should be configurable via environment variables and UI. If configured via env vars, the setting should be read-only in the UI. If configured via UI changes should apply immediately (-ish).

To enable the latter, we need to figure out a way to make other API server instances aware of when this config changes, so they can update their schedule. Since there is no central scheduler at the moment.

For context, in DT v4.x it was configurable via UI, but it required a server restart to take effect. Which of course isn't great either.

[worming004]

Thanks for the quick answer and your involvement:)

Only my 2 cents, propose to configure through UI and environment variable adding internal complexity for little added value. Maybe other users have another point of view.

About the decentralized scheduler, maybe I am wrong, but I expect that API server is a single instance. Only other components are horizontally scalable. So, in my mind the Scheduler is always a central and unique component. At least, the diagram in readme page do not show "API Server" service as composed by several instance.

EDIT: fix my terrible phrasing

[nscuro]

but I expect that API server is a single instance

Actually, you can scale the API server horizontally, too!

The way concurrent scheduling of the same task is handled, is via locks (https://github.com/lukas-krecan/ShedLock). This works because tasks are now scheduled via cron, whereas in v4.x they were scheduled relative to when the API server started. It is a very simple solution but it allowed us to avoid, or at least delay, introduction of yet another component.

At least, the diagram in readme page do not "API Server" service composed by several instance.

That diagram deserves an update, yes... :D

[nscuro]

Only my 2 cents, propose to configure through UI and environment variable adding internal complexity for little added value. Maybe other users have another point of view.

From what I've heard from users so far, configuration is a really subjective thing. You'll see technically averse folks demanding everything to be configurable via environment variables, since it plays better with configuration as code. On the other side you have "normal" users for whom every change would then require opening tickets with their operations team.

I personally am more inclined towards the former, but we can't simply dismiss the latter either. Perhaps the middle-ground is to focus on environment variables short-term, and work on something "better" that supports both use-cases mid- to long-term.