-
Notifications
You must be signed in to change notification settings - Fork 204
Enable to push outdated images #1258
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
Conversation
sorry for the dumb question, but I could not get the point of rename |
| } | ||
| } | ||
| return updates, nil | ||
| return cfg, nil |
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.
nit: I suggest we could simplify the function signature of this config.LoadImageWatcher function to
func LoadImageWatcher(repoRoot string, includes, excludes []string) (*ImageWatcherSpec, error)and create a new error type config.NotFound, then check it here with errors.Is.
The reasons is
- current
okvalue here look quite weird, should it befound? such that it's clarifying shown what do we use it for. - I read the implementation of
config.LoadImageWatcheronce, looks like after check foros.IsNotExistwe have to passfalsevalue for it on all other cases.
What do you think of 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.
Thank you! No objection to that! Other part should use that error type, so let me address it as another patch: #1259
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.
thanks 👍
Thanks for giving me the opportunity to rethink it. This config field mainly aims to filter the image watcher files. With the name |
|
IMO, config field name should tell users what it actually does by setting its name, but what do you think? |
| } | ||
|
|
||
| // run periodically compares the image stored in the given provider and one stored in git. | ||
| // run periodically compares the image in the given provider and one in git repository. |
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.
Not in this PR's scope, but I feel that we should start thinking about simplifying the concurrency model implemented in this ImageWatcher package.
Current approach:
- Spawn goroutines for each image provider
- Inside each goroutine
- loop the repositories
- lock and pull to update the local git.repo data
- load the configuration at
.pipeto find the target providers - if the provider was specified, retrieve the latest images
- lock and update them
- loop the repositories
Suggestion:
- Spawn goroutines for each repository
- Inside each goroutine
- pull to update the local repo data
- load the configuration at
.pipeto find the target providers - loop the target providers
- retrieve the latest images and update them
Pros:
- don't need the look for
git.Pull - avoid complex concurrent processing for
git.Repo: pull and push - reduce the number of pulls and configuration loads (current: provider_num x repo_num, new: repo_num)
Cons:
- The pull interval for all image providers must be same (I suggest to move that field into
imageWatcherpart,imageProviderpart is only for defining how to interact with the image provider)
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're quite right. Current complex implementation is cause by the spec that requires to specify polling interval for each provider. I couldn't completely make up my mind for a long time. The way to be the same interval across all provider would be pretty simple, and love it. But isn't it really needed to configure the interval for each provider? I thought we should be more cautious about communication to the container registry than to git repository, that's why I designed like 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.
But as you said, using the same interval is pretty good if it's not worth supporting.
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.
For instance, a user has two image providers:
- Docker Hub that has the strict pull rate limit
- ECR that has not strict pull rate limit
For that, it's useful to respectively set pull intervals.
However, we don't have to handle such carefully if we define that case as an edge case.
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 in that case they can split into multiple pipeds.
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.
Ah, agree with you. The general case had better be prioritized. Okay, let me work on them in another PR. I'll fix your other change requests.
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.
👍
| return fmt.Errorf("failed to replace value at %s with %s: %w", target.Field, imageInRegistry, err) | ||
| } | ||
| w.mu.Lock() | ||
| f, err := os.OpenFile(path, os.O_WRONLY|os.O_TRUNC, os.ModeAppend) |
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.
Writing directly into the git.Repo may cause unexpected behaviors.
- other goroutines are also accessing this local directory too
- adding a new commit may cause a pull error in the future
So I think we have to clone it into a temporary directory for pushing the changes.
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.
Sounds great idea, will do so!
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 change will be unneeded if we change to spawn goroutines for each repository according to your suggestion in the above comment, right?
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.
Dumb... still remains an issue adding a new commit may cause a pull error in the future.
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.
Leave TODO comments so may I address them when I work on the issue to spawn goroutines for each repo?
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.
| if err := f.Close(); err != nil { | ||
| return fmt.Errorf("failed to close file %s: %w", path, err) | ||
| } | ||
| err = repo.Push(ctx, repo.GetClonedBranch()) |
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.
We need to commit the changes before pushing.
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.
Yup, that's the basic part...
| # encryptServiceAccountFile: /etc/piped-secret/encrypt-service-account.json | ||
|
|
||
| imageWatcher: | ||
| repos: |
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.
One vote from me to keep it as repos. It may contain not only the filter thing but also other configurable fields (e.g. interval).
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.
still do not have a good enough ideal for the name but the previous repos is lgtm. cc @nakabonne
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.
From now my thought has been varied. Let's keep as is.
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.
still do not have a good enough ideal for the name
Yup, I keep thinking the best name :D
|
The following ISSUES will be created once got merged. If you want me to skip creating the issue, you can use Details1. Spawn goroutines for each repositoryThis was created by todo plugin since "TODO:" was found in c70a038 when #1258 was merged. cc: @nakabonne.2. Clone repository another temporary destinationThis was created by todo plugin since "TODO:" was found in c70a038 when #1258 was merged. cc: @nakabonne.3. Make it changeable the commit messageThis was created by todo plugin since "TODO:" was found in c70a038 when #1258 was merged. cc: @nakabonne. |
|
@nghialv Fixed them. I'll address the created three issues in the next PR. |
|
/lgtm |
|
/cc @khanhtc1202 |
|
thanks 👍 |
What this PR does / why we need it:
Mainly this PR contains:
PipedImageWatcherRepoTargettoPipedImageWatcherFilterso Piped config will be like:Also, currently the mutex is used for file locking. If we have to try to perform as fast as possible, I'd say it's preferable to have mutex for each repository. But premature optimization is the root of all evil. Let's use the same mutex for all file locking.
Which issue(s) this PR fixes:
Fixes #1210
Does this PR introduce a user-facing change?: