Skip to content

[Federation] Update hpa e2e utils to enable reuse in fed hpa tests#51277

Merged
k8s-github-robot merged 2 commits intokubernetes:masterfrom
irfanurrehman:hpa-e2e-mod-for-fed
Sep 21, 2017
Merged

[Federation] Update hpa e2e utils to enable reuse in fed hpa tests#51277
k8s-github-robot merged 2 commits intokubernetes:masterfrom
irfanurrehman:hpa-e2e-mod-for-fed

Conversation

@irfanurrehman
Copy link
Copy Markdown

This PR is to enable reuse of some hpa e2e utils in federation, facilitating #50168
cc @mwielgus @quinton-hoole
cc @kubernetes/sig-federation-pr-reviews

Release note:

@k8s-ci-robot k8s-ci-robot added sig/federation cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. labels Aug 24, 2017
@k8s-github-robot k8s-github-robot added size/M Denotes a PR that changes 30-99 lines, ignoring generated files. release-note-none Denotes a PR that doesn't merit a release note. labels Aug 24, 2017
@irfanurrehman
Copy link
Copy Markdown
Author

/sig federation
/assign @quinton-hoole
/assign @mwielgus
/unassign @spiffxp

@k8s-ci-robot k8s-ci-robot assigned mwielgus and ghost and unassigned spiffxp Aug 24, 2017
func NewDynamicResourceConsumer(name, kind string, replicas, initCPUTotal, initMemoryTotal, initCustomMetric int, cpuLimit, memLimit int64, f *framework.Framework) *ResourceConsumer {
return newResourceConsumer(name, kind, replicas, initCPUTotal, initMemoryTotal, initCustomMetric, dynamicConsumptionTimeInSeconds,
dynamicRequestSizeInMillicores, dynamicRequestSizeInMegabytes, dynamicRequestSizeCustomMetric, cpuLimit, memLimit, f)
func NewDynamicResourceConsumer(name, nsName, kind string, replicas, initCPUTotal, initMemoryTotal, initCustomMetric int, cpuLimit, memLimit int64, clientset clientset.Interface, internalClientset *internalclientset.Clientset) *ResourceConsumer {
Copy link
Copy Markdown

Choose a reason for hiding this comment

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

I don't really like the idea of flattening the Framework parameter and passing the individual clientsets instead. Can you convince me otherwise?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

The use of framework here is to consume only the cluster clientset, cluster internalclientset and namespace. The resource consumer, the controller rc that controls the resource consumer and communications across using local service discovery, need only these 3 for their correct functioning. The e2e framework, however has hell a lot many things, including loggers, piping/redirection of stuff, their own beforeeach/aftereach (and many more things I did not explore). The fw we create and use in fed e2e tests is the extention of the e2e fw with subtle differences (for example it stores fed clientset, and clientsets for all clusters). The easier way for me to reuse these rc utils to drive the fed test was to create the resource consumer directly into the specific cluster, I want the utilisation driven into and create a matching object (deployment/rs) in federation to control the distribution. I did explore creating a dummy fw with only the cluster clientset, cluster internalclientset and namespace for that particular cluster set, and use that instead (rather then flattening it); but was afraid of some inbuilt suff on that fw (for example beforeeach/aftereach) interfering with the actual fed e2e fw which is used to drive the fed e2e test.
Meanwhile, I think using the dummy fw, as mentioned above might work here, however, this somehow felt the right way to make these utils not really depend on it.

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

OK, fair enough. I accept your argument. Given that, the rest of the PR LGTM.

controllerName: name + "-ctrl",
kind: kind,
framework: f,
nsName: nsName,
Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Can you explain why you decided to do this? Is it because Federation e2e tests don't use Framework? If that is the case, it seems better to fix that instead?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

As above.

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

OK.

@ghost ghost added this to the v1.8 milestone Aug 28, 2017
@ghost
Copy link
Copy Markdown

ghost commented Aug 28, 2017

/lgtm

Would anyone in @kubernetes/sig-autoscaling-pr-reviews like to take a quick look at this? Seems pretty uncontentious to me. If I don't hear any objections in the next few days, I'd like to get this merged in time for v1.8.

@k8s-ci-robot k8s-ci-robot added lgtm "Looks good to me", indicates that a PR is ready to be merged. sig/autoscaling Categorizes an issue or PR as relevant to SIG Autoscaling. labels Aug 28, 2017
@dims
Copy link
Copy Markdown
Member

dims commented Sep 4, 2017

/test all

@dims
Copy link
Copy Markdown
Member

dims commented Sep 4, 2017

/retest

1 similar comment
@irfanurrehman
Copy link
Copy Markdown
Author

/retest

@DirectXMan12
Copy link
Copy Markdown
Contributor

Would anyone in @kubernetes/sig-autoscaling-pr-reviews like to take a quick look

I will. Seems pretty reasonable to me.

/lgtm

@ghost
Copy link
Copy Markdown

ghost commented Sep 13, 2017

/approve no-issue

@ghost
Copy link
Copy Markdown

ghost commented Sep 13, 2017

/assign @madhusudancs

@ghost
Copy link
Copy Markdown

ghost commented Sep 15, 2017

/test pull-kubernetes-e2e-gce-bazel

@dims
Copy link
Copy Markdown
Member

dims commented Sep 19, 2017

/retest

1 similar comment
@dims
Copy link
Copy Markdown
Member

dims commented Sep 19, 2017

/retest

@spiffxp
Copy link
Copy Markdown
Contributor

spiffxp commented Sep 20, 2017

/approve no-issue
given the approvals and lgtms above

@k8s-github-robot
Copy link
Copy Markdown

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: DirectXMan12, irfanurrehman, quinton-hoole, spiffxp

Associated issue requirement bypassed by: spiffxp

The full list of commands accepted by this bot can be found here.

Details Needs approval from an approver in each of these OWNERS Files:

You can indicate your approval by writing /approve in a comment
You can cancel your approval by writing /approve cancel in a comment

@k8s-github-robot k8s-github-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Sep 20, 2017
@k8s-github-robot
Copy link
Copy Markdown

/test all [submit-queue is verifying that this PR is safe to merge]

@k8s-github-robot
Copy link
Copy Markdown

Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions here..

@k8s-github-robot k8s-github-robot merged commit f7dd62f into kubernetes:master Sep 21, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by an approver from all required OWNERS files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. lgtm "Looks good to me", indicates that a PR is ready to be merged. release-note-none Denotes a PR that doesn't merit a release note. sig/autoscaling Categorizes an issue or PR as relevant to SIG Autoscaling. size/M Denotes a PR that changes 30-99 lines, ignoring generated files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants