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

Encapsulate Recover of controllers #1014

Merged
merged 23 commits into from
Jan 6, 2021

Conversation

Yiyiyimu
Copy link
Member

@Yiyiyimu Yiyiyimu commented Oct 2, 2020

Signed-off-by: yiyiyimu wosoyoung@gmail.com

What problem does this PR solve?

fix #961, currently only encapsulate chaos w/o managers.

What is changed and how does it work?

Add a common CleanFinalizersAndRecover which implemented for a new struct.

Checklist

Tests

  • Unit test
  • E2E test
  • Manual test (add detailed scripts or steps below)
  • No code

Does this PR introduce a user-facing change?

NONE

Signed-off-by: yiyiyimu <wosoyoung@gmail.com>
@Yiyiyimu Yiyiyimu changed the title [WIP] Encapsulate Recover of controllers Encapsulate Recover of controllers Oct 2, 2020
Signed-off-by: yiyiyimu <wosoyoung@gmail.com>
@Yiyiyimu
Copy link
Member Author

Yiyiyimu commented Oct 2, 2020

It would be a bit hard for encapsulation for controllers with managers, like IoChaos and NetworkChaos. They are quite similar but still there is some chaos-specific logic, for example #788 and #892 is made for networkChaos only.

Actually I'm not so sure if it would be a good idea to encapsulate this part.
Not like api which every chaos type has the same API, encapsulating code here might make it hard to implement a change of certain chaos type, like the PR I listed. But I'm not sure about this inference, maybe certain change could work on different types but right now only one type is changed, so encapsulation would make it effective. @YangKeao Could you give me some suggestions?

No that does not effect the encapsulation, #788 didn't make difference, and the difference resulting from #892 is coming from only change one of managers but forget the other one.

@Yiyiyimu Yiyiyimu changed the title Encapsulate Recover of controllers [WIP] Encapsulate Recover of controllers Oct 2, 2020
@YangKeao
Copy link
Member

Maybe I should also try to make a subresourcemanager to replace podiochaosmanager and podnetworkchaosmanager... But these changes are blocked until #940 get merged. The code generator in #940 could provide a more convinient way to add getter and setter, and obviously I need SetName, SetNamespace in subresourcemanager 😢 .

@Yiyiyimu
Copy link
Member Author

Maybe I should also try to make a subresourcemanager to replace podiochaosmanager and podnetworkchaosmanager... But these changes are blocked until #940 get merged. The code generator in #940 could provide a more convinient way to add getter and setter, and obviously I need SetName, SetNamespace in subresourcemanager 😢 .

Sure I think we could wait until that time to update this part

Signed-off-by: yiyiyimu <wosoyoung@gmail.com>
Signed-off-by: yiyiyimu <wosoyoung@gmail.com>
Signed-off-by: yiyiyimu <wosoyoung@gmail.com>
@Yiyiyimu Yiyiyimu changed the title [WIP] Encapsulate Recover of controllers Encapsulate Recover of controllers Nov 28, 2020
Signed-off-by: yiyiyimu <wosoyoung@gmail.com>
@codecov-io
Copy link

codecov-io commented Nov 28, 2020

Codecov Report

Merging #1014 (ea13fca) into master (7e9ff3f) will decrease coverage by 3.62%.
The diff coverage is 52.77%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #1014      +/-   ##
==========================================
- Coverage   55.78%   52.15%   -3.63%     
==========================================
  Files          68       78      +10     
  Lines        4383     4918     +535     
==========================================
+ Hits         2445     2565     +120     
- Misses       1768     2095     +327     
- Partials      170      258      +88     
Impacted Files Coverage Δ
api/v1alpha1/common_types.go 0.00% <0.00%> (ø)
api/v1alpha1/common_webhook.go 100.00% <ø> (ø)
api/v1alpha1/dnschaos_type.go 0.00% <0.00%> (ø)
api/v1alpha1/dnschaos_webhook.go 0.00% <0.00%> (ø)
api/v1alpha1/httpchaos_types.go 0.00% <0.00%> (ø)
api/v1alpha1/iochaos_types.go 0.00% <ø> (-40.00%) ⬇️
api/v1alpha1/jvmchaos_webhook.go 0.00% <0.00%> (ø)
api/v1alpha1/kernelchaos_types.go 0.00% <ø> (-20.00%) ⬇️
api/v1alpha1/kernelchaos_webhook.go 100.00% <ø> (+14.81%) ⬆️
api/v1alpha1/kinds.go 27.27% <ø> (+0.60%) ⬆️
... and 128 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0f817aa...ea13fca. Read the comment docs.

@Yiyiyimu
Copy link
Member Author

Hi @YangKeao is the current implementation what we want

@Yiyiyimu
Copy link
Member Author

/run-e2e-tests

Signed-off-by: yiyiyimu <wosoyoung@gmail.com>
Signed-off-by: yiyiyimu <wosoyoung@gmail.com>
@Yiyiyimu
Copy link
Member Author

Hi @YangKeao PTAL

@YangKeao
Copy link
Member

Actually, I don't think generating all codes through a generator is a good idea. Only small parts of them (such as some getter or setter) should be done by code generation.

We can analyze the problem like this:

