jiebi/CodeConvo huggingface dataset:
Change:
}), }, } <del> systemPriority := int32(2147483647) specs[1].pod.Spec.Priority = &systemPriority </del> <ins> specs[1].pod.Spec.PriorityClassName = highPriorityClassName </ins> runEvictionTest(f, pressureTimeout, expectedNodeCondition, expectedStarvedResource, logMemoryMetrics, specs) }) })

Discussion:
https://k8s- The following tests are broken: NVIDIA GPU Device Plugin PriorityLocalStorageEvictionOrdering PriorityMemoryEvictionOrdering Looks like some new validation was to prevent two things: PodPriority directly system-critical priority classes outside of the kube-system namespace. To fix this, we need to create new priority classes for these tests. cc /kind failing-test /sig node /sig scheduling /priority important-soon
/kind bug
/assign
This doesn't appear to have fixed the tests. Tests now panic during the Aftereach in which the PriorityClass is deleted. /reopen
Panic:
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close Instructions 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
Change:
var unsecuredMux *mux.PathRecorderMux if c.SecureServing != nil { unsecuredMux = genericcontrollermanager.NewBaseHandler(&c.ComponentConfig.Generic.Debugging, healthzHandler) <ins> if utilfeature.DefaultFeatureGate.Enabled(features.ComponentSLIs) { slis.SLIMetricsWithReset{}.Install(unsecuredMux) } </ins> handler := genericcontrollermanager.BuildHandlerChain(unsecuredMux, &c.Authorization, &c.Authentication) // TODO: handle stoppedCh and listenerStoppedCh returned by c.SecureServing.Serve if _, _, err := c.SecureServing.Serve(handler, 0, stopCh); err != nil {

Discussion:
As per, , wire up for KCM
/sig instrumentation
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 instrumentation
Change:
} return nil } <ins> // FindContainerStatusInPod finds a container status by its name in the provided pod func FindContainerStatusInPod(pod *v1.Pod, containerName string) *v1.ContainerStatus { for _, containerStatus := range pod.Status.InitContainerStatuses { if containerStatus.Name == containerName { return &containerStatus } } for _, containerStatus := range pod.Status.ContainerStatuses { if containerStatus.Name == containerName { return &containerStatus } } for _, containerStatus := range pod.Status.EphemeralContainerStatuses { if containerStatus.Name == containerName { return &containerStatus } } return nil } </ins>

Discussion:
We would like to know early if the behavior is broken on any container runtime implementation. This is motivated by the discussion under the PR:
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
/sig node
/assign
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
Change:
// OnUpdate manages the active set of service proxies. // Active service proxies are reinitialized if found in the update set or // shutdown if missing from the update set. <del> func (proxier Proxier) OnUpdate(services []api.Service) { </del> <ins> func (proxier *Proxier) OnUpdate(services []api.Service) { </ins> glog.Infof("Received update notice: %+v", services) activeServices := util.StringSet{} for _, service := range services {

Discussion:
https://travis-
Looking.
Another instance, or a different thing? https://travis-
Change:
v1.NodeOutOfDisk, v1.NodeMemoryPressure, v1.NodeDiskPressure, <del> // We don't change 'NodeInodePressure' condition, as it'll be removed in future. // v1.NodeInodePressure, </del> // We don't change 'NodeNetworkUnavailable' condition, as it's managed on a control plane level. // v1.NodeNetworkUnavailable, }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind cleanup What happened: It seems kubelet did not update inode pressure; and only test codes are using . So prefer to deprecate or remove it directly. (seems no node-misc group :). )
Change:
// getResourcesAndSelector retrieves resources and the selector expression from the given args (assuming selectors the last arg) func getResourcesAndSelector(args []string) (resources []string, selector *metav1.LabelSelector, err error) { <del> if len(args) > 1 { resources = args[:len(args)-1] </del> <ins> if len(args) == 0 { return []string{}, nil, nil </ins> } <ins> resources = args[:len(args)-1] </ins> selector, err = metav1.ParseToLabelSelector(args[len(args)-1]) return resources, selector, err }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST? (choose one):BUG REPORT Kubernetes version (use ):Client Version: version.Info{Major:"1", Minor:"6+", GitVersion:"v1.6.0-alpha.0.2610+-dirty", GitCommit:"", GitTreeState:"dirty", BuildDate:"2016-12-29T06:28:44Z", GoVersion:"go1.7.1", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"6+", GitVersion:"v1.6.0-alpha.0.2610+-dirty", GitCommit:"", GitTreeState:"dirty", BuildDate:"2016-12-29T06:28:44Z", GoVersion:"go1.7.1", Compiler:"gc", Platform:"linux/amd64"} What happened:
Could someone from please help with triage. Thanks!
There is already a PR on the way.
Change:
} } <del> // transformDecodeError adds additional information when a decode fails. </del> <ins> // transformDecodeError adds additional information into a bad-request api error when a decode fails. </ins> func transformDecodeError(typer runtime.ObjectTyper, baseErr error, into runtime.Object, gvk *schema.GroupVersionKind, body []byte) error { objGVKs, _, err := typer.ObjectKinds(into) if err != nil { <del> return err </del> <ins> return errors.NewBadRequest(err.Error()) </ins> } objGVK := objGVKs[0] if gvk != nil && len(gvk.Kind) > 0 {

