search

StackStorm / st2

StackStorm (aka "IFTTT for Ops") is event-driven automation for auto-remediation, incident responses, troubleshooting, deployments, and more for DevOps and SREs. Includes rules engine, workflow, 160 integration packs with 6000+ actions (see https://exchange.stackstorm.org) and ChatOps. Installer at https://docs.stackstorm.com/install/index.html
https://stackstorm.com/
Apache License 2.0
6.08k stars 747 forks source link

Should st2timersengine default to local timezone? #4356

Open nmaludy opened 6 years ago

nmaludy commented 6 years ago
SUMMARY

Curious why it's necessary to configure the timezone of the timers engine, instead of simply defaulting to the timezone of the local system?

Looking at the code, it doesn't seem to matter what the timezone is, because the timers are using the timezone from the rule definition.

I'm asking for puppet-st2. Is this an essential config option, or is it OK to be defaulted to America/Los_Angeles everywhere?

ISSUE TYPE:
STACKSTORM VERSION

2.9dev

cognifloyd commented 6 years ago

ansible-st2 leaves the default America/Los_Angeles unless the playbook user explicitly changes it via the st2_config.timersengine.local_timezone var.

arm4b commented 6 years ago

cc @Kami which as I remember is in favor of unified UTC everywhere.

Kami commented 6 years ago

Yes, I believe all the services should always use UTC internally.

Local / custom timezone option should only be available for user facing stuff (CLI, WebUI, itd.). This way there is no confusion and potential date time conversion related issues when different objects are saved with different timezones, etc.

As far as this specific setting goes - it's there for backward compatibility reasons since we already supported this option before splitting timers engine into a separate service.

Having said that, I also think this value should default to UTC to avoid confusion.

nmaludy commented 6 years ago

Does the timezone even matter?

It looks like each rule specifies its own timezone. I'm confused, not sure what this setting actually affects?

cognifloyd commented 6 years ago

grepping the code, it looks like "local" timezone is a misnomer. It is the timezone used by the scheduler. https://github.com/StackStorm/st2/blob/0245a18198babafe2ab0abde31791cf526435234/st2reactor/st2reactor/cmd/timersengine.py#L58-L60 https://github.com/StackStorm/st2/blob/f71f9b1ca03db1f9b916336f33be46a099900788/st2reactor/st2reactor/timer/base.py#L19 https://github.com/StackStorm/st2/blob/f71f9b1ca03db1f9b916336f33be46a099900788/st2reactor/st2reactor/timer/base.py#L40-L46

The APScheduler docs refer to this as:

the scheduler’s timezone

Default setting: https://github.com/StackStorm/st2/blob/04d0d983e4d474c310300705c027ad3cb79b453c/st2reactor/st2reactor/timer/config.py#L58-L60 https://github.com/StackStorm/st2/blob/13955a090e8759ca4689544f33f24f02bd7073a1/conf/st2.conf.sample#L325-L339

cognifloyd commented 6 years ago

In conjunction with upgrading from 2.7.0 to 2.9.1, I just switched my production st2timersengine instance from US/Central to UTC. I will report back if I notice anything weird. I suspect timers will work just as they did before - triggering at the appropriate timezone-specific time.

stale[bot] commented 5 years ago

Thanks for contributing to this issue. As it has been 90 days since the last activity, we are automatically marking is as stale. If this issue is not relevant or applicable anymore (problem has been fixed in a new version or similar), please close the issue or let us know so we can close it. On the contrary, if the issue is still relevant, there is nothing you need to do, but if you have any additional details or context which would help us when working on this issue, please include it as a comment to this issue.

nmaludy commented 5 years ago

Still an issue

stale[bot] commented 5 years ago

Thanks for contributing to this issue. As it has been 90 days since the last activity, we are automatically marking is as stale. If this issue is not relevant or applicable anymore (problem has been fixed in a new version or similar), please close the issue or let us know so we can close it. On the contrary, if the issue is still relevant, there is nothing you need to do, but if you have any additional details or context which would help us when working on this issue, please include it as a comment to this issue.

nmaludy commented 5 years ago

Still an issue.

stale[bot] commented 5 years ago

Thanks for contributing to this issue. As it has been 90 days since the last activity, we are automatically marking is as stale. If this issue is not relevant or applicable anymore (problem has been fixed in a new version or similar), please close the issue or let us know so we can close it. On the contrary, if the issue is still relevant, there is nothing you need to do, but if you have any additional details or context which would help us when working on this issue, please include it as a comment to this issue.

cognifloyd commented 5 years ago

I've had my system in UTC for a long time without issue. Next step: an internal st2 discussion to decide which way to take this: