-
Notifications
You must be signed in to change notification settings - Fork 40
Implement fast multi-node via an in-cluster proxy #106
base: main
Are you sure you want to change the base?
Conversation
0a69224
to
9335b53
Compare
PR CI is now working. Still needs post-merge CI (could come in a follow up PR possibly) More docs are definitely a must-have before merging. |
29cd1fa
to
d3d4439
Compare
Codecov Report
@@ Coverage Diff @@
## main #106 +/- ##
==========================================
+ Coverage 65.13% 67.02% +1.89%
==========================================
Files 40 49 +9
Lines 2825 4552 +1727
==========================================
+ Hits 1840 3051 +1211
- Misses 761 1272 +511
- Partials 224 229 +5
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
c793ee2
to
ac53d2f
Compare
Added more coverage and updated the docs to reflect the new design. Once we wire up native multi-arch support (to follow) we should be able to get much higher coverage on build.go (there's some ~dormant code in there right now) |
ac53d2f
to
404ab4a
Compare
c564794
to
89fd202
Compare
621fe4d
to
9fa9390
Compare
7b491af
to
69bc95e
Compare
69bc95e
to
1b825e5
Compare
I wish the proxy implementation on this PR was simpler. I have some concerns this might turn into a maintenance challenge over time. What might make sense is to refine it a bit further so we have a "slow path fall-back" implemented where when/if the fast-path ever runs into problems or falls out of sync, users can still use the tool with the slow path until we update the proxy to match the new patterns. Since this is already a patch-bomb, one possible thought is to put this on a feature branch, continue to iterate a bit more, maybe cut an RC build from that branch and let it mature a bit longer. (Open to suggestions) |
Closes #26
This implements a proxy container inside the builder pod that can be used to handle image loading and transfer tasks at the end of a build.
I'm marking this WIP for the moment as it needs more documentation updates and CI work to publish the resulting image, but the main code should be ready for review.I would like to further improve/enhance native multi-arch support, but given we don't support that yet in the prior code, splitting that out as a follow on effort feels like the right approach (and this PR is already pretty massive)