jiebi/CodeConvo huggingface dataset:
Change:
"//test/e2e/framework/resource:go_default_library", "//test/e2e/framework/service:go_default_library", "//test/e2e/framework/skipper:go_default_library", <ins> "//test/e2e/framework/testfiles:go_default_library", </ins> "//test/utils:go_default_library", "//test/utils/image:go_default_library", "//vendor/github.com/onsi/ginkgo:go_default_library",

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: Which test(s) are failing: Since when has it been failing: Testgrid link: Reason for failure: Anything else we need to know: /sig scheduling /cc /priority critical-urgent /milestone v1.19
Appears to have started failing after , which seems unrelated. /cc
according to the build log , the test timed out because it could not find gpu on any nodes. Is it probably a test-infra issue?
I think you are right, I don't see anything changing in the config so must be underlying infra issue /cc
yes, the issue is that the nodes do not have the GPU required to run the test The same infra commit () was used for the last passing job () and the first failing job ()
not sure who owns the node setup for the gpu tests, but I would guess
test-infra-maintainers owns e.g. prow, I don't think anything there relates to the GPUs the infra commit (test-infra commit) not changing suggests perhaps a change to the scripts / test harness in this repo?
the delta between the passing and failing runs only changed an ingress e2e test ()
The image is used in when installing the Nvidia driver. Given that ([1]) is lastly updated on July 17, 2020 at 12:22:11 AM UTC-7 (latest tag points to v2.0.0), does it seem this version is incompatible? BTW: the latest successful run pulled the image with SHA: 8d86a652759f80595cafed7d3dcde3dc53f57f9bc1e33b27bc3cfa7afea8d483 ([2]), maybe we can try that SHA specifically? [1]: [2]:
Forgot to mention, the shows that the deamonset was pending:
yes, and the log also shows that the pod was pending because the init container failed to complete could we change the image to  whose digest is exactly .
Change:
// acceptedNames are the names that are actually being used to serve discovery. // They may be different than the names in spec. <ins> // +optional </ins> optional CustomResourceDefinitionNames acceptedNames = 2; // storedVersions lists all versions of CustomResources that were ever persisted. Tracking these

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Currently, the field on must be explicitly set to their zero-values due to the fact that they are not tagged . Ref: Why is this needed: If using a system that automatically compares the provided configuration to the current, it will produce a diff on the updated status after creation. In addition, making sure to explicitly set to zero-values is not the best user experience. I am happy to provide the fix if this change is approved! /cc /sig api-machinery /area custom-resources
marking them as seems ok, so that client-side validation doesn't complain if they are absent when submitting manifests, but they shouldn't need to be set to omitempty (and at this point, we likely wouldn't change the serialization) Those fields are changed by controllers after creation, so expecting the live API object to exactly match the status is not going to go well anyway.
Good point! I’ll open a fix for this. Yep! The specific system in question ignores fields that are not set at creation time by default when doing comparison, so if status fields are not included then it will not report a diff.
/assign
I opened a fix for this but CC'ed both you and Let me know if any additional effort is required. Thanks!
Change:
} func (s *ServiceController) createLoadBalancer(service *v1.Service) (*v1.LoadBalancerStatus, error) { <del> nodes, err := s.nodeLister.List(labels.Everything()) </del> <ins> nodes, err := s.nodeLister.ListWithPredicate(getNodeConditionPredicate()) </ins> if err != nil { return nil, err } <del> lbNodes := []*v1.Node{} for ix := range nodes { if includeNodeFromNodeList(nodes[ix]) { lbNodes = append(lbNodes, nodes[ix]) } } </del> // - Only one protocol supported per service // - Not all cloud providers support all protocols and the next step is expected to return //   an error for unsupported protocols <del> return s.balancer.EnsureLoadBalancer(s.clusterName, service, lbNodes) </del> <ins> return s.balancer.EnsureLoadBalancer(s.clusterName, service, nodes) </ins> } // ListKeys implements the interface required by DeltaFIFO to list the keys we

Discussion:
For reasons that are not entirely clear to me, and as spotted by in , there are two functions for selecting nodes in includeNodeFromNodeList & getNodeConditionPredicate. I think includeNodeFromNodeList should use the logic in getNodeConditionPredicate
/sig network
Change:
// The number of old ReplicaSets to retain to allow rollback. // This is a pointer to distinguish between explicit zero and not specified. <del> // Defaults to 2. </del> <ins> // Defaults to 10. </ins> // +optional RevisionHistoryLimit *int32 `json:"revisionHistoryLimit,omitempty" protobuf:"varint,6,opt,name=revisionHistoryLimit"`

Discussion:
All controllers that use the field have a default value of 10 for the field, except for , which has a default of 2. We should increase it to 10 for consistency on its default value across controllers. /sig apps
Change:
} ]' spec: <ins> affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: labelSelector: matchExpress: - key: app operator: In values: - cockroachdb topologyKey: kubernetes.io/hostname </ins> containers: - name: cockroachdb # Runs the master branch. Not recommended for production, but since

