-
-
Notifications
You must be signed in to change notification settings - Fork 746
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
Initial mistral removal from st2 #5011
Conversation
Initial mistral removal, to see what happens on the CI runs. Further testing to be done... |
Not ready for review, missed a whole bunch of changes! |
…as only if ALL tasks passed
FYI CircleCI build is green now as we merged related st2-packages change: StackStorm/st2-packages#656 |
@armab Thanks for merge, the CircleCI tests are now passing. I still need to work out why I've broken python3 - I would have expected that I'd break python2.7 unit-tests not python3. But I'm investigating this... |
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've added a review on my own code - with queries to be answered/points to validate.
@@ -249,7 +249,7 @@ def _clean_up_auth_token(self, runner, status): | |||
it doesn't throw. | |||
""" | |||
# Deletion of the runner generated auth token is delayed until the token expires. | |||
# Async actions such as Mistral workflows uses the auth token to launch other | |||
# Async actions use the auth token to launch other |
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 do we want to do about this statement for auth taken, the example comment is about Mistral. Is this relevant now mistral is removed?
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.
Keep this as is because the concept of async actions is generic although Mistral is the only runner that requires this at the moment.
@@ -1,54 +0,0 @@ | |||
# Copyright 2019 Extreme Networks, Inc. | |||
# |
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.
This package now only has an init.py - do we want to leave the st2api/controllers/exp package?
} | ||
|
||
MOCK_LIVEACTION_4_CHILD_1_RUNNING = { | ||
'id': 'idmistralchild1', |
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.
Do we need these tests rewritten for Orquesta?
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.
That would be nice if you can take a look and give it a try. The tail output for orquesta workflow is different though. Thanks!
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.
That would be nice if you can take a look and give it a try. The tail output for orquesta workflow is different though. Thanks!
Taking a look at the output in the scheduler log then it looks like the children of an orquesta workflow have the same fields like task_name but in an orquesta context. There may be different other parameters, but out of the ones that are mocked in these replies they seem to be the same.
I also took a look at a tail of an orquesta log and the output looks the same.
If I'm missing other changes to make to these mock objects please let me know.
@@ -9,7 +9,6 @@ flex==6.14.0 | |||
# commments.... | |||
git+https://github.com/Kami/logshipper.git@stackstorm_patched#egg=logshipper | |||
git+https://github.com/StackStorm/orquesta.git@224c1a589a6007eb0598a62ee99d674e7836d369#egg=orquesta | |||
git+https://github.com/StackStorm/python-mistralclient.git#egg=python-mistralclient |
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.
For some reason had to manually alter this requirements file even says say don't edit by hand - couldn't find any Makefile or anything that updated it. Is comment at top of file correct?
@@ -35,23 +35,11 @@ def test_get_runner_failure_not_found(self): | |||
self.assertRaisesRegexp(ActionRunnerCreateError, expected_msg, | |||
get_runner, 'invalid-name-not-found') | |||
|
|||
def test_get_query_module_success(self): |
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.
Only runner that seemed to support query and callback was mistral - so felt had to delete the UT. But I've left in the code about queries in main ST2.
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.
Yes, Mistral is the only one async runner that uses the query/callback. Can we set up a mock async runner in the test setup and then use that here so we preserve the functions and tests for any async runner in the future?
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.
@m4dcoder Is there a way to get it to load mock runners. At moment it looks like the unit-test will only find the real modules, not any in fixtures. I had a play with the fixturesloader, but it doesn't seem to load them at the right level - just in the db.
So the stevedore doesn't load them.
I could MagicMock at the stevedore level, but I wasn't sure if we wanted to test with that in.
Any thoughts? (For now I've put back the tests but commented out)
@@ -95,3 +95,53 @@ def test_rerun_task_of_workflow_already_succeeded(self): | |||
self.assertNotEqual(ex.id, orig_st2_ex_id) | |||
ex = self._wait_for_state(ex, action_constants.LIVEACTION_STATUS_SUCCEEDED) | |||
self.assertEqual(ex.context['workflow_execution'], orig_wf_ex_id) | |||
|
|||
def test_rerun_and_reset_with_items_task(self): |
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.
There were tests for re-run with and without reset in mistral, but couldn't find equivalent in orquesta - so wrote new tests.
@@ -1,72 +0,0 @@ | |||
version: "2.0" | |||
name: "examples.mistral-complex" |
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.
These set of workflows were mistral, have not gone through all of these to see if we need to re-write to create orquesta equivalent.
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 think you need to worry about ensuring there is an Orquesta equivalent as part of this change. It would be good to have those, but there is a decent set of Orquesta examples, so don't worry too much about it right now.
-e{toxinidir}/st2client | ||
-e{toxinidir}/st2common | ||
commands = | ||
nosetests --rednose --immediate -sv contrib/runners/mistral_v2/tests/unit/ |
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.
As the unit tests nightly only seemed to do mistral - I removed them.
@@ -1269,7 +1266,7 @@ def __init__(self, resource, *args, **kwargs): | |||
help='Name of the workflow tasks to re-run.') | |||
self.parser.add_argument('--no-reset', dest='no_reset', nargs='*', | |||
help='Name of the with-items tasks to not reset. This only ' | |||
'applies to Mistral workflows. By default, all iterations ' | |||
'applies to Orquesta workflows. By default, all iterations ' |
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.
Option looks to have always been supported for Orquesta - it is in the documents and we had a unit-test, but the parser just referred to Mistral - so think it should have previously said both - so adjusted to Orquesta.
@@ -52,10 +52,6 @@ def add_result_tracker(exec_id): | |||
# Check runner type. |
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 results tracker was only supported for mistral, then should this whole file go? Or should we leave it in with the runner_type != mistral-v2 so the logic is there if need to add for new runners?
What about the actual results tracker itself?
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.
Great job! This takes a lot of time and effort. This looks good overall. I just have a few minor requests on preserving tests for query/callback for async runner.
} | ||
|
||
MOCK_LIVEACTION_4_CHILD_1_RUNNING = { | ||
'id': 'idmistralchild1', |
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.
That would be nice if you can take a look and give it a try. The tail output for orquesta workflow is different though. Thanks!
st2common/bin/st2-track-result
Outdated
@@ -44,73 +44,5 @@ def setup(): | |||
script_setup.setup(config, register_mq_exchanges=False) | |||
|
|||
|
|||
def add_result_tracker(exec_id): |
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.
Can we keep the st2 result tracker and minimize changes to it? st2 result tracker is a generic solution to pull results from a remote runner instead of having the runner push result into st2. It is not specific to Mistral. Although Mistral is the only one that uses it.
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.
Can we keep the st2 result tracker and minimize changes to it? st2 result tracker is a generic solution to pull results from a remote runner instead of having the runner push result into st2. It is not specific to Mistral. Although Mistral is the only one that uses it.
Hi @m4dcoder I've put back the st2-track-result back to where it was, but with an additional comment to explain why it's there, and to update when other runners support the result tracker.
st2common/bin/st2-track-result
Outdated
add_result_tracker(child_exec_id) | ||
|
||
|
||
def del_result_tracker(exec_id): |
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.
See comment above.
@@ -249,7 +249,7 @@ def _clean_up_auth_token(self, runner, status): | |||
it doesn't throw. | |||
""" | |||
# Deletion of the runner generated auth token is delayed until the token expires. | |||
# Async actions such as Mistral workflows uses the auth token to launch other | |||
# Async actions use the auth token to launch other |
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.
Keep this as is because the concept of async actions is generic although Mistral is the only runner that requires this at the moment.
@@ -40,9 +40,9 @@ def test_fire_queries_doesnt_loop(self): | |||
mock_query_state_1 = QueryContext( | |||
uuid.uuid4().hex, | |||
uuid.uuid4().hex, | |||
'mistral_v2', | |||
'orquesta_runner', |
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 orquesta runner doesn't use the Querier. Mistral is the only one that uses the querier. I want to preserve the generic solution here. Can we add a mock async runner in the test setup and use that here instead?
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'll look into getting that mock runner in this week, and update tests to use the mock runner.
@@ -35,23 +35,11 @@ def test_get_runner_failure_not_found(self): | |||
self.assertRaisesRegexp(ActionRunnerCreateError, expected_msg, | |||
get_runner, 'invalid-name-not-found') | |||
|
|||
def test_get_query_module_success(self): |
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.
Yes, Mistral is the only one async runner that uses the query/callback. Can we set up a mock async runner in the test setup and then use that here so we preserve the functions and tests for any async runner in the future?
Co-authored-by: Eugen C. <[email protected]>
@m4dcoder looks like this mistral removal PR needs a second review round? |
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. Once this is merged and new 3.3dev packages are built, please do a test run on the packages end to end to make sure st2 isn't generally broken.
Remove mistral and postgres from st2ci workflows as part of the Mistral deprecation
Addresses st2from #4762
Resolves #5012