Skip to content

Conversation

@nakabonne
Copy link
Member

@nakabonne nakabonne commented Jan 13, 2021

What this PR does / why we need it:
Add Event watcher, a piped component that periodically fetches the latest Event from the eventstore to compare the value with one in the git repository.

Most core logic is borrowed from imagewatcher being already. And soon-to-be enables this as another PR.

Which issue(s) this PR fixes:

Ref #1381

Does this PR introduce a user-facing change?:

NONE

@pipecd-bot
Copy link
Collaborator

TODO

The following ISSUES will be created once got merged. If you want me to skip creating the issue, you can use /todo skip command.

Details

1. Retrieve the data from the control-plane.

https://github.com/pipe-cd/pipe/blob/ad24180b4169308cb0e93ba22aed22bb374ad145/pkg/app/piped/eventwatcher/eventwatcher.go#L201-L204

This was created by todo plugin since "FIXME:" was found in ad24180 when #1411 was merged. cc: @nakabonne.

Copy link
Collaborator

@pipecd-bot pipecd-bot left a comment

Choose a reason for hiding this comment

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

GO_LINTER

Some issues were detected while linting go source files in your changes.

@pipecd-bot
Copy link
Collaborator

COVERAGE

Code coverage for golang is 34.00%. This pull request decreases coverage by -0.06%.

File Function Base Head Diff
pkg/app/piped/cloudprovider/kubernetes/state.go determineRoleHealth -- 0.00% +0.00%
pkg/app/piped/cloudprovider/kubernetes/state.go determineRoleBindingHealth -- 0.00% +0.00%
pkg/app/piped/cloudprovider/kubernetes/state.go determineClusterRoleHealth -- 0.00% +0.00%
pkg/app/piped/cloudprovider/kubernetes/state.go determineClusterRoleBindingHealth -- 0.00% +0.00%
pkg/app/piped/cloudprovider/kubernetes/state.go determineResourceHealth 0.00% 0.00% +0.00%

@pipecd-bot
Copy link
Collaborator

COVERAGE

Code coverage for golang is 33.95%. This pull request does not change code coverage.

@nakabonne nakabonne marked this pull request as ready for review January 15, 2021 05:10
pipecd-bot pushed a commit that referenced this pull request Jan 15, 2021
**What this PR does / why we need it**:
This PR adds a new `apistore` for Events according to @nghialv 's [suggestion](#1410 (comment)). It allows us to reduce communication number by caching the latest events.

This will be used by #1411 at first.

**Which issue(s) this PR fixes**:

Ref #1381

**Does this PR introduce a user-facing change?**:
<!--
If no, just write "NONE" in the release-note block below.
-->
```release-note
NONE
```

This PR was merged by Kapetanios.
continue
}
// Put it into the change list.
newYml, err := yamlprocessor.ReplaceValue(yml, r.YAMLField, latestEvent.Data)
Copy link
Member

@nghialv nghialv Jan 15, 2021

Choose a reason for hiding this comment

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

In case the users configured multiple fields for the same file, will this override the old changes?

Copy link
Member Author

@nakabonne nakabonne Jan 15, 2021

Choose a reason for hiding this comment

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

Yes, that commit will happen conflict and end with failure.

Copy link
Member Author

@nakabonne nakabonne Jan 15, 2021

Choose a reason for hiding this comment

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

But I assumed it doesn't happen if the latest values are the same. It happens when only the latest values are different from each other.

Copy link
Member Author

Choose a reason for hiding this comment

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

Ah, I just got what you mean. No. it always override the original content, defined in Git.

Copy link
Member Author

Choose a reason for hiding this comment

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

All of my decisions are based on the rule that never makes a change that crosses lines, but you know what I mean?

Copy link
Member Author

Choose a reason for hiding this comment

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

Ah, I totally got what you're most worried about. Yes, you're right. That can revert previous changes. Let me re-think it.

Copy link
Member Author

Choose a reason for hiding this comment

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

I feel like we can simply solve it by editing a local file inside this loop.

Copy link
Member

Choose a reason for hiding this comment

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

Yes. That is what I was talking about.

Copy link
Member Author

@nakabonne nakabonne Jan 15, 2021

Choose a reason for hiding this comment

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

haha, finally I caught up.

