-
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
[v3] add design doc for the new render and deploy #5823
Conversation
Codecov Report
@@ Coverage Diff @@
## master #5823 +/- ##
==========================================
- Coverage 70.92% 70.85% -0.07%
==========================================
Files 438 446 +8
Lines 16434 16729 +295
==========================================
+ Hits 11656 11854 +198
- Misses 3921 3999 +78
- Partials 857 876 +19
Continue to review full report at Codecov.
|
kpt: [string] | ||
|
||
# This field defines the dry manifests from a variety of sources. | ||
generate: |
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.
Will the default for skaffold fix
once this change goes in be to treat "vanilla" deploy yaml files provided as DRY config? For example, once this change is in will skaffold's simple examples/
skaffold.yaml files all have build, render and deploy sections?
Would this yaml be treated as dry config?
https://github.com/GoogleContainerTools/skaffold/blob/master/examples/microservices/leeroy-app/kubernetes/deployment.yaml
What would the skaffold fix
yaml look like for:
examples/microservices skaffold.yaml
https://github.com/GoogleContainerTools/skaffold/blob/master/examples/microservices/skaffold.yaml
TLDR; nit: might be helpful to add an example with a no-op render and show how that is handled by skaffold fix
with the API update. From the doc I was a bit confused if the file would be added as DRY or WET config in the no-op render examples (I believe it would be DRY and a render:
phase would be added but an example might help clarify this)
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, I think those yaml files are dry config.
for
https://github.com/GoogleContainerTools/skaffold/blob/master/examples/microservices/skaffold.yaml, it would be like
build: NO CHANGE
render:
generate:
manifests:
- leeroy-web/kubernetes
- leeroy-app/kubernetes
deploy: # The deployer info is tolerated on purpose.
portForward: NO CHANGE
profiles: NO CHANGE
|
||
#### Under the hood | ||
|
||
Though the new UI looks similar except moving helm from "deploy" to "render", the actual implementation is very different. Instead of calling the `helm` CLI, the `skaffold-helm-inflator` functions are used to convert the `Helm` charts to a kpt [`ResourceList.items`](https://googlecontainertools.github.io/kpt/guides/producer/functions/#resourcelistitems). This function is expected to digest all the `helm` arguments listed in the `skaffold.yaml` reference doc [v2beta16](https://skaffold.dev/docs/references/yaml/#deploy-helm). |
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.
Are there any features/flags that skaffold+helm supports currently that are not backwards compatible with the skaffold-helm-inflator? If so they might be worth calling out in the migration story.
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.
Good point. The helm-inflator image is not there yet, we will add more doc once that part of work is more stabilized.
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, left some nits. Looks great!
Also not sure if you have travis access but I restarted the one job that had a Travis flake on this PR. |
|
||
### Builtin `kpt` | ||
|
||
`skaffold` will have `kpt` embedded via go bindata, which ship together with the skaffold binary to guarantee the versions match. |
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.
Are there any performance or binary size concerns w/ this approach? Skaffold is currently ~50Mb and kpt is also ~50Mb. Might make sense to add a blurb here around the possible tradeoffs (if there are any)
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.
Also it might make sense to add a blurb/section around how this will be tested specifically as I don't believe skaffold has integration tests that pull in updated external binary deps atm. Will skaffold pin to a kpt version and be updated ad-hoc? Use the latest kpt release? Perhaps nothing special is needed here (as it is somewhat similar to the situation for other binaries that skaffold calls out to) but kpt seems very tightly coupled in this case.
It might also make sense to add section here about what files/changes will be made the V2 Events proto (from meeting offline) and possibly the process there if it is non-trivial |
I would need to do more research on this. I have a gut feeling that the v2 events proto is more related to our release workflow (currently we release a single API version but in the future there would be two) than the kpt render/deploy part. WDYT? |
related: #5673
To Reviewers:
you can review the doc from here. The UX still uses the old field names.