python tutorial for workflow versioning#1277
python tutorial for workflow versioning#1277alicejgibbons merged 9 commits intodapr:release-1.17from
Conversation
Signed-off-by: Albert Callarisa <albert@diagrid.io>
Signed-off-by: Albert Callarisa <albert@diagrid.io>
|
@acroca I updated the branch to 1.17 to get the tests to pass. |
alicejgibbons
left a comment
alicejgibbons
left a comment
There was a problem hiding this comment.
Am going to let @marcduiker review this one since it will be used for DaprU and will be the basis for the other tutorials
| A2 --> EW | ||
| ``` | ||
|
|
||
| The workflow starts by evaluating whether the `patch1` patch is patched. If it is, the workflow will continue to the `activity1` activity. If it is not, the workflow will continue to the `activity2` activity. |
There was a problem hiding this comment.
Im a bit confused by this example still. For instance, here, can we add what workflows_instances means in this context?
Like so is_patched is part of the workflow context and is set where? Is this an input param? https://github.com/dapr/quickstarts/pull/1277/changes#diff-3a044745ae283d6ad936247cd9f6a8d406edf23815b1bbc4f26085e2ef3b8bc4R5
Also can we give a bit more details in terms of the if the workflow name has any significance.
There was a problem hiding this comment.
The workflow_instances in the app.py is just the response from the API call to the example app that returns the workflow IDs that it created. Kind of the same as the workflow-manament example, but returning two workflow instances instead of only one, because we use two workflows.
The is_patched is not set anywhere, is the function we expose in the workflow context to do patch-style versioning. Patching is described in the docs (PR).
The workflow name doesn't mean anything, users can use any name workflows any way they want. I don't know if that's worth mentioning, we can't add a note for every concept that is not related to versioning, it might confuse people more than help. If they want more information on the specifics they can always visit the docs
Signed-off-by: Albert Callarisa <albert@diagrid.io>
Signed-off-by: Albert Callarisa <albert@diagrid.io>
Signed-off-by: Albert Callarisa <albert@diagrid.io>
|
|
||
| ## Inspect the named versioned workflow | ||
|
|
||
| Open the `after_named_version.py` file. This file shows how to migrate the workflow using named versions. A new version of the workflow (`notify_user`) is created that calls `send_sms`, while the original version is kept as `notify_user_v1` for any in-flight workflow instances. |
There was a problem hiding this comment.
| Open the `after_named_version.py` file. This file shows how to migrate the workflow using named versions. A new version of the workflow (`notify_user`) is created that calls `send_sms`, while the original version is kept as `notify_user_v1` for any in-flight workflow instances. | |
| Review the `after_named_version.py` file. This file shows how to create a new workflow version using named versions. A new version of the workflow (`notify_user`) is created that calls the `send_sms` activity, while the original version is kept as `notify_user_v1` for any workflow instances that might already be running. |
| SW2 --> SS --> EW2 | ||
| ``` | ||
|
|
||
| The workflow engine will always execute the latest version of the workflow for new instances. Older versions will only be executed for workflows that were already in-flight when the update was deployed. |
There was a problem hiding this comment.
| The workflow engine will always execute the latest version of the workflow for new instances. Older versions will only be executed for workflows that were already in-flight when the update was deployed. | |
| The workflow engine will always execute the latest version of the workflow when new instances are started. Older versions will only be executed for workflows that were already in-flight when the update was deployed. |
|
|
||
| ## Inspect the patching workflow | ||
|
|
||
| Open the `after_patching.py` file. This file shows how to migrate the workflow using patching. The `ctx.is_patched("send_sms")` check determines whether the workflow should execute the new `send_sms` activity or the original `send_email` activity. |
There was a problem hiding this comment.
| Open the `after_patching.py` file. This file shows how to migrate the workflow using patching. The `ctx.is_patched("send_sms")` check determines whether the workflow should execute the new `send_sms` activity or the original `send_email` activity. | |
| Review the `after_patching.py` file. This file shows how to create a new workflow version using patching. The `ctx.is_patched("send_sms")` check determines whether the workflow should execute the new `send_sms` activity or the original `send_email` activity based on if the patch `send_sms` is applied. |
| P -- No --> SE --> EW | ||
| ``` | ||
|
|
||
| New workflow instances will execute the patched code path (`send_sms`), while in-flight workflows will continue using the original code path (`send_email`). |
There was a problem hiding this comment.
| New workflow instances will execute the patched code path (`send_sms`), while in-flight workflows will continue using the original code path (`send_email`). | |
| New workflow instances will execute the patched code path (`send_sms`) since the workflow has already had a patch applied, while already started, in-flight workflows will continue using the original code path (`send_email`). |
| pip3 install -r requirements.txt | ||
| ``` | ||
|
|
||
| 3. Navigate back one level to the `versioning` folder. The `dapr.yaml` file is configured to run `before.py` by default. To try a versioned workflow, update the `command` field in `dapr.yaml` to run `after_named_version.py` or `after_patching.py` instead. |
There was a problem hiding this comment.
Add example here on how to change it
| == APP - versioning == send_email: Received input: user_id. | ||
| ``` | ||
|
|
||
| When running `after_named_version.py` or `after_patching.py`, the expected app logs are: |
There was a problem hiding this comment.
| When running `after_named_version.py` or `after_patching.py`, the expected app logs are: | |
| When running `after_named_version.py` or `after_patching.py`, the expected app logs change from `send_email` to `send_sms` and are: |
Signed-off-by: Albert Callarisa <albert@diagrid.io>
marcduiker
left a comment
marcduiker
left a comment
There was a problem hiding this comment.
One old wf name needs to be updated, rest looks good 👍
Signed-off-by: Albert Callarisa <albert@diagrid.io>
3 participants
Ref: #1274
Close: #1281
Adds a tutorial demonstrating how to use the two workflow versioning mechanisms.