-
Notifications
You must be signed in to change notification settings - Fork 176
Update task timer use duration #5023
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
base: master
Are you sure you want to change the base?
Update task timer use duration #5023
Conversation
541e3a8 to
1b9c59a
Compare
| } | ||
|
|
||
| // GlobalValueDuration - Gets a duration global setting value | ||
| func (configPtr *ConfigItemValueMap) GlobalValueDuration(key GlobalSettingKey) time.Duration { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if this function is good idea because it assumes that the time unit is seconds.
So it would be bug to use it for example for: goroutine.leak.detection.check.interval.minutes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or kubevirt.drain.timeout (hours)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we had no such options (expecting minutes or hours), it might even be a good idea: users would know that all intervals and durations should be in seconds. But unfortunately it will not work :(
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what about renaming it to GlobalValueDurationSeconds?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On its own, this type is useful, and we could consider using it exclusively in the future. However, I am uncertain about replacing the existing options with it. I expect (though I’m not entirely sure) that doing so could lead to issues with backward compatibility. If the value is serialized, we cannot interpret an integer as a duration.
@milan-zededa and @eriknordmark can clarify it here.
TLDR:
I'm voting for 1) the new type and function 2) against applying it to already existing props, at least non-seconds ones
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's also a good idea to add multiple types like DurationSeconds, DurationMinutes, DurationHours, DurationDays... and use them accordingly to what is expected from a parameter
| const shortTime = 120 // Two minutes | ||
| certInterval := ctx.globalConfig.GlobalValueInt(types.CertInterval) | ||
| const shortTime = 2 * time.Minute | ||
| certInterval := time.Duration(ctx.globalConfig.GlobalValueInt(types.CertInterval)) * time.Second |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you want to use GlobalValueDuration here, but see my other comment.
1b9c59a to
ce032ad
Compare
|
regarding spdx check: seems the tool is wrong @OhmSpectator as I see this in this file: |
|
I'm now curious, where did we take this file from? |
And I am curious what this PR has to do with |
23639d2 to
cb64fc1
Compare
ah, rebase helped |
rene
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There clearly isn't a SPDX license in that header. |
eriknordmark
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Introducing the GlobalValueDurationSeconds() adds clarity but should we also define Seconds as a type in global.go (even if it looks the same as an Int) so that the definition of the value in global.go ends up using Seconds i.e., introduce a
configItemSpecMap.AddSecondsItem() and use it for all of the seconds time values?
If we do this, why not also introduce the Minutes and Hours function to parallel this - that makes the definitions in global.h a lot clearer.
cb64fc1 to
f148e8e
Compare
5a337ed to
a7b76b5
Compare
time.Duration Signed-off-by: Christoph Ostarek <[email protected]>
a7b76b5 to
ccfcb68
Compare
|
@christoph-zededa, are you planning to address the comments? This one? https://github.com/lf-edge/eve/pull/5023/files#r2169484219 |
|
EVE Upgrade fails all the time... It's better to check the logs. |
europaul
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's a very good idea to convert the parameters to time.Duration as soon as possbile. Very nice @christoph-zededa
| defaultDuration, minDuration, maxDuration time.Duration) { | ||
|
|
||
| if defaultDuration < minDuration || defaultDuration > maxDuration { | ||
| logrus.Fatalf("Adding int item %s failed. Value does not meet given min/max criteria", key) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| logrus.Fatalf("Adding int item %s failed. Value does not meet given min/max criteria", key) | |
| logrus.Fatalf("Adding duration item %s failed. Value does not meet given min/max criteria", key) |
| AgentSettings map[AgentSettingKey]ConfigItemSpec | ||
| } | ||
|
|
||
| // AddDurationItem - Adds integer item to specMap |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| // AddDurationItem - Adds integer item to specMap | |
| // AddDurationItem - Adds duration item to specMap |
| case ConfigItemTypeTriState: | ||
| return FormatTriState(val.TriStateValue) | ||
| case ConfigItemTypeDuration: | ||
| return fmt.Sprintf("%d", uint64(val.DurationValue.Seconds())) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe it would be better to use
| return fmt.Sprintf("%d", uint64(val.DurationValue.Seconds())) | |
| return fmt.Sprintf("%v", val.DurationValue) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't want to change it to show floats as of now it was always an integer with seconds.
Do you think it does not matter?
| } | ||
|
|
||
| // GlobalValueDuration - Gets a duration global setting value | ||
| func (configPtr *ConfigItemValueMap) GlobalValueDuration(key GlobalSettingKey) time.Duration { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's also a good idea to add multiple types like DurationSeconds, DurationMinutes, DurationHours, DurationDays... and use them accordingly to what is expected from a parameter
I don't understand why you need this? F.e. for hours you can just do: |
|
/rerun red (hoping to gather collect-info this time) |
you have to know how to convert the integer that you get out of the config to time.Duration for each parameter (because it could mean mins, secs, hours etc). I'll try to create a PR for this soon |
No, because it will fail during upgrade as So, I think I should reset this PR to ce032ad . Stacktrace: |
OhmSpectator
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The upgrade path is broken, so I am submitting a change request to avoid merging it for now.
Description
this is a follow-up of #4967 (comment)
pillar/updateTaskTimer: switch to less-error prone
How to test and validate this PR
same as #4967
Changelog notes
No user-visible changes.
PR Backports
Checklist
check them.