Skip to content
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

Added lazy sync functionality #279

Merged
merged 10 commits into from
Oct 26, 2023

Conversation

fritzduchardt
Copy link
Contributor

@fritzduchardt fritzduchardt commented Aug 7, 2023

…has changed since the last sync. Added extra field to lock file in order to keep track of config changes.

Signed-off-by: Fritz Durchardt <[email protected]>
Fritz Durchardt added 2 commits August 10, 2023 13:31
@fritzduchardt fritzduchardt changed the title feat: added lazy sync functionality Draft: added lazy sync functionality Aug 10, 2023
Signed-off-by: Fritz Durchardt <[email protected]>
@@ -50,6 +51,7 @@ func NewSyncCmd(o *SyncOptions) *cobra.Command {

cmd.Flags().StringSliceVarP(&o.Directories, "directory", "d", nil, "Sync specific directory (format: dir/sub-dir[=local-dir])")
cmd.Flags().BoolVarP(&o.Locked, "locked", "l", false, "Consult lock file to pull exact references (e.g. use git sha instead of branch name)")
cmd.Flags().BoolVar(&o.Eager, "eager", false, "Ignore lazy setting in vendir yml and eagerly fetch all remote content")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did we decide to have default functionality of vendir to fetch only if vendir.yaml has changed else ignore?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The proposal is already open. I think the default will remain unchanged, but if you have this new feature enabled via vendir.yaml config, you can opt out by setting the eager flag.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kumaritanushree the default behavior will not change - vendir will always fetch. However, if the user sets lazy to true in the vendir.yaml for a particular content, lazy fetching will apply. The global flag serves the purpose to force a fetch, even if lazy is set in vendir.yaml

Signed-off-by: Fritz Duchardt <[email protected]>
Signed-off-by: Fritz Duchardt <[email protected]>
Signed-off-by: Fritz Duchardt <[email protected]>
@fritzduchardt fritzduchardt changed the title Draft: added lazy sync functionality Added lazy sync functionality Oct 10, 2023
@kumaritanushree
Copy link
Contributor

@fritzduchardt
I have gone through the functionality and looks good but flag --lazy somehow creating confusion for me. As we say in flag description it will override "lazy" value in directory content configuration.

But if we have vendir.yml:

apiVersion: vendir.k14s.io/v1alpha1
kind: Config
directories:
- path: sponnet
  contents:
  - path: .
    lazy: false
    http:
      url: https://github.com/spinnaker/sponnet/archive/refs/tags/v1.26.0.tar.gz

And we run just vendir sync on this it will not override this value. Also it does not make much sense to use such config but if will just look into flag --lazy it sounds the same.

Here --lazy will only update "lazy" value false not vice versa and description does not tell that.
I am not able to think better description as of now.
@joaopapereira any suggestion on this?

@Zebradil
Copy link
Member

If I read the proposal correctly, lazy is false by default in the config. It can be explicitly changed to true. To disable the "lazy" from CLI, --lazy=false has to be used.

So, it wouldn't make much sense to use lazy: false in the config because it's the default. Even if it is used, --lazy=false won't affect the corresponding directories, they will be synced "non-lazily".

Does that make sense?

@joaopapereira
Copy link
Member

I think that @Zebradil answer make sense

@kumaritanushree
Copy link
Contributor

LGTM

Copy link
Member

@joaopapereira joaopapereira left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I made some comments in the PR. Also, can we add some end-to-end tests to ensure we are doing the correct thing when using the lazy flag?

"fmt"
"gopkg.in/yaml.v3"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we use sigs.k8s.io/yaml instead? Just to keep it consistent

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure

go.mod Outdated
@@ -27,6 +27,8 @@ require (
sigs.k8s.io/yaml v1.3.0
)

require gopkg.in/yaml.v3 v3.0.1
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When this becomes indirect again, please let us revert this change

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok

@@ -50,6 +51,7 @@ func NewSyncCmd(o *SyncOptions) *cobra.Command {

cmd.Flags().StringSliceVarP(&o.Directories, "directory", "d", nil, "Sync specific directory (format: dir/sub-dir[=local-dir])")
cmd.Flags().BoolVarP(&o.Locked, "locked", "l", false, "Consult lock file to pull exact references (e.g. use git sha instead of branch name)")
cmd.Flags().BoolVar(&o.Lazy, "lazy", true, "Override \"lazy\" value in directory content configuration")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we can change the text here to something like:
"When this flag is set to 'false' it ignores the 'lazy' value in the directory content configuration"
Do you think it is easier to understand what the flag does?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking along the same lines. It it less vague about the purpose of this option.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @joaopapereira This CLI option 'lazy' (default value is true) is really confusing. With vendir 0.37.0, vendir sync --lazy=true won't do lazy fetch. This behavior does not comply with the proposal:
https://github.com/carvel-dev/carvel/tree/develop/proposals/vendir/001-lazy-synching-on-stable-config#other-approaches-considered
图片

This proposal should mean the CLI option --lazy default to false, and if --lazy is set to true, vendir will do lazy fetch,
Also this PR defines 'Lazy bool' as a bool instead of *bool, so it can not be used to override the CLI option '--lazy' because it always has a default value 'false'.

type DirectoryContents struct {
	Path string `json:"path"`
	Lazy bool   `json:"lazy,omitempty"`

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jessehu The proposal was:

  • to add the lazy option to vendir.yml to allow skipping sync when the config is not changed,
  • to add the --lazy CLI argument to temporarily disable the effect of the lazy option.

What you reference to is a considered approach that could've satisfied the use case but wasn't accepted.

image

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. Thanks. However this 'other approach considered' makes more sense. The current code behaves a little weird:

  1. vendir sync --lazy=true won't do lazy fetch (--lazy default to true) since it does not overrites in lazy setting in vendir.yml
  2. vendir sync --lazy=false won't do lazy fetch since it overrites in lazy setting in vendir.yml

According to this behaviour, this CLI flag should be named ignoreLazySetting or noLazy rather than lazy (the setting name in verdir.yml)

cmd.Flags().BoolVar(&o.Lazy, "lazy", true, "Set to 'false' it ignores the 'lazy' flag in the directory content configuration")

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The alternative approach is less flexible, as it doesn't allow configuring "laziness" per directory in the vendir.yml configuration file.

The selected name of the CLI flag is a little confusing, I agree. It might've been more explicit to use, as you mentioned, --noLazy or alike instead of --lazy=false.

@@ -243,3 +278,17 @@ func maybeChmod(path string, potentialPerms ...*os.FileMode) error {

return nil
}

func handleLazySync(oldConfigDigest string, newConfigDigest string, fetchLazyGlobalOverride bool, fetchLazy bool) (bool, bool) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We try to keep functions that are only used in a single struct internal to the structure even if they do not use the structure itself. That way we will know the scope in which we expect these functions to run.
With that in mind do you mind adding this function to the Directory struct?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not at all - done


import "testing"

func Test_handleLazySync(t *testing.T) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not a fan of testing not exported functions. I understand here that this code would be more complex than testing from the outside. Is there any refactoring that can make this easier?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No worries, let's remove it and use the e2e test instead

Copy link
Member

@joaopapereira joaopapereira left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a comment about the added test.
After that is solved I think we are good to merge this PR


package e2e

import (
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We do have require package as a dependency, and we are using it to do all the assertions in the other tests, you can see an example here.
Do you mind refactoring this test to make it similar to the other tests?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not at all - look much more concise now

Copy link
Member

@joaopapereira joaopapereira left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@joaopapereira joaopapereira merged commit 890f119 into carvel-dev:develop Oct 26, 2023
4 checks passed
Zebradil added a commit to Zebradil/carvel that referenced this pull request Dec 21, 2023
Zebradil added a commit to Zebradil/carvel that referenced this pull request Dec 21, 2023
Zebradil added a commit to Zebradil/carvel that referenced this pull request Dec 26, 2023
praveenrewar pushed a commit to carvel-dev/carvel that referenced this pull request Dec 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

Only run sync for stable versions, if vendir.yaml has changed since last sync
5 participants