Issue 10: Move state machine to terraform module

[voxparcxls]

Github Issue: #10

Description

Move bignbit state machine definition to terraform module

Overview of work done

TF update to step.tf, iam_step.tf, main.tf

Overview of integration done

CI Build, Workflow

PR checklist:

• Linted
• Updated unit tests
• Updated changelog
• Integration testing

See Pull Request Review Checklist for pointers on reviewing this pull request

[frankinspace]

Can you also update the examples/cumulus-tf to show how the module should be used in a cumulus deployment now?

[voxparcxls]

@frankinspace
Because it is now in /terraform , shouldn't this be named {}-BrowseImageWorkflow instead of {}-sm:

bignbit/terraform/step.tf

Line 2 in ee34659

name = "${local.ec2_resources_name}-sm"

[frankinspace]

@voxparcxls That's why I was wondering if just putting the state machine definition into the workflow module will work or not. Doesn't https://github.com/nasa/cumulus/releases/download/v16.1.2/terraform-aws-cumulus-workflow.zip create a state machine resource based on the definition passed in to it? I think we might end up with the same state machine defined twice

[frankinspace]

Last time we talked about this we had talked about the approach of calling the state machine inside the module from the cumulus workflow state machine that needs to use the module.

[voxparcxls]

Yes, terraform-aws-cumulus-workflow.zip has the VARs that inherit the definition. I think you're right.

Now, there is resource state_machine in modules/big_and_bit_module and browse_image_workflow

So it ends up creating both:

• svc-haile-cumulus-bignbit-BrowseImageWorkflow (from big_and_bit_module)
• haile-cumulus-BrowseImageWorkflow (from browse_image_workflow)

Perhaps finding a different way to declare the JSON definition and then have it invoke in cumulus workflow is one way to go about it.

@frankinspace

[voxparcxls]

Correct, But I believe the created module ‘bignbit_module’ should provide that file once it’s there.

With this module path:

in directory ../../terraform

bignbit/examples/cumulus-tf/step.tf

Line 6 in fd79394

definition = templatefile("../../terraform/state_machine_definition.json", {

[voxparcxls]

Correct, But I believe the created module ‘bignbit_module’ should provide that file once it’s there.

With this module path:

in directory ../../terraform

bignbit/examples/cumulus-tf/step.tf

Line 6 in fd79394

definition = templatefile("../../terraform/state_machine_definition.json", {

@frankinspace

The Nested workflow method doesn’t cover the problem of duplicate state machines once that “resource” is activate by the cumulus deployment big_and_bit_module and later used as a definition in browse_image_workflow module.



With the single JSON file state_machine_definition.json , its accessible for cumulus deploy and bignbit repo.


Update (bignbit repository):

• With the step.tf staying in examples/cumulus-tf/
  • step.tf resource sfn_state_machine and the browse_image_workflow are both able to located the state_machine_definition from ../../terraform/state_machine_definition.json


---

BLOCKER: There is a block for browse_image_workflow deploy in our bignbit CICD. 

There are variables and outputs required in that declared in the large cumulus https://github.com/nasa/cumulus/releases/download/v16.1.2/terraform-aws-cumulus.zip

I think this can be its own ticket. This PR can deal with the combined state_machine

[frankinspace]

@voxparcxls I added a commit with the suggestion we discussed on Wed. Please review and I think we're good to merge