-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
SDK/Components - Simplified _create_task_factory_from_component_spec function #662
Merged
k8s-ci-robot
merged 1 commit into
kubeflow:master
from
Ark-kun:SDK/Components---Greatly-shortened-_create_task_factory_from_component_spec-function
Jan 15, 2019
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Can you add some comments about _created_task_transformation_handler? The only place this is populated seems to be the line 195 so it is not clear why it needs to exist as a list.
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 intent is to set it in the
Pipeline
context. I had that code in the PR, but then I decided to split that into its own PR. The intent will be more obvious there.Python context managers that replace some value usually make the value holder a list so that the context is re-entrant - so that the code does not break if you happen to have nested contexts. https://docs.python.org/3/library/contextlib.html#reentrant-cms
The high-level idea is as follows: Conceptually, what you get when you give arguments to a Component is a Task. But currently we need to get a
ContainerOp
instance. So there needs to be aTaskSpec
->ContainerOp
transformation that's applied automatically when the pipeline is being compiled.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.
What do you think would be the best wording for a comment?
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.
In some new cases (the existing cases will continue to work)
load_component
will need to returnTaskSpec
objects instead ofContainerOp
objects. So there needs to be a way to enable/disable theTaskSpec
conversion toContainerOp
. The_created_task_transformation_handler
holds the transformation procedure that can be changed or disabled.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.
Since some of the code is for graph components, would you hold it off this when we decide graph component priority? Or, is it possible to decouple graph component from container component?
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 code change is a foundation that is needed for multiple puzzle pieces that me and other team members are delivering this quarter. It's needed for the following efforts:
The reason this affects that much is that many features depend on having the full information which
TaskSpec
has, but that's lost in transition toContainerOp
.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 see. Thanks @Ark-kun.
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
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.
Just to clarify: The actual change that will make "component task factory function" output
TaskSpec
instead ofContainerOp
in some scenarios is coming in the next PR.This PR is just a refactoring that does not change the behavior.
BTW, this was the intent behind the whole
_dsl_bridge.py
file and the_task_object_factory
variable - bridge between the component structures and dsl structures likeContainerOp
https://github.com/kubeflow/pipelines/blob/master/sdk/python/kfp/components/_dsl_bridge.py#L40 . It turned out the initial effort was insufficient since only limited information was passed to that handler.