Discussion:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): Is this a BUG REPORT or FEATURE REQUEST? (choose one): <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): master Environment: Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: What happened: Check , it is still using , we should move it to . What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know:
/assign
probably will want to move the init container also to the PodSpec
I think the init container still depend on annotations , can I specify in ? If so, I want to file another issue to track it
FYI Init containers have graduated to GA and now appear as a field. The beta annotation value will still be respected and overrides the field value. (,
Seems like that the doc should be updated. EDIT: NOTE: This feature is beta in Kubernetes 1.5. Once the feature exits beta, Init Containers will be specified in the PodSpec alongside the app containers array.
Thanks I filed an issue here
What about merge this first and then handle init-container in a separate PR?
Sounds good to me, thanks.
Change:
"k8s.io/apiserver/pkg/authentication/user" genericapirequest "k8s.io/apiserver/pkg/endpoints/request" "k8s.io/apiserver/pkg/server/egressselector" <ins> utilflowcontrol "k8s.io/apiserver/pkg/util/flowcontrol" </ins> "k8s.io/component-base/metrics" "k8s.io/component-base/metrics/legacyregistry" apiregistration "k8s.io/kube-aggregator/pkg/apis/apiregistration/v1"

Discussion:
On a cluster with many APIs provided by aggregated apiservers, with controllers managing those APIs, the number of occupied seats effectively has a floor of 1 per watch. If the combined max-inflight limit is reduced low enough, priority levels tend to become saturated by these long-running watch requests and other requests are starved. Watch requests consume a seat only during initialization. a PriorityLevelConfiguration and a corresponding FlowSchema to match watches against a resource served by an aggregated apiserver. some watch requests. the metric climb on the priority level per watch until all seats are exhausted. Kubernetes version (use ): (OpenShift 4.9) /sig api-machinery
cc
D'oh! I can see two obvious possible ways to cope: one apiserver not manage watch requests the are delegated to another apiserver; or a marker into the notification stream so that the non-origin apiservers can detect when initialization is done.
I would even say that for regular (non-long-running) requests, it's not obvious that they should be managed by P&F even. [I agree that for watch initialization it's particularly bad though.] - do we have a simple way to detect if the request will be served from our kube-apiserver or from some other aggregated apiserver?
There is not currently a way to know that ahead of time in the filters today. It require a list/watch, but it ought not be excessively expensive to make a 99% correct prediction, but the actual decision is made by the aggregated apiserver later in the request.
/triage accepted
: is there a way that we can plumb that knowledge forward to the filters?
Change:
"//vendor/k8s.io/apimachinery/pkg/util/wait:go_default_library", "//vendor/k8s.io/apimachinery/pkg/util/yaml:go_default_library", "//vendor/k8s.io/apimachinery/pkg/watch:go_default_library", <ins> "//vendor/k8s.io/apiserver/pkg/util/feature:go_default_library", </ins> "//vendor/k8s.io/client-go/kubernetes:go_default_library", ] + select({ "@io_bazel_rules_go//go/platform:linux": [

Discussion:
Once the API for is finalized, add a node e2e test. /kind feature /assign /cc /sig node
We plan on adding this for 1.10
Change:
err = f.WaitForPodRunning(pod.Name) framework.ExpectNoError(err, "Error waiting for pod to run %v", pod) <del> content, err = tk.ReadFileViaContainer(pod.Name, "test-container", testFilePath) framework.ExpectNoError(err, "Error reading file via container") gomega.Expect(content).NotTo(gomega.ContainSubstring(testContent)) </del> <ins> // for this to work, SELinux should be in enforcing mode, so let's check that isEnforced, err := tk.ReadFileViaContainer(pod.Name, "test-container", "/sys/fs/selinux/enforce") if err == nil && isEnforced == "1" { _, err = tk.ReadFileViaContainer(pod.Name, "test-container", testFilePath) framework.ExpectError(err, "expecting SELinux to not let the container with different MCS label to read the file") } </ins> }

Discussion:
Tests in are failing because they are faulty. A container can't read from a file if it has selinux permission denied for it. More context - /sig node /sig storage
something we can look into.
Also,
The tests expect that SELinux blocks a pod with label "s0:c2,c3" reading a file created by a pod with label "s0:c0,c1". Since the tests runs on GCI, where SELinux is not available, nothing blocks the read and the tests can't ever pass. The tests should check that the node has SELinux in Enforcing mode and skip the tests otherwise. Somewhere around these parts, where we write/read a file in the first "s0:c0,c1" pod: Is there an easy way how to test that in /proc or /sys in a non-privileged busybox container?
There are two problems. First one is obviously - the test can't run on non-selinux systems, but second one is - it is also broken on selinux enabled systems as per
To check whether SELinux is in enforced mode, one can check that read returns "1". I've implemented that in a particular case that relies on selinux being enforced: To check whether SELinux is enabled (I guess this is a prerequisite for all the test cases in ), one can use from (which of course should be run in a proper context). In case a check for a particular container is needed, the presence of directory should be enough. Having said that, I'm not sure how to properly wrap the above check(s) into (or , or whatever).
Change:
wantPodStatus: v1.PodStatus{ Phase:   v1.PodFailed, Reason:  "Evicted", <del> Message: "The node was low on resource: memory. ", </del> <ins> Message: "The node was low on resource: memory. Threshold quantity: 2Gi, available: 1500Mi. ", </ins> }, }, }

Discussion:
when the pod is evicted due to low imagefs.available, the prompt is difficult to understand. it showed: But the container was evicted not by exceeding its request of 0 ephemeral-storage, but due to reaching the evictionHard of the node. The correct prompt message points out the reason for the pod eviction. don't print "which exceeds its request of 0.", because the container was evicted not by exceeding its request of 0. % oc label mcp worker custom-kubelet-eviction=small-pods evictionHard by creating a kubeletconfig % oc create -f custom-kubelet- custom-kubelet- several minutes, the mcp worker finish rolling out to the latest mc a pod % oc create -f hello-pod- hello-pod- a large file in container, make imagefs.available < 90Gi (the current available disk size is 111G ) command terminated with exit code 137 the node status the pod status % oc get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES hello-pod-2 0/1 ContainerStatusUnknown 1 7m58s 10.131.0.7 ip-10-0-213- <none<none% oc get pod hello-pod-2 -o yaml No response <details</details<detailsaws </details<details</details<details</details<details</details<details</details
/sig node
/assign
/assign
/triage accepted
Change:
if nanoSeconds <= 0 { return nil, fmt.Errorf("zero or negative interval (%v - %v)", newStats.Timestamp, cachedStats.Timestamp) } <del> usageNanoCores := (newStats.UsageCoreNanoSeconds.Value - cachedStats.UsageCoreNanoSeconds.Value) * uint64(time.Second/time.Nanosecond) / uint64(nanoSeconds) </del> <ins> usageNanoCores := uint64(float64(newStats.UsageCoreNanoSeconds.Value-cachedStats.UsageCoreNanoSeconds.Value) / float64(nanoSeconds) * float64(time.Second/time.Nanosecond)) </ins> // Update cache with new value. usageToUpdate := usageNanoCores

Discussion:
What happened: CRI CPU metrics are incorrect when using a large number of cores, due to a overflow. What you expected to happen: CPU metrics should be correct for arbitrarily high numbers of cores. How to reproduce it (as minimally and precisely as possible): Deploy a pod with 20 CPU units allocated, and fetch the CRI metrics. The metrics will be incorrect. Environment: Kubernetes version (use ): 1.14.4 CRI: CRI-O cc cc /sig node /sig scalability
How did you get the cri cpu metrics?
kubelet /stats/summary API. For "large" pods, we confirmed that cri-o/cgroupfs calculations were being generated correctly and CPU data overflows at the kubelet CRI stats provider layer. Overflows of CPU data in /stats/summary results in metrics-server having bad data which further propagates to the HPA scaling Pods incorrectly.
Change:
# Accessing the Cluster <del> ## Using the Kubernetes proxy to access the cluster </del> <ins> * [Using the Kubernetes proxy](#proxy) * [Requesting redirects](#redirect) ## <a name="proxy"></a>Using the Kubernetes proxy to access the cluster </ins> Information about the cluster can be accessed by using a proxy URL and the cluster authentication keys. <del> For example, for a cluster that has cluster-level logging enabled (using Elasticsearch), you can retrieve information about the Elasticsearch logging on that cluster. </del> <ins> For example, if a cluster has cluster-level logging enabled (using Elasticsearch), you can retrieve information about the Elasticsearch logging on that cluster through a proxy URL. ### Retrieving the authentcation keys and proxy URLs Use `kubectl` commands to retrieve the access information. </ins> <del> To retrieve the configuration details about your cluster, including the address of the Kubernetes master cluster and the cluster's authentication keys (username, password, and access token), run the following command: </del> <ins> To retrieve the authentication keys for your clusters, run the following command: </ins> ``` $ kubectl config view <del> { clusters: - cluster: certificate-authority-data: REDACTED server: https://104.197.5.247 name: kubernetes_logging contexts: - context: cluster: kubernetes_logging user: kubernetes_logging name: kubernetes_logging current-context: kubernetes_logging kind: Config preferences: {} </del> <ins> ... </ins> users: - name: kubernetes_logging user:

Discussion:
is out of date. Please update for the current location/contents of the file and v1beta3. Once is submitted we should also update the examples to show to to curl using bearer tokens instead of basic auth credentials.
We're working on scrubbing the docs and examples of references to v1beta1 () prior to deleting that API, so it would be good to have this in soon.
: let me know if you want to punt this back to me -- now that I have some clue again about how to access an cluster (assuming I can create a cluster!).
Punting back to you. Getting the auth credentials is accomplished via But I think you have a better idea how to curl with token auth than I do.
Change:
} function kube-up { <del> echo "Starting cluster using os distro: ${KUBE_OS_DISTRIBUTION}" >&2 </del> <ins> echo "Starting cluster using os distro: ${OS_DISTRIBUTION}" >&2 </ins> get-tokens

Discussion:
If e.g. coreos doesn't work with kube-up, we should point users to an installation method that works. Also consider offering hints like "vivid no longer gets security updates, consider using wily or official"
Change:
type containerManagerStub struct { shouldResetExtendedResourceCapacity bool <ins> extendedPluginResources             v1.ResourceList </ins> } var _ ContainerManager = &containerManagerStub{}

Discussion:
A kubernetes cluster is normally constructed from a variety of machine templates. Different instance groups may have different CPU, memory capacity. They may be equipped with specialized accelerators, network devices. I think we should have an extensible way for users to custom node configuration to simulate real production cluster states. Currently, nodelabel and nodetaints are supported. I am consider to accept a template with more configuration like resources so we won't grow option list in the future. Without this feature, it's hard for users to simulate heterogeneous cluster.
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
/sig scalability
Change:
// all at once. APIListChunking featuregate.Feature = "APIListChunking" <del> // owner: @MikeSpreitzer @yue9944882 // alpha: v1.18 // beta: v1.20 // stable: 1.29 // // Enables managing request concurrency with prioritization and fairness at each server. // The FeatureGate was introduced in release 1.15 but the feature // was not really implemented before 1.18. APIPriorityAndFairness featuregate.Feature = "APIPriorityAndFairness" </del> // owner: @ilackams // alpha: v1.7 // beta: v1.16

Discussion:
Priority and Fairness is going GA in 1.29, the feature has been marked stable and the feature gate has been locked to default. See In 1.31, we need to remove the feature gate.
/kind bug /sig api-machinery /cc
/assign
/triage accepted
Change:
vagrant ssh node-1 ``` <del> If you are running more than one nodes, you can access the others by: </del> <ins> If you are running more than one node, you can access the others by: </ins> ```sh vagrant ssh node-2 vagrant ssh node-3 ``` <ins> Each node in the cluster installs the docker daemon and the kubelet. The master node instantiates the Kubernetes master components as pods on the machine. </ins> To view the service status and/or logs on the kubernetes-master: ```console <del> $ vagrant ssh master [vagrant@kubernetes-master ~] $ sudo systemctl status kube-apiserver [vagrant@kubernetes-master ~] $ sudo journalctl -r -u kube-apiserver </del> <ins> [vagrant@kubernetes-master ~] $ vagrant ssh master [vagrant@kubernetes-master ~] $ sudo su </ins> <del> [vagrant@kubernetes-master ~] $ sudo systemctl status kube-controller-manager [vagrant@kubernetes-master ~] $ sudo journalctl -r -u kube-controller-manager </del> <ins> [root@kubernetes-master ~] $ systemctl status kubelet [root@kubernetes-master ~] $ journalctl -ru kubelet </ins> <del> [vagrant@kubernetes-master ~] $ sudo systemctl status etcd [vagrant@kubernetes-master ~] $ sudo systemctl status nginx </del> <ins> [root@kubernetes-master ~] $ systemctl status docker [root@kubernetes-master ~] $ journalctl -ru docker [root@kubernetes-master ~] $ tail -f /var/log/kube-apiserver.log [root@kubernetes-master ~] $ tail -f /var/log/kube-controller-manager.log [root@kubernetes-master ~] $ tail -f /var/log/kube-scheduler.log </ins> ``` To view the services on any of the nodes: ```console <del> $ vagrant ssh node-1 [vagrant@kubernetes-node-1] $ sudo systemctl status docker [vagrant@kubernetes-node-1] $ sudo journalctl -r -u docker [vagrant@kubernetes-node-1] $ sudo systemctl status kubelet [vagrant@kubernetes-node-1] $ sudo journalctl -r -u kubelet </del> <ins> [vagrant@kubernetes-master ~] $ vagrant ssh node-1 [vagrant@kubernetes-master ~] $ sudo su [root@kubernetes-master ~] $ systemctl status kubelet [root@kubernetes-master ~] $ journalctl -ru kubelet [root@kubernetes-master ~] $ systemctl status docker [root@kubernetes-master ~] $ journalctl -ru docker </ins> ``` ### Interacting with your Kubernetes cluster with Vagrant.

Discussion:
I cannot find such a service when . Same thing applies for . My cluster runs fine. cc:
Ah, good catch... everything is run as a container now, will update the documentation on where to get the logs.
Change:
srcs = ["healthz_test.go"], embed = [":go_default_library"], deps = [ <ins> "//staging/src/k8s.io/api/core/v1:go_default_library", </ins> "//staging/src/k8s.io/apimachinery/pkg/util/sets:go_default_library", "//staging/src/k8s.io/apiserver/pkg/endpoints/metrics:go_default_library", "//staging/src/k8s.io/component-base/metrics/legacyregistry:go_default_library",

Discussion:
<!-- 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 --What happened: for extension API server panics with: Apparently introduces this panic with . What you expected to happen: to do not panic. How to reproduce it (as minimally and precisely as possible): extension API server with - for example the endpoint that the apiserver panics with Anything else we need to know?: Environment: Kubernetes version (use ): / Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/kind regression
/sig api-machinery
/assign
cc
Oops - sorry for that. It seems it is basically this comment: that I blindly applied without e2e retesting (the problem seem to be lack of tests, which is a bit surprising because bugs in my previous implementations were caught by tests). ^^ BTW - this has been cherrypicked to previous releases: 16: 17: 18: so it's actually even more critical...
I can file the automated cherry-pick PRs once the PR against the master branch is merged. :)
Reopening - since we need to cherrypick it still.
I now opened the cherry-picks: 16 - 17 - 18 -
Fix and picks are merged