Add DD_DASHBOARD_FORCE_SYNC_PERIOD environment variable

[puretension]

What does this PR do?

Adds DD_DASHBOARD_FORCE_SYNC_PERIOD environment variable to configure DatadogDashboard controller sync frequency, following the same pattern as DD_MONITOR_FORCE_SYNC_PERIOD.

Motivation

Fixes #2179 - DatadogDashboard controller has a hardcoded 60-minute force sync period, unlike DatadogMonitor which supports DD_MONITOR_FORCE_SYNC_PERIOD. This means dashboard drift from manual UI changes can persist for up to 60 minutes.

Additional Notes

• Implementation follows the exact same pattern as DatadogMonitor controller
• Defaults to 60 minutes if environment variable is not set
• Includes error handling for invalid values
• All existing tests pass

Minimum Agent Versions

No minimum version requirements - this is an operator-only change.

• Agent: N/A
• Cluster Agent: N/A

Describe your test plan

• Verified existing DatadogDashboard tests still pass
• Tested environment variable parsing logic with valid/invalid values
• Confirmed lint and build checks pass

Checklist

• PR has at least one valid label: enhancement
• PR has a milestone or the qa/skip-qa label

[puretension]

Hi! Could someone please add the 'enhancement' label and either a milestone or the 'qa/skip-qa' label to this PR?
The CI is failing due to missing labels/milestone.

[orkhanM]

Should any documentation be updated?

[orkhanM]

@puretension Thanks for putting this together! It looks good I think but it seems like this doesn't follow the same pattern as the monitors do exactly. I haven't dived too deeply into the patterns used in other crd controllers here but the Monitor controller seems to check the Monitor specific MonitorLastForceSyncTime rather than the generic LastForceSyncTime:

datadog-operator/internal/controller/datadogmonitor/controller.go

Lines 154 to 178 in 900987e

	} else if instance.Status.MonitorLastForceSyncTime == nil || (forceSyncPeriod-now.Sub(instance.Status.MonitorLastForceSyncTime.Time)) <= 0 {
	// Periodically force a sync with the API monitor to ensure parity
	// Get monitor to make sure it exists before trying any updates. If it doesn't, set shouldCreate
	m, err = r.get(instance, newStatus)
	if err != nil {
	logger.Error(err, "error getting monitor", "Monitor ID", instance.Status.ID)
	if strings.Contains(err.Error(), ctrutils.NotFoundString) {
	shouldCreate = true
	}
	} else {
	shouldUpdate = true
	}
	} else if instance.Status.MonitorStateLastUpdateTime == nil || (defaultRequeuePeriod-now.Sub(instance.Status.MonitorStateLastUpdateTime.Time)) <= 0 {
	// If other conditions aren't met, and we have passed the defaultRequeuePeriod, then update monitor state
	// Get monitor to make sure it exists before trying any updates. If it doesn't, set shouldCreate
	m, err = r.get(instance, newStatus)
	if err != nil {
	logger.Error(err, "error getting monitor", "Monitor ID", instance.Status.ID)
	if strings.Contains(err.Error(), ctrutils.NotFoundString) {
	shouldCreate = true
	}
	}
	updateMonitorState(m, now, newStatus)
	}
	}

The MonitorLastForceSyncTime seems to be set whenever a monitor is synced. I'm not sure if having a Monitor specific variable there was intentional or not or if the maintainers care about consistency in this case but thought it'd be worthwhile to bring to your attention.

[puretension]

@orkhanM Great catch! You're absolutely right about the consistency issue.

Looking at the Monitor controller pattern you referenced,
I can see it uses MonitorLastForceSyncTime for the force sync check.
I'll update the Dashboard implementation to use DashboardLastForceSyncTime
to match this pattern for consistency across controllers.

Thanks for pointing this out!

[puretension]

Should any documentation be updated?

I don't think any documentation updates are needed for this change
since it's an internal API field rename for consistency with the Monitor controller pattern.
But I'm not entirely sure😅 would appreciate the maintainers' input on this!