Discussion:
What happened: POST or PUT to a custom resource with a JSON body missing "kind" results in a 500 error: A missing "apiVersion" also results in a 500 error: Then with both "kind" and "apiVersion" defined we get the normal 4XX return codes. What you expected to happen: All bad inputs for create and update requests should be 4XX return codes. E.g. Creating a with body of results in the 422 error: How to reproduce it: Create a CRD or use a cluster that already has a one prepared (GKE 1.11.0+ clusters have the CRD installed which you could test against). HTTP to that custom resource with a JSON body of . E.g. Environment: Kubernetes version (use ): 1.11.2 Cloud provider or hardware configuration: GKE OS (e.g. from /etc/os-release): Kernel (e.g. ): /sig api-machinery <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
This is fixed on master, but I can reproduce it on 1.11. Posting a custom resource with a JSON body of : on master: on 1.11:
we are transforming all non-status error into 500 status error. in this case, it's the decoder returning a which is non-status. a quick fix by . (i like this number)
instead of fixed, it's rather been shadowed by i suppose. now when that empty unstructured obj going thru the decoder, the gvk is explicitly coerced, so this case is not reproducable on master for now.
/cc
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or .

/lifecycle rotten
I get the same response when trying to update the custom resource's 'status' sub-resource. On k8s v1.11.4
/assign
submitting the specified object on master returns a 400 badrequest, as desired /close
Closing this issue. <detailsIn response to : submitting the specified object on master returns a 400 badrequest, as desired Instructions 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
Change:
fi if [[ "${START_MODE}" != "nokubelet" ]]; then <ins> install_cni_if_needed </ins> ## TODO remove this check if/when kubelet is supported on darwin # Detect the OS name/arch and display appropriate error. case "$(uname -s)" in

Discussion:
Since we switched from dockershim to containerd, my cluster seems to come up okay but pods get stuck in ContainerCreating. When I investigated further, I found Most dependencies of launching a cluster are installed automatically. In this case, it seems we don't get the CNI plugins installed and set up as needed. /cc /sig node network Pod should have been created as expected. Try to create pods on a system with local-up-cluster without CNI plugins already installed. No response <details</details<detailsN/A </details<details</details<detailshack/local-up- </details<details</details<details</details
maybe also /sig testing ?
cc patron saint of local-up-
/assign
I think it's as simple as checking if exists (or wherever it's looking for the CNI plugins) and if not, downloading the latest Linux version for the appropriate arch of
already working on installing cni plugin for the local-up ci job but if the script is running by user, doesn't we make an assumption that user will install cni plugins along with container runtime?
/assign the local e2e job is now working, have to refine the script we are anyways installing cni for the ci job, will add a provision so that users can also install.
/triage accepted
similar bug:
Change:
<del> kind: Service apiVersion: v1 metadata: name: dns-backend spec: ports: - port: 8000 selector: name: dns-backend </del>

