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

Add support for runtime image and env vars in pipeline default properties #2656

Merged
merged 36 commits into from
Apr 20, 2022

Conversation

kiersten-stokes
Copy link
Member

@kiersten-stokes kiersten-stokes commented Apr 11, 2022

Upstream PR: elyra-ai/pipeline-editor#190

Fixes #1130; fixes #1768; fixes #1843; fixes #2268

Documentation updates in follow up PR #2668

What changes were proposed in this pull request?

This PR adds support for global pipeline properties. A new function (propagate_global_properties) is added to the PipelineDefinition object and called during PipelineDefinition __init__. This function first grabs the global properties from the primary pipeline app_data/properties stanza. For each property, all nodes (of all pipelines) are checked, and those nodes that 1. are generic, and 2. do not specify a value of their own have their value for that property replaced with the value of the global property.

This PR is working off the assumption that all global properties are grouped in the primary pipeline's app_data/properties stanza as shown below. Once we are sure of the final structure of the pipeline JSON sent from the frontend, changes can be made here as required.

"app_data":{
  "name":"read_and_write",
  "source":"read_and_write.pipeline",
  "properties":{
    "name":"read_and_write",
    "runtime":"Generic",
    "pipeline_defaults":{
      "runtime_image":"ex",
      "env_vars":[
        "val1=1",
        "val2=2"
      ]
    }
  },

This PR also adds a new API endpoint to serve the pipeline properties JSON (previously hardcoded on the frontend here). The new endpoint is elyra/pipeline/components/{runtime_type}/properties.

How was this pull request tested?

  • Add tests for global property propagation
  • Add handler test for new pipeline properties endpoint

Fixes #2268

Developer's Certificate of Origin 1.1

   By making a contribution to this project, I certify that:

   (a) The contribution was created in whole or in part by me and I
       have the right to submit it under the Apache License 2.0; or

   (b) The contribution is based upon previous work that, to the best
       of my knowledge, is covered under an appropriate open source
       license and I have the right under that license to submit that
       work with modifications, whether created in whole or in part
       by me, under the same open source license (unless I am
       permitted to submit under a different license), as indicated
       in the file; or

   (c) The contribution was provided directly to me by some other
       person who certified (a), (b) or (c) and I have not modified
       it.

   (d) I understand and agree that this project and the contribution
       are public and that a record of the contribution (including all
       personal information I submit with it, including my sign-off) is
       maintained indefinitely and may be redistributed consistent with
       this project or the open source license(s) involved.

@kiersten-stokes kiersten-stokes added this to the 3.8.0 milestone Apr 11, 2022
@elyra-bot
Copy link

elyra-bot bot commented Apr 11, 2022

Thanks for making a pull request to Elyra!

To try out this branch on binder, follow this link: Binder

@akchinSTC
Copy link
Member

akchinSTC commented Apr 11, 2022

Questions:

  • Will we ever need to support sub-pipeline/supernode "global" variables? - Deferred until the need arises
  • When a property contains a list or some other "container" type, how should the values be resolved ? - Deferred, working on runtime_image first.

@@ -432,6 +436,23 @@ def validate(self) -> list:

return validation_issues

def propagate_global_properties(self):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any difference between "propagating" vs "if not local, read global value"?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The approach using propagation isolates the changes to one location, otherwise, you'd have to know the locations where these kinds of properties are used (and probably all the way down to actual submission). I think validation would be easier as well and it minimizes the risk of errors.

In a side-discussion, you mentioned a use-case where we might need to know whether a given value was inherited from the globals or not. If that need were to arise, one could compare the node's value to the global's value and, if the same, assume inherited, otherwise not. The only case that doesn't solve is when the node redundantly defines a property and it's technically not inherited, but that strikes me as fairly "edgy".

@ajbozarth ajbozarth changed the title Add backend support for global pipeline properties Add support for global pipeline properties Apr 12, 2022
@ajbozarth
Copy link
Member

After discussion in scrum I have pushed the front end changes to this PR and updated the title.

The front-end currently points to the code sandbox for elyra-ai/pipeline-editor#190 and only supports the initially runtime images global property (or more specifically it supports global enum properties)

@ptitzler
Copy link
Member

ptitzler commented Apr 12, 2022

After some quick testing of the new UI for the global runtime image property, I believe we should change the default entry that's shown in the node properties from 'select' to the global setting, if one was specified. The reason is that the current behavior does not reduce the number of steps the user needs to complete to configure generic components. For example:

  • 3.7 workflow:

    • user adds 20 nodes
    • user must select a runtime image for 20 nodes
    • ... other config steps unrelated to runtime images
  • current PR workflow:

    • user configures global runtime image
    • user adds 20 nodes
    • user selects 'global' runtime image for 20 nodes
    • ... other config steps unrelated to runtime images
  • proposed PR workflow:

    • user configures global runtime image
    • user adds 20 nodes
    • ... other config steps unrelated to runtime images

(does not add actual support for those env vars)
@ajbozarth
Copy link
Member

ajbozarth commented Apr 12, 2022

user selects 'global' runtime image for 20 nodes

This step isn't necessary, the global value is used by default. The proposed workflow IS the current workflow

@ajbozarth
Copy link
Member

FYI I added env_vars to the global properties definition (palette). This allows users to add global env_vars, but until @akchinSTC or @kiersten-stokes add the backend support they won't actually be used yet.

AFAIK since we plan to "simply merge" list/array global properties with node properties there is no further front end work required since the backend will handle that. So unless we want to visualize any global env vars to the user in the node properties, the front end work is "done"

@ptitzler
Copy link
Member

ptitzler commented Apr 12, 2022

user selects 'global' runtime image for 20 nodes

This step isn't necessary, the global value is used by default. The proposed workflow IS the current workflow

How would the user know?

Edit: is you are saying that the pre-selected local entry is ... (global) then I encountered a bug because it's set to select ....

@ajbozarth
Copy link
Member

How would the user know?

The global property is "shown" in the dropdown for any node's property that isn't set it if the global property is set. I'm not sure how else we would surface it to the user. Maybe if they don't understand globals they might open the node properties for each node and check it themselves, but from a UX perspective they don't have to do anything.

@ajbozarth
Copy link
Member

Edit: is you are saying that the pre-selected local entry is ... (global) then I encountered a bug because it's set to select ...

Ah that would be a bug then. If the global is set then the global should be shown there. (either way it would still work, this would just be a UI bug)

rather than docker images specifically
@ptitzler
Copy link
Member

Edit: is you are saying that the pre-selected local entry is ... (global) then I encountered a bug because it's set to select ...

Ah that would be a bug then. If the global is set then the global should be shown there. (either way it would still work, this would just be a UI bug)

I am no longer able to recreate my initially observed behavior. Will try provide steps if I encounter this again. I did confirm that run/export appear to work as expected (including validation).

@ptitzler
Copy link
Member

Perhaps we should use (pipeline default) instead of (global) since it's more descriptive?

image

Copy link
Member

@ptitzler ptitzler left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@ajbozarth
Copy link
Member

I fixed the bug with lists in the tooltip that @ptitzler showed in scrum.

Once this gets final approval I'll merge and release the upstream pr and update here

@kevin-bates
Copy link
Member

@ajbozarth - Was there previously an interim build that could be used to verify this PR and, if so, could the same thing happen so we can capture the single-character fix in elyra-ai/pipeline-editor@cf36bb0 and avoid having to wait for its full approval/merge/release cycle?

Copy link
Member

@kevin-bates kevin-bates left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good. Just had the one question about the code scan alert. Since its medium severity, it's probably something we address later so I'm approving. Should we create an issue to track it?

EDIT: Forgot to add that I ran a multi-node pipeline through its paces relative to the defaults.


# Get pipeline properties json
jinja_loader = PackageLoader("elyra", "templates/pipeline")
template = Environment(loader=jinja_loader).get_template("pipeline_properties_template.jinja2")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are there plans to address this in this PR?

@akchinSTC
Copy link
Member

This looks good. Just had the one question about the code scan alert. Since its medium severity, it's probably something we address later so I'm approving. Should we create an issue to track it?

EDIT: Forgot to add that I ran a multi-node pipeline through its paces relative to the defaults.

Im going to leave this in for now or suppress it. The safe filter in jinja doesn't seem to satisfy the requirements of the checker. Turning on the escape feature is a no-go since it will essentially corrupt the template with encoded characters.

@ptitzler

This comment was marked as resolved.

Copy link
Member

@ptitzler ptitzler left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

ajbozarth added a commit to elyra-ai/pipeline-editor that referenced this pull request Apr 20, 2022
Add support for global properties as introduced in elyra-ai/elyra#2656
@akchinSTC akchinSTC merged commit f5260db into elyra-ai:master Apr 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component:pipeline-editor pipeline editor component:pipeline-runtime issues related to pipeline runtimes e.g. kubeflow pipelines impact:needs doc updates This PR requires follow up PR(s) for documentation and/or examples kind:enhancement New feature or request
Projects
None yet
6 participants