-
Notifications
You must be signed in to change notification settings - Fork 119
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
Proposal: Make vendir lazy: don't syncing if the config has not changed #675
Conversation
✅ Deploy Preview for carvel ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Signed-off-by: Fritz Durchardt <[email protected]>
81a5fb4
to
f62de40
Compare
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.
Some process-related changes before we get to the approval phase.
The proposal looks good, but let us wait for the other approvers to have a look
--- | ||
title: "Lazy Synching" | ||
authors: [ "Fritz Duchardt <[email protected]>" ] | ||
status: "draft" |
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 please change this to "In Review"
title: "Lazy Synching" | ||
authors: [ "Fritz Duchardt <[email protected]>" ] | ||
status: "draft" | ||
approvers: [ ] |
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.
Approvers should be:
[ @kumaritanushree, @vmunishwar, @neil-hickey, @joaopapereira ]
|
||
To force a sync despite the `lazy` setting, a new option is added to the vendir binary, e.g. | ||
``` | ||
vendir sync --eager |
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 would lean towards having something like --ignore-lazy
to have a flag more obviously associated with the field name in vendir config.
I'd imagine this would be more helpful to non-native English speakers!
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.
+1, if we are saying it as lazy configuration then --ignore-lazy
makes more sense.
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 would lean towards having something like --ignore-lazy to have a flag more obviously associated with the field name in vendir config.
+1 to have clearer association.
i would even go a step further and following existing carvel convention to favor noun based flags. so concretely:
--lazy=true
(default) respects lazy specified sections--lazy=false
disables lazy evaluation and just forces download for anything
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.
@fritzduchardt do you mind doing the change above? I think that after that we will be ready to merge this proposal
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 have done it just now
Looks good. First approach seems better, adding config for each contents. For an example in one vendir.yam l if there are multiple contents and only one of them require non-lazy sync then we have to sync others as well multiple times if we add flag on binary. |
Looks great, thank you for the proposal! +1 to first approach being the better option. I'm inclined to think we should include a note that the sync was not performed in vendir output. Other than that this sounds like a good option. Semantically I am wondering is this really lazy loading? Lazy to me implies that we sync it on demand - but we are actually sync'ing on changes in the common case of this being enabled. This actually sounds more to me like caching, we store on first load, then we just re-use the local files unless there is a remote change. I'm pondering a |
- path: vendor | ||
contents: | ||
- path: custom-repo-custom-version | ||
hash: e8a5d1511f2eb22b160bb849e5c8be39da1c4ffa5fd56ded71ff095a8b24720b |
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.
let's rename hash
(too generic) field to something like configDigest
-- i'm thinking in future we may need to implement contentDigest
for ensuring content stays exactly as expected.
LGTM 👍 |
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.
Your last commit was not signed do you mind signing it so that we can merge the PR when we have all the needed approvals?
Thanks for the proposal. LGTM |
95e5d12
to
f7f520e
Compare
If have done this just now |
Signed-off-by: Fritz Duchardt <[email protected]>
f7f520e
to
48da96c
Compare
Signed-off-by: Fritz Duchardt <[email protected]>
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
No description provided.