I feel like we can simply solve it by editing a local file inside this loop.

I'm now inspecting if there are some issues with this way.

Copy link
Member Author

Choose a reason for hiding this comment

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

Looks like we have no problem with it, so applied it. PTAL 😄

@pipecd-bot
Copy link
Collaborator

COVERAGE

Code coverage for golang is 33.95%. This pull request does not change code coverage.

if err != nil {
return nil, fmt.Errorf("failed to replace value at %s with %s: %w", r.YAMLField, latestEvent.Data, err)
}
if err := ioutil.WriteFile(path, newYml, os.ModePerm); err != nil {
Copy link
Member

@nghialv nghialv Jan 15, 2021

Choose a reason for hiding this comment

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

I have just realized that we have to save it in memory instead of writing to the local path.
Because writing it back to the local path will cause an error while doing the next pulls ??
(The data inside the repo must be read-only.)

Copy link
Member

@nghialv nghialv Jan 15, 2021

Choose a reason for hiding this comment

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

So at line 215, checking it in the changes map before loading it from the local path looks good.

Copy link
Member Author

Choose a reason for hiding this comment

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

You are right! using cache looks good. Alternatively, I think we can leverage the temp repo because we use it when pushing. We can use it when making changes as well
https://github.com/pipe-cd/pipe/pull/1411/files#diff-60908ffb7e37bfc3692d8c4cace4be91d53bccf9a549fb91ea30b70387abd9cfR191

Copy link
Member Author

Choose a reason for hiding this comment

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

(Totally I misunderstood that we're using tmpRepo when making changes.)

Copy link
Member Author

@nakabonne nakabonne Jan 15, 2021

Choose a reason for hiding this comment

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

Hmm... using tmp repo makes the logic simple. But on the dark side, copying the directory happens every time no matter commits exists. After thinking about that, I'm beginning to think the way to check changes you suggested is more appropriate.

Copy link
Member

Choose a reason for hiding this comment

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

IMO, checking changes looks better.

Copy link
Member Author

Choose a reason for hiding this comment

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

Good. Let me do so.

Copy link
Member Author

@nakabonne nakabonne Jan 15, 2021

Choose a reason for hiding this comment

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

Hold on, I found it is still likely to be overwritten when processing other events. The changes is reset for each event. So looks like it's safer to use tmpRepo.

https://github.com/pipe-cd/pipe/pull/1411/files#diff-60908ffb7e37bfc3692d8c4cace4be91d53bccf9a549fb91ea30b70387abd9cfR170-R171

Copy link
Member

Choose a reason for hiding this comment

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

Right. lol. So let's update the local data. And please change the function name to match its new behavior.

Copy link
Member Author

Choose a reason for hiding this comment

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

Got it. The current one is absolutely not appropriate.

@nakabonne
Copy link
Member Author

Thanks to deeper discussion, maybe we have the best one. Could you take a look?

@pipecd-bot
Copy link
Collaborator

COVERAGE

Code coverage for golang is 33.95%. This pull request does not change code coverage.

@nghialv
Copy link
Member

nghialv commented Jan 15, 2021

Nice.
/lgtm

@nghialv
Copy link
Member

nghialv commented Jan 15, 2021

Let's merge this PR.
/approve

@pipecd-bot
Copy link
Collaborator

APPROVE

This pull request is APPROVED by nghialv.

Approvers can cancel the approval by writing /approve cancel in a comment. Any additional commits also will change this pull request to be not-approved.

@pipecd-bot pipecd-bot merged commit 4c66fbd into master Jan 15, 2021
@pipecd-bot pipecd-bot deleted the event-watcher branch January 15, 2021 13:19
@khanhtc1202
Copy link
Member

ops, sorry I have not noticed this PR 🙇‍♂️

@nghialv
Copy link
Member

nghialv commented Jan 15, 2021

@khanhtc1202 No problem. I just want to merge it for a nice weekend. lol.

@khanhtc1202
Copy link
Member

khanhtc1202 commented Jan 15, 2021

Have a nice weekend! 😂

@nakabonne
Copy link
Member Author

Thank you both of you. It's going to make for a good weekend 😃

@nghialv
Copy link
Member

nghialv commented Jan 15, 2021

Have a nice weekend. 🏃‍♂️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants