Is Python3.7 officially supported by StackStorm

Is Python3.7 officially supported by StackStorm e.g. Full testing as part of the CI/CD?

StackStorm is tested on python 3.6. You can still try to run this on python 3.7 and let us know if you encounter any issues.

I’ve been running StackStorm 3.2 on Debian Buster which is Python3.7 only. Long story short, eventlet 0.25.0 is buggy (bumping to 0.25.1 seemed to resolve the errors), icontains raises exceptions, rules silently fail to match which I can’t explain why. This is why I’m asking for an official position.

The thing is Ubuntu Bionic comes with Python 3.6 and Python 3.7 packages. So it should be possible to test both versions on Ubuntu. The flow on effect being if Python 3.7 works on Ubuntu, it’ll most likely work on Debian and other distros.

It would also help if you post logs from the rules engine so we can check what is going on.

I just checked and icontains doesn’t do anything special, as long as both arguments are strings, it should work.

It’s possible though that one argument is bytes and other is unicode (string) and that’s why it’s failing. I will look into adding a test case for that.

Thanks for commenting @kami. This is really the point of my question. I don’t want to burden the team asking for support on unsupported versions of Python/OS. I couldn’t see anything explicit in the St2 documentation as to which version(s) of Python3 are supported. If Python3.7 is considered compatible and supported, I’ll open a github issue with detailled tracing etc.

Yeah, Python 2.7 is going to be EOL soon so we should also come up with an official plan for removing support for Python 2.7 and only supporting Python 3.x deployments in the future.

But yes, if it works under Python 3.6 it’s very likely that it will also work under 3.7 and also 3.8 (vice-versa is not necessary 100% true though).

As far as rule criteria comparison operators go, I imagine it’s likely related to mixing bytes and string / unicode types - Update rule comparison operators to work with mixed operator types (bytes and strings) by Kami · Pull Request #4831 · StackStorm/st2 · GitHub.

That git PR looks like a potential match. I’ll rebuild the packages and test again once the patch has been merged to master. If I encounter problems, I’ll open an issue on github. Thanks!

I was able to run St2 on Debian using Python3.7, Mongo4.2 and there are exceptions processing rules.

 Traceback (most recent call last):
 File "/usr/lib/python3.7/logging/__init__.py", line 1034, in emit
 File "/usr/lib/python3.7/logging/__init__.py", line 880, in format
 File "/opt/stackstorm/st2/lib/python3.7/site-packages/st2common/logging/formatters.py", line 176, in format
 File "/opt/stackstorm/st2/lib/python3.7/site-packages/st2common/logging/formatters.py", line 151, in _format_extra_attributes
File "/opt/stackstorm/st2/lib/python3.7/site-packages/st2common/logging/formatters.py", line 65, in serialize_object
File "/opt/stackstorm/st2/lib/python3.7/site-packages/st2common/models/db/stormbase.py", line 105, in to_serializable_dict
File "/opt/stackstorm/st2/lib/python3.7/site-packages/st2common/models/db/rule.py", line 122, in mask_secrets
AttributeError: 'str' object has no attribute 'get'

Call stack:
File "/opt/stackstorm/st2/lib/python3.7/site-packages/eventlet/greenthread.py", line 221, in main
File "/opt/stackstorm/st2/lib/python3.7/site-packages/st2common/transport/consumers.py", line 71, in _process_message
File "/opt/stackstorm/st2/lib/python3.7/site-packages/st2reactor/rules/worker.py", line 88, in process
File "/opt/stackstorm/st2/lib/python3.7/site-packages/st2reactor/rules/engine.py", line 33, in handle_trigger_instance
File "/opt/stackstorm/st2/lib/python3.7/site-packages/st2reactor/rules/engine.py", line 64, in get_matching_rules_for_trigger
File "/opt/stackstorm/st2/lib/python3.7/site-packages/st2reactor/rules/matcher.py", line 38, in get_matching_rules
File "/opt/stackstorm/st2/lib/python3.7/site-packages/st2reactor/rules/matcher.py", line 38, in <listcomp>
File "/opt/stackstorm/st2/lib/python3.7/site-packages/st2reactor/rules/filter.py", line 72, in filter
File "/opt/stackstorm/st2/lib/python3.7/site-packages/st2common/log.py", line 105, in func_wrapper
Message: 'Validating rule %s for %s.'

I’ll try to find why there is a string instead of the a dictionary object. Would you like me to open an issue on githhub?

I’ve dug into the code a bit and it seems that action executions are being stored as strings. I don’t know how this would be happening.

Here’s some debug I added to the rule.py

        LOG.debug("ACTION RESULT: {} {}\n".format(type(result), result))
        action = result.get("action", {})
        LOG.debug("ACTION: {} {}\n".format(type(action), action))
        action_ref = action.get('ref', None)
        LOG.debug("ACTION REF: {}\n".format(action_ref))

Which produces the following output

2019-12-27 10:35:07,188 140344396449664 DEBUG rule [-] ACTION RESULT: <class 'dict'> {'action': 'ActionExecutionSpecDB@140344398146800(ref="chatops.post_message", parameters
="{\'route\': \'errbot\', \'user\': \'#autobot\', \'channel\': \'#autobot\', \'message\': \'Test: Icinga detected DOWN.\'}")', 'context': {}, 'criteria': {'trigger.payload.c
heck_type': {'pattern': 'host', 'type': 'equals'}}, 'description': 'Notify when a state change occurs.', 'enabled': True, 'id': '5e04b42659931ad5ded4c33f', 'metadata_file': 
'rules/storage_host_down.yaml', 'name': 'storage_host_down', 'pack': 'st2b_monitoring', 'ref': 'st2b_monitoring.storage_host_down', 'tags': [], 'trigger': 'icinga2.event.sta
te_change', 'type': 'RuleTypeSpecDB@140344398145600(ref="standard", parameters="{}")', 'uid': 'rule:st2b_monitoring:storage_host_down'}

2019-12-27 10:35:07,188 140344396449664 DEBUG rule [-] ACTION: <class 'str'> ActionExecutionSpecDB@140344398146800(ref="chatops.post_message", parameters="{'route': 'errbot', 'user': '#autobot', 'channel': '#autobot', 'message': 'Test: Icinga detected DOWN.'}")

Any ideas @kami?

After further testing, the errors above are non-fatal on Ubuntu using the unstable packages. The conclusion is StackStorm is broken in subtle ways under Debian 10 using Python 3.7.