profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/jingxu97/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Jing Xu jingxu97 Google Mountain View, CA

jingxu97/cloud-builders-community 0

Community-contributed images for Google Cloud Build

jingxu97/cluster-api 0

Home for the Cluster Management API work, a subproject of sig-cluster-lifecycle

jingxu97/code-generator 0

Generators for kube-like API types

jingxu97/community 0

Kubernetes community content

jingxu97/csi-driver-host-path 0

A sample (non-production) CSI Driver that creates a local directory as a volume on a single node

jingxu97/csi-driver-smb 0

This driver allows Kubernetes to use SMB CSI volume on both Linux and Windows nodes.

jingxu97/csi-proxy 0

CSI Proxy utility to enable CSI Plugins on Windows

jingxu97/csi-test 0

CSI test frameworks

jingxu97/docs 0

Documentation for CSI integration with Kubernetes

jingxu97/enhancements 0

Features tracking repo for Kubernetes releases

issue commentkubernetes/kubernetes

Proxy healthz start failure after node CRI maintenance

/triage not-reproducible

If someone can repro this, then we can look at fixing it but thus far we have been unable. Will close if we cannot reproduce.

martinstraesser

comment created time in a few seconds

Pull request review commentkubernetes/kubernetes

Add score func for NodeResourcesFit plugin

 type NodeResourcesFitArgs struct { 	// A resource group name can't contain '/'. 	// +listType=atomic 	IgnoredResourceGroups []string `json:"ignoredResourceGroups,omitempty"`++	// ScoringStrategy selects the node resource scoring strategy.+	// +listType=atomic+	ScoringStrategy *ScoringStrategy `json:"scoringStrategy,omitempty"`

it would be confusing to users, we allow it but does nothing.

yuzhiquan

comment created time in a minute

issue commentkubernetes/kubernetes

TOB-K8S-021: Improper fetching of PIDs allows incorrect cgroup movement

/triage accepted /priority important-longterm

cji

comment created time in 2 minutes

Pull request review commentkubernetes/kubernetes

Add score func for NodeResourcesFit plugin

 type NodeResourcesFitArgs struct { 	// A resource group name can't contain '/'. 	// +listType=atomic 	IgnoredResourceGroups []string `json:"ignoredResourceGroups,omitempty"`++	// ScoringStrategy selects the node resource scoring strategy.+	// +listType=atomic+	ScoringStrategy *ScoringStrategy `json:"scoringStrategy,omitempty"`

It's fine to allow it. The plugin would just return immediately because there is no strategy set. I don't think it's worth the custom validation.

yuzhiquan

comment created time in 2 minutes

pull request commentkubernetes/kubernetes

Automated cherry pick of #93250: Handle int -> float conversion in FromUnstructured

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: <a href="https://github.com/kubernetes/kubernetes/pull/103105#" title="Author self-approved">liggitt</a>, <a href="https://github.com/kubernetes/kubernetes/pull/103105#issuecomment-867841414" title="Approved">roycaihw</a>, <a href="https://github.com/kubernetes/kubernetes/pull/103105#pullrequestreview-692083824" title="Approved">xmudrii</a>

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

The pull request process is described here

<details > Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment Approvers can cancel approval by writing /approve cancel in a comment </details> <!-- META={"approvers":[]} -->

liggitt

comment created time in 2 minutes

pull request commentkubernetes/kubernetes

Update mounter interface in volume manager

/priority important-soon

jsafrane

comment created time in 3 minutes

pull request commentkubernetes/kubernetes

Update mounter interface in volume manager

/hold cancel

jsafrane

comment created time in 3 minutes

issue commentkubernetes/kubernetes

Restarting containerd (and kubelet) does not impact "runtime" startTime in summary API

it looks like this was a cadvisor bug that had activity in https://github.com/google/cadvisor/pull/2800

if that's resolved the issue, can we use this to track when the fixed cadvisor version is included in k/k?

/cc @bobbypage

karan

comment created time in 4 minutes

pull request commentkubernetes/kubernetes

Remove MPL-licensed dep from lruexpirecache

@liggitt this is ready now!

ahmedtd

comment created time in 5 minutes

issue commentkubernetes/kubernetes

Excessive disk writes after enabling CPUManager

/triage accepted

/cc @fromanirh @swatisehgal @cynepco3hahue

SaveTheRbtz

comment created time in 5 minutes

issue commentkubernetes/kubernetes

Restarting containerd (and kubelet) does not impact "runtime" startTime in summary API

The runtime metrics are supposed to be metrics for the container runtime itself. This is related to the ability to monitor container runtime health, not saying that all containers should have been restarted.

karan

comment created time in 6 minutes

pull request commentkubernetes/kubernetes

Recover from volume expansion failure

@gnufied: The following test failed, say /retest to rerun all failed tests:

Test name Commit Details Rerun command
pull-kubernetes-e2e-gce-ubuntu-containerd fc83569b3689d456a6ab99f30161f0858988a032 link /test pull-kubernetes-e2e-gce-ubuntu-containerd

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

<details>

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. </details> <!-- test report -->

gnufied

comment created time in 6 minutes

issue commentkubernetes/kubernetes

Kubelet restarts due to concurrent map read and write

@ehashman: This request has been marked as needing help from a contributor.

Please ensure the request meets the requirements listed here.

If this request no longer meets these requirements, the label can be removed by commenting with the /remove-help command.

<details>

In response to this:

/remove-lifecycle stale

I think we should try to backport a targeted fix that just fixes the panic in 1.19 (1.18 unfortunately isn't supported anymore).

/triage accepted /help

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. </details>

sseetharaman6

comment created time in 6 minutes

issue commentkubernetes/kubernetes

Kubelet restarts due to concurrent map read and write

/remove-lifecycle stale

I think we should try to backport a targeted fix that just fixes the panic in 1.19 (1.18 unfortunately isn't supported anymore).

/triage accepted /help

sseetharaman6

comment created time in 6 minutes

Pull request review commentkubernetes/enhancements

KEP 2527: Clarify meaning of `status`

+# KEP-2527: Clarify if/how controllers can use status to track non-observable state++<!-- toc -->+- [Release Signoff Checklist](#release-signoff-checklist)+- [Summary](#summary)+- [Motivation](#motivation)+  - [Goals](#goals)+  - [Non-Goals](#non-goals)+- [Proposal](#proposal)+  - [User Stories (Optional)](#user-stories-optional)+    - [Story 1](#story-1)+    - [Story 2](#story-2)+  - [Notes/Constraints/Caveats (Optional)](#notesconstraintscaveats-optional)+  - [Risks and Mitigations](#risks-and-mitigations)+- [Design Details](#design-details)+  - [Test Plan](#test-plan)+  - [Graduation Criteria](#graduation-criteria)+  - [Upgrade / Downgrade Strategy](#upgrade--downgrade-strategy)+  - [Version Skew Strategy](#version-skew-strategy)+- [Production Readiness Review Questionnaire](#production-readiness-review-questionnaire)+  - [Feature Enablement and Rollback](#feature-enablement-and-rollback)+  - [Rollout, Upgrade and Rollback Planning](#rollout-upgrade-and-rollback-planning)+  - [Monitoring Requirements](#monitoring-requirements)+  - [Dependencies](#dependencies)+  - [Scalability](#scalability)+  - [Troubleshooting](#troubleshooting)+- [Implementation History](#implementation-history)+- [Drawbacks](#drawbacks)+- [Alternatives](#alternatives)+- [Infrastructure Needed (Optional)](#infrastructure-needed-optional)+<!-- /toc -->++## Release Signoff Checklist++Items marked with (R) are required *prior to targeting to a milestone / release*.++- [ ] (R) Enhancement issue in release milestone, which links to KEP dir in [kubernetes/enhancements] (not the initial KEP PR)+- [ ] (R) KEP approvers have approved the KEP status as `implementable`+- [ ] (R) Design details are appropriately documented+- [ ] (R) Test plan is in place, giving consideration to SIG Architecture and SIG Testing input+- [ ] (R) Graduation criteria is in place+- [ ] (R) Production readiness review completed+- [ ] (R) Production readiness review approved+- [ ] "Implementation History" section is up-to-date for milestone+- [ ] User-facing documentation has been created in [kubernetes/website], for publication to [kubernetes.io]+- [ ] Supporting documentation—e.g., additional design documents, links to mailing list discussions/SIG meetings, relevant PRs/issues, release notes++[kubernetes.io]: https://kubernetes.io/+[kubernetes/enhancements]: https://git.k8s.io/enhancements+[kubernetes/kubernetes]: https://git.k8s.io/kubernetes+[kubernetes/website]: https://git.k8s.io/website++## Summary++Since basically the beginning of Kubernetes, we've had this sort of "litmus+test" for status fields: "If I erased the whole status struct, would everything+in it be reconstructed (or at least be reconstructible) from observation?". The+goal was to ensure that the delineation between "what I asked for" and "what it+actually is" was clear and to encourage active reconciliation of state.++Another reason for this split was an idea which, as far as I know, has never+been implemented by anyone: that an object's spec and status blocks could be+stored in different etcd instances and the status could have a TTL.  At this+point in the project, I expect that wiping status out like this would end in+fireworks, and not the fun kind.  Status is, effectively, as durable as spec.++Many of our APIs pass this test (sometimes we fudge it and say yes "in+theory"), but not all of them do.  This KEP proposes to clarify or remove this+guidance, especially as it pertains to state that is not derived from+observation.++One of the emergent uses of the spec/status split is access control.  It is+assumed that, for most resources, users own (can write to) all of spec and+controllers own all of status, and not the reverse.  This allows patterns like+Services which set `spec.type: LoadBalancer`, where the controller writes the+LB's IP address to status, and kube-proxy can trust that IP address (because it+came from a controller, not a user).  Compare that with Services which use+`spec.externalIPs`.  The behavior in kube-proxy is roughly the same, but+because non-trusted users can write to `spec.externalIPs` and that does not+require a trusted controller to ACK, that behavior was declared a CVE.++This KEP further proposes to add guidance for APIs that want to implement an+"allocation" or "binding" pattern which requires trusted ACK.++## Motivation++As an API reviewer, I have seen many different patterns in use.  I have shot+down APIs that run afoul of the rebuild-from-observation test, and forced the+implementations to be more complicated.  I no longer find this to be useful to+our APIs, and in fact I find it to be a detriment.++I suspect that several APIs would have come out differently if not for this.++### Goals++* Clarify or remove the from-observation rule to better match reality.+* Provide guidance for APIs on how to save controller results.++### Non-Goals++* Retroactively apply this pattern to change existing GA APIs.+* Necessarily apply this pattern to change pre-GA APIs (though they may choose+  to follow it).+* Provide arbitrary storage for controller state.+* Provide distinct access control for subsets of spec or status.++## Proposal++This KEP proposes to:++1) Get rid of the [if it got lost](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)+litmus test for status fields+2) Acknowledge that spec/status are a useful and meaningful split for access control+3) Document one or more patterns for APIs that need a trusted acknowledgement+   of the spec++Depending on feedback, there may be other approaches to solving the same+problems.++### Risks and Mitigations++The current guidance exists for a reason.  It does encourage a sort of+idealogical cleanliness.  However, it is not universally adhered to and it+neglects the reality of these request/acknowledge APIs.  On the whole, this KEP+posits that the current guidance is a net negative.++## Design Details++<<[UNRESOLVED ideas to debate]>>++### Option 1: Loosen status++Remove the idea that status fields _must_ be from observation.  Allow controllers+to write values to status that represent allocations or acknowledged requests.+Document that status fields are best when they represent observed state, but do+not _require_ it.++This has [already happened](https://github.com/kubernetes/enhancements/pull/2308/files#r567809465)+at least once.++#### Examples++Some of these are variants of existing APIs and some are hypothetical.++1) User creates a Service and sets `Service.spec.type = LoadBalancer`.  The+cloud controller sets `Service.status.loadBalancer.ingress.ip` in response.  If+the user sets `Service.spec.loadBalancerIP` to a specific value, the cloud+controller will either successfully use that IP and and set it as before (ACK),+or it will not set any value in `Service.status.loadBalancer.ingress` (NAK).++2) Given a Pod, user patches `Pod.spec.containers[0].resources.requests[cpu]`+to a new value.  Kubelet sees this as a request and, if viable, sets+`Pod.status.containerStatuses[0].resources.requests[cpu]` to the same value.++3) User creates a `Bucket`, setting `Bucket.spec.instance = artifacts-prod`.+The bucket controller verifies that the namespace is allowed to use the+artifacts-prod bucket and, if so, sets `Bucket.status.instance` to the same+value.++#### Tradeoffs++Pro: Easy and compatible with existing uses.++Con: Dilutes the meaning of status.++### Option 2: Add a new top-level stanza to spec/status resources++Keep and strengthen the idea that status fields must be from observation.+Segregate controller-owned fields to a new stanza, parallel to `spec` and+`status`, which can be RBAC'ed explicitly.  For the sake of this doc, let's+call it `control`.++To make this viable, we would need to add `control` as a "standard" subresource+and apply similar rules to `spec` and `status` with regards to writes (can't+write to `control` through the main resource, can't write to `spec` or `status`+through the `control` subresource).  We would also need to add it to CRDs as an+available subresource.++#### Examples++1) User creates a Service and sets `Service.spec.type = LoadBalancer`.  The+cloud controller sets `Service.control.loadBalancer.ingress.ip` in response.  If+the user sets `Service.spec.loadBalancerIP` to a specific value, the cloud+controller will either successfully use that IP and and set it as before (ACK),+or it will not set any value in `Service.control.loadBalancer.ingress` (NAK).++2) Given a Pod, user patches `Pod.spec.containers[0].resources.requests[cpu]`+to a new value.  Kubelet sees this as a request and, if viable, sets+`Pod.control.containerStatuses[0].resources.requests[cpu]` to the same value.++3) User creates a `Bucket`, setting `Bucket.spec.instance = artifacts-prod`.+The bucket controller verifies that the namespace is allowed to use the+artifacts-prod bucket and, if so, sets `Bucket.control.instance` to the same+value.++#### Tradeoffs++Pro: Clarifies the meaning of status.++Pro: Possibly clarifies the roles acting on a resource.++Con: Requires a lot of implentation and possibly steps on existing uses of the+field name.++Con: Net-new concept requires new documentation and socialization.++Con: Incompatible with existing uses of status for this.++### Option 3: Sub-divide spec++Keep and strengthen the idea that status fields must be from observation.+Segregate controller-owned fields to a sub-stanza of spec.  Create a new+access-control mechanism (or extend RBAC) to provide field-by-field access.++#### Examples++1) User creates a Service and sets `Service.spec.type = LoadBalancer`.  The+cloud controller sets `Service.spec.control.loadBalancer.ingress.ip` in+response.  If the user sets `Service.spec.loadBalancerIP` to a specific value,+the cloud controller will either successfully use that IP and and set it as+before (ACK), or it will not set any value in+`Service.spec.control.loadBalancer.ingress` (NAK).++2) Given a Pod, user patches `Pod.spec.containers[0].resources.requests[cpu]`+to a new value.  Kubelet sees this as a request and, if viable, sets+`Pod.spec.control.containerStatuses[0].resources.requests[cpu]` to the same+value.++3) User creates a `Bucket`, setting `Bucket.spec.instance = artifacts-prod`.+The bucket controller verifies that the namespace is allowed to use the+artifacts-prod bucket and, if so, sets `Bucket.spec.control.instance` to the same+value.++#### Tradeoffs++Pro: Retains purity of status.++Con: Confuses the meaning of spec.++Con: Can collide with existing uses of the field name.++Con: Needs a whole new access model.++Con: Likely needs a new subresource.++#### Notes++This model is included for completeness.  I do not expect ANYONE to endorse it.++### Option 4: Use 2 objects++Keep and strengthen the idea that status fields must be from observation.+Segregate controller-owned fields to a new object, parallel to the user-owned+object.  RBAC the new object.++#### Examples++1) User creates a Service "foo" and sets `Service.spec.type = LoadBalancer`.+The cloud controller creates a new ServiceLoadBalancer object "foo" and sets+`ServiceLoadBalancer.ingress.ip` in response.  If the user sets+`Service.spec.loadBalancerIP` to a specific value, the cloud controller will+either successfully use that IP and and set it as before (ACK), or it will+create a ServiceLoadBalancer object with an error status (NAK).++2) Given a pod "foo", user patches+`Pod.spec.containers[0].resources.requests[cpu]` to a new value.  Kubelet sees+this as a request and, if viable, updates the matching PodResources object+"foo", setting `PodResources.requests[cpu]` to the same value.++3) User creates a `Bucket`, setting `Bucket.spec.instance = artifacts-prod`.+The bucket controller verifies that the namespace is allowed to use the+artifacts-prod bucket and, if so, creates a new BucketBinding object which sets+`BucketBinding.instance` to the same value.++#### Tradeoffs++Pro: RBAC is clear.++Pro: Different controllers can be RBAC'ed to different result-kinds.++Con: Proliferation of many small objects, lifecycle management.++Con: Results are not always 1:1 with user objects (e.g. a Service can have N+ports, each needs a NodePort allocation).++Con: More watch streams overall (but less traffic on each).++Pro: Feels natural for things like Buckets.++Con: Feels clumsy for things like Pod resources.++Pro: Third-party controllers can follow the same pattern for non-standard+results.++#### Notes++Even if we ultimately adopt option 1, 2, or 3, option 4 may still be a better+answer, depending on the particular design.+

I guess I am not arguing NOT to use conditions when that makes sense, just that the use of status (proper) should also be allowed for common-case needs.

thockin

comment created time in 7 minutes

IssuesEvent

pull request commentkubernetes/kubernetes

Remove MPL-licensed dep from lruexpirecache

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: <a href="https://github.com/kubernetes/kubernetes/pull/95472#" title="Author self-approved">ahmedtd</a>, <a href="https://github.com/kubernetes/kubernetes/pull/95472#issuecomment-867847348" title="LGTM">dims</a> To complete the pull request process, please ask for approval from liggitt after the PR has been reviewed.

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

<details open> Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment Approvers can cancel approval by writing /approve cancel in a comment </details> <!-- META={"approvers":["liggitt"]} -->

ahmedtd

comment created time in 8 minutes

pull request commentkubernetes/kubernetes

Remove MPL-licensed dep from lruexpirecache

New changes are detected. LGTM label has been removed.

ahmedtd

comment created time in 8 minutes

Pull request review commentkubernetes/kubernetes

allow scheduler to update pod conditions when imagePullSecrets have no name field

 func updatePod(client clientset.Interface, pod *v1.Pod, condition *v1.PodConditi 	if nominatedNode != "" { 		podCopy.Status.NominatedNodeName = nominatedNode 	}+	// See issue: #94626. This is to handle the case with empty name field in spec.ImagePullSecrets+	// which is also the patchMergeKey and would fail the two-way merge patch generation and prevent scheduler from updating+	// the pod conditions+	var pullSecrets []v1.LocalObjectReference

Thanks for the context (#94626)

PatchPod is within the scheduler package, so it might be fine to do changes there. The scheduler is only concerned very few things, in terms of patching: conditions and nominated nodename, both part of the status.

I think a better alternative is to do some kind of allow list: instead of doing a DeepCopy of the entire pod, we just do it for the status. And we use the statuses for the creating the patch. Then, you probably have to add some extra formatting to create the Pod patch.

marwanad

comment created time in 8 minutes

issue commentkubernetes/kubernetes

Restarting containerd (and kubelet) does not impact "runtime" startTime in summary API

@ehashman: Closing this issue.

<details>

In response to this:

What happened: Containerd (and optionally the kubelet) was restarted.

What you expected to happen: runtime's startTime should be the restart time.

I would not this expect this to happen because restarting containerd should not restart containers. The data plane should be resilient to control plane failures.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. </details>

karan

comment created time in 8 minutes

issue closedkubernetes/kubernetes

Restarting containerd (and kubelet) does not impact "runtime" startTime in summary API

<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks!

If the matter is security related, please disclose it privately via https://kubernetes.io/security/ -->

What happened: Containerd (and optionally the kubelet) was restarted.

What you expected to happen: runtime's startTime should be the restart time.

$ curl -s localhost:10255/stats/summary | grep -i runtime -A 2
    "name": "runtime",
    "startTime": "2021-01-22T01:29:09Z",
    "cpu": {

How to reproduce it (as minimally and precisely as possible):

# Note the current startTime
$ curl -s localhost:10255/stats/summary | grep -i runtime -A 2

# Restart containerd
$ sudo systemctl restart containerd

# Note the current startTime
$ curl -s localhost:10255/stats/summary | grep -i runtime -A 2

I would expect the time to change. The reason why it does not is because cAdvisor is looking in the cgroup fs and finding the oldest modified time of cgroup.clone_children in all subsystems. In other words, for each of the supported subsystems, it's looking at the oldest mtime of /sys/fs/cgroup/$subsystem/system.slice/containerd.service/cgroup.clone_children. When containerd is restarted, that file is unchanged.

https://github.com/google/cadvisor/blob/730e7df6dbddf323b4cdd54cc91156cfdd9cf127/container/common/helpers.go#L74-L91

In this code, for the runtime:

  • cgroupPaths is a map (eg { cpu: /sys/fs/cgroup/cpu/system.slice/containerd.service/, memory: /sys/fs/cgroup/memory/system.slice/containerd.service/ })
  • spec.CreationTime is set as the startTime in summary API

Anything else we need to know?:

Environment:

  • Kubernetes version (use kubectl version): At least 1.16+ just from reading it and experiments.
  • Cloud provider or hardware configuration: GKE
  • OS (e.g: cat /etc/os-release): Container-Optimized OS however this seems OS-agnostic
  • Kernel (e.g. uname -a): 5.4.49+ however kernel shouldn't matter
  • Install tools:
  • Network plugin and version (if this is a network-related bug):
  • Others:

closed time in 8 minutes

karan

issue commentkubernetes/kubernetes

Restarting containerd (and kubelet) does not impact "runtime" startTime in summary API

What happened: Containerd (and optionally the kubelet) was restarted.

What you expected to happen: runtime's startTime should be the restart time.

I would not this expect this to happen because restarting containerd should not restart containers. The data plane should be resilient to control plane failures.

/close

karan

comment created time in 8 minutes

pull request commentkubernetes/kubernetes

Remove MPL-licensed dep from lruexpirecache

@ahmedtd: The following tests failed, say /retest to rerun all failed tests:

Test name Commit Details Rerun command
pull-kubernetes-verify d0a5e8b4cd6c3062412f1bebc83dc1ce1569d34c link /test pull-kubernetes-verify
pull-kubernetes-e2e-aks-engine-windows-containerd d0a5e8b4cd6c3062412f1bebc83dc1ce1569d34c link /test pull-kubernetes-e2e-aks-engine-windows-containerd
pull-kubernetes-dependencies 9ad2f62817d763dc1eefa0847a28f0a679276cb8 link /test pull-kubernetes-dependencies
pull-kubernetes-node-e2e-containerd 9ad2f62817d763dc1eefa0847a28f0a679276cb8 link /test pull-kubernetes-node-e2e-containerd

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

<details>

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. </details> <!-- test report -->

ahmedtd

comment created time in 9 minutes

issue commentkubernetes/kubernetes

sched: revisit preference algorithm of extended resources in heterogeneous env

the best practice is that these nodes should have a taint so that pods that don't request the resource don't get scheduled there

With this as an assumption, yes, (50+50)/2 is a neat algorithm.

Huang-Wei

comment created time in 9 minutes

pull request commentkubernetes/kubernetes

Run ubernetes tests on gke only

Ah, I see:

https://github.com/kubernetes/kubernetes/pull/103160/files#diff-5932e00b41c8dd8f2d77bad2acee72a8d1f6c956e4b52e7ddc86d6573395b5e8R127

which creates an instance. That is definitely an assumption that is very much tied to GKE vs the more broad GCE. I would expect that to skip.

Is there a corresponding test for this that would work in most cloud environments? Or are those already covered elsewhere?

/hold cancel

ravisantoshgudimetla

comment created time in 10 minutes

pull request commentkubernetes/kubernetes

Remove MPL-licensed dep from lruexpirecache

@ahmedtd: The following tests failed, say /retest to rerun all failed tests:

Test name Commit Details Rerun command
pull-kubernetes-verify d0a5e8b4cd6c3062412f1bebc83dc1ce1569d34c link /test pull-kubernetes-verify
pull-kubernetes-e2e-aks-engine-windows-containerd d0a5e8b4cd6c3062412f1bebc83dc1ce1569d34c link /test pull-kubernetes-e2e-aks-engine-windows-containerd
pull-kubernetes-node-e2e-containerd 9ad2f62817d763dc1eefa0847a28f0a679276cb8 link /test pull-kubernetes-node-e2e-containerd
pull-kubernetes-dependencies 9ad2f62817d763dc1eefa0847a28f0a679276cb8 link /test pull-kubernetes-dependencies

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

<details>

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. </details> <!-- test report -->

ahmedtd

comment created time in 10 minutes

pull request commentkubernetes/kubernetes

Remove MPL-licensed dep from lruexpirecache

/test pull-kubernetes-node-e2e-containerd

ahmedtd

comment created time in 11 minutes

pull request commentkubernetes/kubernetes

Remove MPL-licensed dep from lruexpirecache

@ahmedtd: The following tests failed, say /retest to rerun all failed tests:

Test name Commit Details Rerun command
pull-kubernetes-verify d0a5e8b4cd6c3062412f1bebc83dc1ce1569d34c link /test pull-kubernetes-verify
pull-kubernetes-e2e-aks-engine-windows-containerd d0a5e8b4cd6c3062412f1bebc83dc1ce1569d34c link /test pull-kubernetes-e2e-aks-engine-windows-containerd
pull-kubernetes-dependencies 8ca0a3e8eb86ccc65ca96f7c777f86298dcff542 link /test pull-kubernetes-dependencies
pull-kubernetes-node-e2e-containerd 9ad2f62817d763dc1eefa0847a28f0a679276cb8 link /test pull-kubernetes-node-e2e-containerd

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

<details>

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. </details> <!-- test report -->

ahmedtd

comment created time in 11 minutes

Pull request review commentkubernetes/test-infra

Crier slack reporter: use pointers for merging configs

 type ReporterConfig struct { }  type SlackReporterConfig struct {-	Host              string         `json:"host,omitempty"`-	Channel           string         `json:"channel,omitempty"`-	JobStatesToReport []ProwJobState `json:"job_states_to_report,omitempty"`-	ReportTemplate    string         `json:"report_template,omitempty"`+	Host              *string         `json:"host,omitempty"`+	Channel           *string         `json:"channel,omitempty"`+	JobStatesToReport *[]ProwJobState `json:"job_states_to_report,omitempty"`

I'm not sure that this field should be a pointer type. Currently is possible for JobStatesToReport == nil or *JobStatesToReport == nil, but this seems redundant and it wouldn't even be possible to achieve the later by loading from YAML.

chaodaiG

comment created time in an hour

Pull request review commentkubernetes/test-infra

Crier slack reporter: use pointers for merging configs

 func (cfg SlackReporterConfigs) GetSlackReporter(refs *prowapi.Refs) SlackReport  func (cfg *SlackReporter) DefaultAndValidate() error {

It looks like we only ever use this on the global config, we never default and validate the merged config for the jobs. Ideally this validation would be checked at config load time.

chaodaiG

comment created time in 19 minutes