Update proposals/bring_your_own_argo_workflows/byoaw_context.md

Co-authored-by: Helber Belmiro <[email protected]>

Author: nsingla

proposals/bring_your_own_argo_workflows/byoaw_context.md

@@ -54,7 +54,7 @@ Given these conditions, an example compatibility matrix would look like the foll
 ### Upgrades/Migration
 In this feature, because the user is providing their own Workflow Controller, there will need to be documentation written on the Upgrade procedure such that self-provided AWF installations remain in-sync with the version supported by ODH during upgrades of the platform operator and/or DSPO.  This should be simple - typically an AWF upgrade just involves re-applying manifests from a set of folders.  Regardless, documentation should point to these upstream procedures to simplify the upgrade process.
 
-A migration plan should also be drafted (for switching the backing pipeline engine between user-provided and dspo-managed).  That is - if a DSPA has a WC but the user wishes to remove it and leverage their own ArgoWF, how are runs, versions, etc persisted between the two Argos. As it stands now, because DSP stores metadata and artifacts in MLMD and S3, respectively, these should be hot-swappable and run history/artifact lineage should be maintained.  The documentation produced should mention these conditions.
+A migration plan should also be drafted (for switching the backing pipeline engine between user-provided and dspo-managed).  That is - if a DSPA has a WC but the user wishes to remove it and leverage their own ArgoWF, how are runs, versions, etc persisted between the two Argo Workflows instances? As it stands now, because DSP stores metadata and artifacts in MLMD and S3, respectively, these should be hot-swappable and run history/artifact lineage should be maintained.  The documentation produced should mention these conditions.
 
 Documentation should also mention that users with self-managed Argo Workflows will be responsible for upgrading their ODH installations appropriately to stay in-support with Argo Workflows. That is - if a user has brought their own AWF installation and it goes out-of-support/EOL, the user will be responsible with upgrading ODH to a version that has DSP built on an AWF backend that is still in-support. This can be done by cross-referencing the support matrix proposed above. ODH will not be responsible for rectifying conditions where an out-of-support Argo Workflows version is installed alongside a supported version of ODH, nor will ODH block on upgrading if this condition is encountered. Consequently, this also means that shipped/included ArgoWorkflowControllers of the latest ODH release will support an Argo Workflows version that is still maintained and supported by the upstream Argo community.