To implement Recover, we require an endpoint with cleanFinalizersAndRecover and Event methods. To implement cleanFinalizersAndRecover for an endpoint, we need a getter and setter for the Finalizers, a Client, and the most important part: recoverPod.

Only some of these requirements should be generated through the code generator (e.g. the Finalizers getter and setter for the custom resource).

@Yiyiyimu
Copy link
Member Author

Yeah it's actually also weird for me, to "generate" this large block of code that contains some logic. But since we could easily get/set finalizer so just only generate this part could not remove much duplicated code.

I have another idea (still a bit weird) that to build a common cleanFinalizersAndRecover, in which pass the endpoint as an argument (don't know if it is plausible), it could be like

func (e *endpoint) Recover(ctx context.Context, req ctrl.Request, chaos v1alpha1.InnerObject) error {
	stressChaos, ok := chaos.(*v1alpha1.StressChaos)
	finalizers, err := cleanFinalizersAndRecover(ctx, e, chaos, stressChaos.Finalizers, stressChaos.Annotations[common.AnnotationCleanFinalizer])
	stressChaos.Finalizers = finalizers
}
// the common one
func cleanFinalizersAndRecover(ctx context.Context, e *endpoint, chaos v1alpha1.InnerObject, finalizers []string, forceClean string) error {
	...
	err = e.recoverPod(ctx, &pod, chaos)
	...
}
// do another type assertion in recoverPod
func (e *endpoint) recoverPod(ctx context.Context, pod *v1.Pod, chaos *v1alpha1.StressChaos) error {
	stressChaos, ok := chaos.(*v1alpha1.StressChaos)
	...
}

@YangKeao
Copy link
Member

YangKeao commented Dec 17, 2020

@Yiyiyimu We can ignore the *manager part temporarily and encapsulate others first.

A straightforward plan could be defining a trait RecoverPod (maybe you can pick a better name), which contains one RecoverPod function.

And automatically implement cleanFinalizersAndRecover for all these traits. However, you cannot impl<T: IRecoverPod> ICleanFinalizers for T in go. But you can construct a new RecoverDelegate struct whose only field is a RecoverPod interface. Than implement Recover and cleanFinalizersAndRecover for this RecoverDelegate struct.

But how to combine it with Apply method still needs consideration. I don't know much about how to write elegant code with such a lack of language features 😭 .

Signed-off-by: yiyiyimu <wosoyoung@gmail.com>
Signed-off-by: yiyiyimu <wosoyoung@gmail.com>
Signed-off-by: yiyiyimu <wosoyoung@gmail.com>
Signed-off-by: yiyiyimu <wosoyoung@gmail.com>
Signed-off-by: yiyiyimu <wosoyoung@gmail.com>
@Yiyiyimu
Copy link
Member Author

@cwen0 it seems the test goes stable now. PTAL

@Yiyiyimu
Copy link
Member Author

Hi @cwen0 @YangKeao could we review this pr at a faster speed? There are so many times files got conflicts.

Signed-off-by: yiyiyimu <wosoyoung@gmail.com>
Signed-off-by: yiyiyimu <wosoyoung@gmail.com>
@cwen0
Copy link
Member

cwen0 commented Dec 29, 2020

Hi @cwen0 @YangKeao could we review this pr at a faster speed? There are so many times files got conflicts.

Sorry for our late reply. I will review this pr ASAP.

Copy link
Member

@cwen0 cwen0 left a comment

Choose a reason for hiding this comment

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

Rest LGTM


func (r *endpoint) recoverPod(ctx context.Context, pod *v1.Pod) error {
r.Log.Info("Try to recover pod", "namespace", pod.Namespace, "name", pod.Name)
r.cancelDNSServerRules(service.Spec.ClusterIP, config.ControllerCfg.DNSServicePort, chaos.Name)
Copy link
Member

Choose a reason for hiding this comment

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

We don't need to run this function in each pod.

Copy link
Member Author

Choose a reason for hiding this comment

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

Fixed. Thanks!

controllers/networkchaos/partition/types.go Show resolved Hide resolved
Signed-off-by: yiyiyimu <wosoyoung@gmail.com>
Copy link
Member

@cwen0 cwen0 left a comment

Choose a reason for hiding this comment

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

LGTM

@cwen0
Copy link
Member

cwen0 commented Jan 6, 2021

@YangKeao PTAL

Copy link
Member

@YangKeao YangKeao left a comment

Choose a reason for hiding this comment

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

LGTM

@YangKeao
Copy link
Member

YangKeao commented Jan 6, 2021

/merge

@ti-srebot
Copy link
Contributor

/run-all-tests

@ti-srebot
Copy link
Contributor

@Yiyiyimu merge failed.

@YangKeao
Copy link
Member

YangKeao commented Jan 6, 2021

/merge

@ti-srebot
Copy link
Contributor

/run-all-tests

@ti-srebot
Copy link
Contributor

@Yiyiyimu merge failed.

@WangXiangUSTC
Copy link
Contributor

/run-e2e-tests

@YangKeao
Copy link
Member

YangKeao commented Jan 6, 2021

/merge

@ti-srebot
Copy link
Contributor

Your auto merge job has been accepted, waiting for:

  • 1360

@ti-srebot
Copy link
Contributor

/run-all-tests

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.

Encapsulate multi-pod chaos
6 participants