-
Notifications
You must be signed in to change notification settings - Fork 59
Retrieve launch plan interfaces from admin #103
Conversation
What is this for? Dynamic LP? |
Yes. |
pkg/compiler/admin.go
Outdated
"github.com/lyft/flyteidl/gen/pb-go/flyteidl/core" | ||
) | ||
|
||
// Should we call this something else? It can be used more generally if ever necessary. |
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.
Historically: I wanted to make both tasks and launchplan parameters in the compiler to take InterfaceProviders... but then launch plans diverged (with expected* stuff) maybe there is still hope?
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 can't think of a good name... InterfaceProviderProvider was the best I could come up with, so I'm leaving it as is for now.
Codecov Report
@@ Coverage Diff @@
## master #103 +/- ##
==========================================
+ Coverage 50.01% 50.13% +0.11%
==========================================
Files 128 129 +1
Lines 7966 8007 +41
==========================================
+ Hits 3984 4014 +30
- Misses 3594 3601 +7
- Partials 388 392 +4
Continue to review full report at Codecov.
|
@@ -97,6 +97,26 @@ func (a *adminLaunchPlanExecutor) GetStatus(ctx context.Context, executionID *co | |||
return item.ExecutionClosure, item.SyncError | |||
} | |||
|
|||
func (a *adminLaunchPlanExecutor) GetLaunchPlan(ctx context.Context, launchPlanRef *core.Identifier) (*admin.LaunchPlan, 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.
Having this method here is fine, but having a separate interface for this method is useful to differentiate the use cases and usage paths
"github.com/lyft/flyteidl/gen/pb-go/flyteidl/core" | ||
) | ||
|
||
// This object is meant to satisfy github.com/lyft/flytepropeller/pkg/compiler/common.InterfaceProvider |
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 comment does not answer why this is needed here?
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.
We need a struct to satisfy the interface because the function that we pass it to, compiler.CompileWorkflow
takes the common.InterfaceProvider
interface.
Thank you for the changes. |
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
* Initial copy from propeller * Remove travis * Linking the makefile * add k8s integration * add description for bumping versions * add permissions * add permissions * load my awesome image * use flyteadmin:test * Pick a running admin pod * Setup a clean cluster for integration tests * use builder phase * Request more memory for postgres * Fix script
# TL;DR When Propeller comes across a launch plan node in a `DynamicJobSpec` it will hit Admin to retrieve the interface for the LP to do the interface check. ## Type - [ ] Bug Fix - [x] Feature - [ ] Plugin ## Are all requirements met? - [x] Code completed - [x] Smoke tested - [x] Unit tests added - [x] Code documentation added - [x] Any pending items have an associated Issue ## Complete description Please see the issue linked below and also the SDK PR flyteorg/flytekit#92 for more information. A sample dynamic job spec object has been uploaded here as well. Please see the text file for the type of dynamic job spec this PR is meant to support. [dynamic_job_spec.txt](https://github.com/lyft/flytepropeller/files/4430252/dynamic_job_spec.txt) * Added a `GetLaunchPlan` function to a `launchplan/Reader` interface which sits alongside the `launchplan/Executor` interface. Admin client wrapper now satisfies both interfaces. * Added a call to that function in the dynamic job handler `buildContextualDynamicWorkflow` function. ## Tracking Issue flyteorg/flyte#139 ## Follow-up issue flyteorg/flyte#246 This PR will be deprecated upon completion of this issue.
TL;DR
When Propeller comes across a launch plan node in a
DynamicJobSpec
it will hit Admin to retrieve the interface for the LP to do the interface check.Type
Are all requirements met?
Complete description
Please see the issue linked below and also the SDK PR flyteorg/flytekit#92 for more information. A sample dynamic job spec object has been uploaded here as well. Please see the text file for the type of dynamic job spec this PR is meant to support.
dynamic_job_spec.txt
GetLaunchPlan
function to alaunchplan/Reader
interface which sits alongside thelaunchplan/Executor
interface. Admin client wrapper now satisfies both interfaces.buildContextualDynamicWorkflow
function.Tracking Issue
flyteorg/flyte#139
Follow-up issue
flyteorg/flyte#246
This PR will be deprecated upon completion of this issue.