-
Notifications
You must be signed in to change notification settings - Fork 350
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 Python Script node #722
Conversation
f60bd79
to
da63e40
Compare
da63e40
to
d41697c
Compare
b12f9c6
to
71c11f7
Compare
daae64c
to
ebdc2d4
Compare
@ptitzler Updated to |
For notebooks we upload the completed notebooks to the CO Sbucket . For Python scripts we we should probably do "the same" and capture STDOUT and STDERR. The script I used writes to STDOUT but the output is not logged in the KFP log nor is a Relevant excerpt from execution log:
Not having access to STDOUT/STDERR is going to be a problem should troubleshooting or validation be performed. For example, in another run the script failed and there's no information available why:
|
Confirmed "Open File" fix. Just realized it now always says this, which I guess is fine. |
Co-authored-by: Kevin Bates <kbates4@gmail.com>
@lresende, I don't see the increment of PIPELINE_CURRENT_VERSION in constants.ts. Is that what should be incremented? |
Will do today (Monday 9/22) |
Regarding the version increment, I think this particular increment should be conditional on whether the pipeline contains a python script node or not - as I touched on here. I really don't think we should unconditionally trigger a migration dialog when there is literally nothing to change. By making this particular increment conditional, older elyra versions can continue working with shared pipelines until those shared pipelines contain a python node - which will trigger a "You're running an older version of Elyra, please upgrade" message. Likewise, users of the current version will continue operating just fine. This does mean that the version check to determine if changes are warranted probably needs to be a list of versions and the check would be is this pipeline version not in the list of "acceptable" versions? If not in the list, prompt migration dialog and set pipeline version to "minimum acceptable" version. Only until a python node is added would the pipeline version then by incremented to the "current" version. Of course, when there are changes that DO warrant a migration, then the "acceptable" versions list is reset to only contain the "current" version and continues as a single entry until a "conditional" version is introduced again. |
Forgot to push :) |
For the version increment, we don't have the necessary infrastructure to enable what you are describing at the moment, but it would be something good to have for the future. |
I'm not seeing the version ever move from 2 to 3. I get prompted to migrate (unconditionally), save the pipeline and zero changes are made to the file (I copied the original and there are no differences after saving after migrating). As a result, I'm prompted to migrate every time I open a pipeline. Does saving a pipeline only persist changes if there are actual differences (which, in this case, there won't be since migration doesn't do anything. 😄 )? |
this last commit restricts the change of the associated node file only to the same type (e.g. if you originally created a python script node you can only update the file to point to another python script file). |
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.
Thanks Luciano - this is a nice feature.
Confirmed local execution works now as expected. Opened #939, which is not specific to this PR. |
Confirmed that KFP execution works but noticed
The last message was produced while a node was executed. |
Confirmed that an exported pipeline containing a Python node can be successfully uploaded to KFP using the KFP UI and runs there. LGTM for the PR pending resolution of STDERR behavior. |
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.
I did a code review of the front end code (no local testing or back end review) and have a handful of questions and code clean up comments, nothing blocking though if you'd rather address them in a followup PR
position += 20; | ||
this.setState({ showValidationError: false }); | ||
} else { | ||
// handle error |
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.
I think you meant to actually handle the error here and not leave it as a comment
the kfp execution of python scripts now captures both stdout and stderr into the same log file. Please update/build |
I believe somehow a regression was introduced because I am no longer able to drag a Python script onto the canvas.
|
With the latest fix both local and kfp execution of a mixed pipeline works. It does appear as if we are not yet capturing STDOUT and STDERR output in the right sequence for KFP execution. This code snippet in a Python node:
produces the following log file content:
Local execution is fine:
|
I believe this might be a limitation on how the |
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
Actually, I think this may be because remote execution is using Code needing to capture stdout or stderr should use run() instead: I believe I mentioned this in an earlier review. It might be worth updating kfp_notebook's python processing to use |
@kevin-bates @lresende do we need a separate issue to follow up on this? |
Thanks Patrick. I just created a kfp-notebook issue for this (linked above). |
Note for testing:
Requires elyra-ai/kfp-notebook#36
And the following env variables
Todos
Fixes #187
Developer's Certificate of Origin 1.1