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

Workflow rerun doesn't inherit protected fields #5146

Open
minsis opened this issue Feb 9, 2021 · 10 comments
Open

Workflow rerun doesn't inherit protected fields #5146

minsis opened this issue Feb 9, 2021 · 10 comments

Comments

@minsis
Copy link
Contributor

minsis commented Feb 9, 2021

I dont know if I should list this a feature request or bug.

When clicking rerun in the history on the UI you have to reenter any passwords or protected fields as they do not carry over from the parent run. Since passwords and such are saved, a rerun of the workflow should be able to inherit the protected fields as it does with the others.

@blag
Copy link
Contributor

blag commented Feb 9, 2021

Please use our issue format, just like you did in #5145.

We need to know:

  • StackStorm version (Paste the output of st2 --version)
  • Exact steps to reproduce the problem (eg: what happens if you click rerun, and then don't change any of the parameter fields and just click run?)
  • Expected results
  • Actual results
  • Any other useful information, like screenshots or exact error messages

@minsis
Copy link
Contributor Author

minsis commented Feb 9, 2021

SUMMARY

When clicking rerun in the history on the UI you have to reenter any passwords or protected fields as they do not carry over from the parent run. Since passwords and such are saved, a rerun of the workflow should be able to inherit the protected fields as it does with the others.

STACKSTORM VERSION

st2 3.3.0, on Python 3.6.9

OS, environment, install method

Oracle 7 using st2-docker

Steps to reproduce the problem

Here I'm just using core.remote but it could be happening with others.

  • Configured a rule to run a remote command: ls -l / on a 10m Interval trigger. Execution is successful
    image

  • In history click on rerun which brings up the config window. Simply just click on run with the supposedly same configured parameters. This run will fail
    image

  • Click on rerun again and replace the obfuscated password with the correct password and click run. This will be successful

  • I looked to see if I could reproduce this on the CLI but I didn't see a way to do a rerun of the action. My assumption is the UI resubmits the previous parameters back to the API.

Expected Results

When clicking rerun on a failed action it should inherit all the parameters including obfuscated ones

Actual Results

The 2nd rerun of the failed (or any action) failed to run due to an authentication issue because the UI didn't provide the previous run's password.

@jensenja
Copy link

is there any update on this? I have a slightly different configuration but the outcome is still the same. Essentially we're storing AWS credentials encrypted in the KV store. These credentials are used for Terraform actions where we store the Terraform state in an S3 bucket:

parameters:
  AWS_DEFAULT_REGION:
    type: "string"
    description: "AWS region for Terraform S3 backend"
    required: true
    default: "{{ st2kv.system.tfbackend_AWS_DEFAULT_REGION | decrypt_kv }}"
    secret: true
  AWS_ACCESS_KEY:
    type: "string"
    description: "AWS Access Key for Terraform S3 backend"
    required: true
    default: "{{ st2kv.system.tfbackend_AWS_ACCESS_KEY | decrypt_kv }}"
    secret: true
  AWS_SECRET_KEY:
    type: "string"
    description: "AWS Secret Key for Terraform S3 backend"
    required: true
    default: "{{ st2kv.system.tfbackend_AWS_SECRET_KEY | decrypt_kv }}"
    secret: true
  RABBITMQ_PASSWORD:
    type: "string"
    description: "Password for RabbitMQ publishing"
    required: true
    default: "{{ st2kv.system.RABBITMQ_PASSWORD | decrypt_kv }}"
    secret: true
  payload:
    type: "object"
    required: true

If this workflow fails at any point, I'm unable to retry it in the Web UI without manually inputting the supposed default values. I've also tried completely clearing out the fields in hopes that the default values from the KV would be retrieved, but this doesn't work either.

@khushboobhatia01
Copy link
Contributor

@jensenja @minsis Are you seeing this issue only through Web UI? Does re-run work fine through CLI?

@minsis
Copy link
Contributor Author

minsis commented Apr 25, 2022

@jensenja @minsis Are you seeing this issue only through Web UI? Does re-run work fine through CLI?

I don't think the CLI has a rerun?

@jensenja
Copy link

There are re-run options via the CLI: https://docs.stackstorm.com/orquesta/operations.html

I have not personally attempted it via CLI however.

@minsis
Copy link
Contributor Author

minsis commented Apr 25, 2022

@jensenja What version of StackStorm are you using?

I've tested this again in 3.6.0 and it seems like everything is now working as expected.

@jensenja
Copy link

I'm running 3.6 via the one-liner install on an Ubuntu 20.04 VM:

jjensen@destackstorm:~$ dpkg --list | grep st2
ii  st2                                   3.6.0-3                            amd64        StackStorm Event-driven automation
ii  st2chatops                            3.6.0-1                            amd64        St2Chatops - StackStorm ChatOps.
ii  st2web                                3.6.0-1                            amd64        St2Web - StackStorm Web UI.

@minsis
Copy link
Contributor Author

minsis commented Apr 25, 2022

@jensenja When the workflow fails, are you trying rerun the entire workflow or just the specific task that failed?

I'm my case I'm just testing a very simple core.remote execution. Also, as suggested have you tried to test the rerun on the CLI?

@jensenja
Copy link

Typically the entire workflow, especially if we need some Terraform actions to execute (ie they need to be retried). I've had mixed results on running the individual tasks via the Web UI - namely if the Terraform action task succeeds, the execution flow stops after that specific task completes; the CLI will likely be better for this route as it might appear that the user has more control over task execution via the CLI, just from skimming the docs.

@arm4b arm4b added the security label Nov 23, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants