-
Notifications
You must be signed in to change notification settings - Fork 349
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
Conversation
Thanks for making a pull request to Elyra! To try out this branch on binder, follow this link: |
Questions:
|
@@ -432,6 +436,23 @@ def validate(self) -> list: | |||
|
|||
return validation_issues | |||
|
|||
def propagate_global_properties(self): |
There was a problem hiding this comment.
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"?
There was a problem hiding this comment.
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".
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) |
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:
|
(does not add actual support for those env vars)
This step isn't necessary, the global value is used by default. The proposed workflow IS the current workflow |
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" |
How would the user know? Edit: is you are saying that the pre-selected local entry is |
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. |
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
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). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
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 |
@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? |
There was a problem hiding this 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") |
There was a problem hiding this comment.
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?
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. |
This comment was marked as resolved.
This comment was marked as resolved.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Add support for global properties as introduced in elyra-ai/elyra#2656
Upstream PR: elyra-ai/pipeline-editor#190
Fixes #1130; fixes #1768; fixes #1843; fixes #2268
elyra/api/elyra.yaml
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 thePipelineDefinition
object and called duringPipelineDefinition
__init__
. This function first grabs the global properties from the primary pipelineapp_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.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?
Fixes #2268
Developer's Certificate of Origin 1.1