Skip to content
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

Merged
merged 30 commits into from
Aug 31, 2020
Merged

Initial mistral removal from st2 #5011

merged 30 commits into from
Aug 31, 2020

Conversation

amanda11
Copy link
Contributor

@amanda11 amanda11 commented Aug 4, 2020

Remove mistral and postgres from st2ci workflows as part of the Mistral deprecation

Addresses st2from #4762

Resolves #5012

@pull-request-size pull-request-size bot added the size/XXL PR that changes 1000+ lines. You should absolutely split your PR into several. label Aug 4, 2020
@amanda11
Copy link
Contributor Author

amanda11 commented Aug 4, 2020

Initial mistral removal, to see what happens on the CI runs. Further testing to be done...

@amanda11 amanda11 marked this pull request as draft August 4, 2020 15:32
@amanda11
Copy link
Contributor Author

amanda11 commented Aug 4, 2020

Not ready for review, missed a whole bunch of changes!

@arm4b arm4b mentioned this pull request Aug 10, 2020
25 tasks
@arm4b arm4b added the feature label Aug 10, 2020
@arm4b
Copy link
Member

arm4b commented Aug 10, 2020

FYI CircleCI build is green now as we merged related st2-packages change: StackStorm/st2-packages#656

@amanda11
Copy link
Contributor Author

@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...

Copy link
Contributor Author

@amanda11 amanda11 left a 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
Copy link
Contributor Author

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?

Copy link
Contributor

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.
#
Copy link
Contributor Author

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',
Copy link
Contributor Author

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?

Copy link
Contributor

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!

Copy link
Contributor Author

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
Copy link
Contributor Author

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):
Copy link
Contributor Author

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.

Copy link
Contributor

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?

Copy link
Contributor Author

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):
Copy link
Contributor Author

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"
Copy link
Contributor Author

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.

Copy link
Contributor

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/
Copy link
Contributor Author

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 '
Copy link
Contributor Author

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.
Copy link
Contributor Author

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?

Copy link
Contributor

@m4dcoder m4dcoder left a 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',
Copy link
Contributor

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!

@@ -44,73 +44,5 @@ def setup():
script_setup.setup(config, register_mq_exchanges=False)


def add_result_tracker(exec_id):
Copy link
Contributor

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.

Copy link
Contributor Author

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.

add_result_tracker(child_exec_id)


def del_result_tracker(exec_id):
Copy link
Contributor

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
Copy link
Contributor

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',
Copy link
Contributor

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?

Copy link
Contributor Author

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):
Copy link
Contributor

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?

@amanda11 amanda11 marked this pull request as ready for review August 10, 2020 22:23
@amanda11 amanda11 changed the title Initial mistral removal from st2 [WIP] Initial mistral removal from st2 Aug 10, 2020
@amanda11 amanda11 requested a review from m4dcoder August 13, 2020 16:10
CHANGELOG.rst Outdated Show resolved Hide resolved
@arm4b arm4b added this to the 3.3.0 milestone Aug 17, 2020
@arm4b
Copy link
Member

arm4b commented Aug 24, 2020

@m4dcoder looks like this mistral removal PR needs a second review round?

Copy link
Contributor

@m4dcoder m4dcoder left a 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.

@amanda11 amanda11 merged commit 0e83fc5 into StackStorm:master Aug 31, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking change feature size/XXL PR that changes 1000+ lines. You should absolutely split your PR into several.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Remove mistral from the launch_dev.sh script
4 participants