Discussion:
master-blocking: gce-cos-master-alpha-featuresKubernetes e2e suite:Failed runs: 09-16 09:58 CDT 09-15 23:41 CDT Both of these runs were on the same commit which also has passing builds. The test fails due to a , specifically when attempting to connect to the DNS backend service . The error indicates that the DNS backend service is either not running or not accessible on the specified address and port. This caused multiple retries in the test, with the pod failing to establish a connection to the backend service each time. As a result, the expected output "Hello World!" was not found in the logs, leading to the failure of the test. The service being unreachable could be due to several potential issues: misconfigured DNS, networking issues within the cluster, or the DNS backend service failing to start properly.Further investigation into the DNS service deployment and networking might be required to resolve this issue. There were two other failures ( , ) on the same commit that seemed to be related to cluster instance not being found: This caused failure when attempting to SSH into the instance and retrieve logs (kube-, , etc.). For those, the cluster setup (e2e-) likely failed, as no nodes were found, resulting in no instances being available. /sig network /kind flake cc:
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
/sig network /kind flake
This test should not be running in this job, it was picked recently ! since we already have coverage I think is better to remove it, is also using images that the sources are not available anymore
Change:
Output:    false, }, { <ins> Inspected: dockertypes.ImageInspect{RepoTags: []string{"colemickens/hyperkube-amd64:217.9beff63"}}, Image:     "colemickens/hyperkube-amd64:217.9beff63", Output:    true, }, { Inspected: dockertypes.ImageInspect{RepoTags: []string{"colemickens/hyperkube-amd64:217.9beff63"}}, Image:     "docker.io/colemickens/hyperkube-amd64:217.9beff63", Output:    true, }, { </ins> Inspected: dockertypes.ImageInspect{ ID: "sha256:2208f7a29005d226d1ee33a63e33af1f47af6156c740d7d23c7948e8d282d53d", },

Discussion:
I'm launching master components from static pods with kubelet. won't launch my pods. Gives this error: I suspect this very recent change: Can you advise anything
- Can you please check if works for you? fyi, i am off on vacation for a week so response may be a bit slow
Yes, it works. Thanks.
Change:
s, gc, clientSet := setup(t) defer s.Close() <del> ns := framework.CreateTestingNamespace("gc-foreground2", s, t) </del> <ins> ns := framework.CreateTestingNamespace("gc-foreground3", s, t) </ins> defer framework.DeleteTestingNamespace(ns, s, t) podClient := clientSet.Core().Pods(ns.Name)

Discussion:
https://k8s- Failed: TestBlockingOwnerRefDoesBlock {garbagecollector}
cc:
https://k8s- Failed: TestBlockingOwnerRefDoesBlock {garbagecollector}
I don't have a good theory yet. It's occurring , so I'll fix the more urgent issues first.
If its that low, its not a blocker. Moving to 1.6.1
Could this be a race condition? Perhaps needs some retry logic? Note that the creation never reported an error that would be fatal to the test:
I checked the log, it appeared when GC was processing the foreground deletion of the owner RC, GC didn't find any dependents of RC. This probably is the same race we expected in no.1. To fix the test, the test can wait some seconds before sending the deletion request, so that the garbage collector will have time to update its dependency graph.
Change:
// if there still isn't enough information to authenticate the user, try prompting if !canIdentifyUser(*mergedConfig) && (fallbackReader != nil) { <ins> if len(config.promptedCredentials.username) > 0 && len(config.promptedCredentials.password) > 0 { mergedConfig.Username = config.promptedCredentials.username mergedConfig.Password = config.promptedCredentials.password return mergedConfig, nil } </ins> prompter := NewPromptingAuthLoader(fallbackReader) promptedAuthInfo, err := prompter.Prompt() if err != nil {

Discussion:
When I want to use basic-auth, kubectl will display the password I entered: I think it is more sensible to hide the password?
And it seems that kubectl request for username/password twice...
I'll take this. There is a library here: That appears to do the trick, but we need some refactoring so that it can read from an arbitrary reader to fit our usecase.
This was fixed by but I didn't close this issue. Closing it now.
Change:
const ( patch_long = `Update field(s) of a resource using strategic merge patch <del> JSON and YAML formats are accepted.` </del> <ins> JSON and YAML formats are accepted. Please refer to the models in https://htmlpreview.github.io/?https://github.com/GoogleCloudPlatform/kubernetes/HEAD/docs/api-reference/definitions.html to find if a field is mutable.` </ins> patch_example = ` // Partially update a node using strategic merge patch <del> kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}'` </del> <ins> kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}' // Update a container's image; spec.containers[*].name is required because it's a merge key kubectl patch pod valid-pod -p '{"spec":{"containers":[{"name":"kubernetes-serve-hostname","image":"new image"}]}}'` </ins> ) func NewCmdPatch(f *cmdutil.Factory, out io.Writer) *cobra.Command {

Discussion:
The current documentation is very vague and doesn't explain what can be updated in this way. Can I rename or stop the pod, change number of replicas in RC etc. For example it seems to be impossible to change pod name:
cc
After an in person discussion with we think the docs should point people to the swagger-ui to find if a field is mutable. I'll add this point into the docs.
Change:
"context" "encoding/json" "fmt" <ins> netutil "k8s.io/utils/net" </ins> "net" "strings" "time"

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: sig-network-kind-ipvs,dual,master sig-network-kind-ipvs,IPv6,master Which test(s) are failing: [x] KubeProxy should set TCP CLOSE_WAIT timeout [x] Conntrack should be able to preserve UDP traffic when server pod cycles for a NodePort Service [x] KubeProxy should resorve connection reset issue (tracking in ) Since when has it been failing: Oct 28 Testgrid link: sig-network-kind-ipvs,dual,master  Reason for failure: Both appear to be failing on missing conntrack entries ex. Anything else we need to know:
/sig network /cc /assign
I'm spinning up a kind cluster with ipv6+ipvs to see if I can replicate this test locally
/triage accepted
heh, the job was not running it, it started to run when we changed the tag I meant this test and the PR where we renamed the kube-proxy test
this one has an issue already open, and I have a PR for fixing it
reached out to me on Slack and we identified as the high priority. I have tested this locally and it fails on both IPTables and IPVS kind clusters locally. I'm digging through the cluster logs now.
I' ve logging to conntrack with level v4 recently just for these problems, try to bump your kube-proxy logging to v4
seems that there are less test failures on the IPv6 jobs, let's keep watching them :eyes: However, the dual-stack jobs are legit failures, basically because on dualstack clusters, the node has 2 internal IPs, and those tests use the internal IP for asserting some operations, and the problem is that they are picking the internalIP of the wrong IP family, hence the test fails The solution should be to add the InernalIp correspoding to the cluster primary IP familty, you can obtain it with but it seems that we have to modify the function or add a new one that returns the nodes and the corresponding ips
Hey Thanks for all the help, will look into the areas of the code and try to bump the logging.
Change:
t.Errorf("Expected %v, but got %v", e, a) } <ins> // Test a name + port number (service port 93 -> target port 80, using second ip) location, _, err = redirector.ResourceLocation(ctx, "foo-second-ip:93") if err != nil { t.Errorf("Unexpected error: %v", err) } if location == nil { t.Errorf("Unexpected nil: %v", location) } if e, a := "//[2001:db7::]:80", location.String(); e != a { t.Errorf("Expected %v, but got %v", e, a) } </ins> // Test a name + port number (service port 9393 -> target port "p" -> endpoint port 93) location, _, err = redirector.ResourceLocation(ctx, "foo:9393") if err != nil {

Discussion:
Hi, I have a issue with a dualstack cluster for my Kubernetes Dashboard deployment. I opened a ticket here (), but I am informed that it is not related to Kubernetes Dashboard. What is the problem? Errors in kube-api: The service is created with the correct ipFamily (=IPv6). My endpoint is fully in IPv6. Indeed, my pod has one IP in IPv4 and another in IPv6. Do you have also the issue? Kubernetes version: 1.18 OS: RHEL7
/sig network /sig api-machinery
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
I think the following should fix the error you saw:
/remove-sig api-machinery
Change:
deps = [ "//pkg/api/v1/pod:go_default_library", "//pkg/apis/core/v1/helper:go_default_library", <ins> "//pkg/features:go_default_library", </ins> "//staging/src/k8s.io/api/core/v1:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/labels:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/util/sets:go_default_library", <ins> "//staging/src/k8s.io/apiserver/pkg/util/feature:go_default_library", </ins> "//staging/src/k8s.io/kube-scheduler/extender/v1:go_default_library", "//vendor/k8s.io/klog:go_default_library", ],

Discussion:
The scheduler does not properly calculate pod requests for a resource as - it ignores init containers completely in . This would allow a workload to get "free" scheduling above the limit of containers (mitigated by quota, which calculates this properly) and so the scheduler would make non-optimal fits. Both kubelet and scheduler enforce the , so you can't actually schedule, but you sometimes get steered to the wrong node if you have more init container resource usage than containers. in should use and the similar helpers instead of writing its own method to calculate the request for resources. /sig scheduling
/priority important-soon
Let me follow this issue. /assign
fyi
After I checked the implementation of function, I think we just need to use it to instead of the function in the scheduler.
/priority critical-urgent
Is the pod phase not considered? When the pod phase is running, the requested resource is actually considered as . This change seems to reduce the resource utilization of the node.
Actually, I don't think we need to consider the pod.Phase. The resource request & limit are mainly used in the scheduling process. The scenario you said is not belong to the responsibility of kube-scheduler
Correct. Setting appropriate requests/limits that maintain good node usage is users responsibility. Considering the max(initContainers, sum(containers)) is the documented behavior.
I understand. Thank you for your comments!
Change:
<ins> // +build !providerless </ins> /* Copyright 2019 The Kubernetes Authors.

Discussion:
make verify WHAT=typecheck-providerless outputs /cc /milestone v1.19
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <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
see example successful run:
For reference -
fix in
screaming