-
Notifications
You must be signed in to change notification settings - Fork 53
Flyte CoPilot: Raw container support for all K8s containers #84
Conversation
Codecov Report
@@ Coverage Diff @@
## master #84 +/- ##
==========================================
+ Coverage 56.03% 59.73% +3.69%
==========================================
Files 93 95 +2
Lines 4806 5327 +521
==========================================
+ Hits 2693 3182 +489
- Misses 1830 1844 +14
- Partials 283 301 +18
Continue to review full report at Codecov.
|
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.
definitely need to spend more time reading through/using the code, but let me know if you want an approval just to move forward.
cd copilot; go build -o ../artifacts/flyte-copilot .; cd - | ||
|
||
cross_compile: | ||
@glide install |
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.
wat
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 good catch, how did that get in there?
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.
pre go.mod go i think
|
||
Once we know the main container, waiting for it to exit is simple and implemented | ||
Copying data is simple and implemented | ||
|
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.
It is not clear reading this which of the three you went with.
copilot/cmd/download.go
Outdated
|
||
func (d *DownloadOptions) Download(ctx context.Context) error { | ||
if d.remoteOutputsPrefix == "" { | ||
return fmt.Errorf("to-remoute-prefix is required") |
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.
spelling
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.
Done
} | ||
|
||
func (d *DownloadOptions) Download(ctx context.Context) error { | ||
if d.remoteOutputsPrefix == "" { |
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.
Should we add eventing to this to emit events to Admin?
Can we emit a timer?
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.
yes metrics i want to add, but as a second pass
@@ -0,0 +1,365 @@ | |||
package data |
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 imagine that the future flytectl will have all this code as well. Maybe this copilot will be a dependency. I can see users wanting to download inputs and outputs to past workflow and task executions to local.
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.
You have absolutely hit a point that I was thinking as well. CoPilot should be part of flytectl?
@@ -0,0 +1,439 @@ | |||
package utils |
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.
Maybe we can move this to flyteidl one day.
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.
yes after this gets merged i was going to move this to there and move eventing etc into propeller
@@ -17,6 +25,21 @@ var ( | |||
DefaultAnnotations: map[string]string{ | |||
"cluster-autoscaler.kubernetes.io/safe-to-evict": "false", | |||
}, | |||
CoPilot: FlyteCoPilotConfig{ | |||
NamePrefix: "flyte-copilot-", | |||
Image: "docker.pkg.github.com/lyft/flyteplugins/operator:v0.4.0", |
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 will make it so that we have to make two PRs right for every change we want to publish right? The first to make the actual change and the second to update this version. Are we okay with this? I think it's fine, just thought I'd mention it.
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.
no, its a config, so you can just change the config for the deployment?
if err != nil { | ||
return err | ||
} | ||
coPilotPod.InitContainers = append(coPilotPod.InitContainers, downloader) |
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.
Appending will make it the last init container - should we make it the first instead?
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.
cannot make the first like in case of IAM wait, but IAM wait is injected. Also, we do not really add the data volume to all init containers, thus not sure, if making it earlier has any uses?
return nil | ||
} | ||
|
||
func NewUploadCommand(opts *RootOptions) *cobra.Command { |
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 general, I feel like the uploader, downloader, and sidecar watcher should be different cmds in flytectl. That could get messy too but maybe worth thinking about?
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.
no this is not messy at all. I think I agree, I think they should be in flytectl, just that we need to move some code to flyteidl before we do that. What do you think we move ahead and then clean up after the fact. I can drop all the github workflows?
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.
sure sure, sounds good.
just let me know when you want the final +1 |
TL;DR
This PR implements FlyteCoPilot as an optional for all container executions. This is an Alpha feature
Type
Are all requirements met?
Complete description
Refer to Design Doc
Tracking Issue
flyteorg/flyte#297
Follow-up issue
flyteorg/flyte#316
flyteorg/flyte#317