jiebi/CodeConvo huggingface dataset:
Change:
// GetWaitingPod returns a waiting pod given its UID. GetWaitingPod(uid types.UID) WaitingPod <ins> // RejectWaitingPod rejects a waiting pod given its UID. RejectWaitingPod(uid types.UID) </ins> // ClientSet returns a kubernetes clientSet. ClientSet() clientset.Interface

Discussion:
What would you like to be : When the pod is scheduled to the phase and I delete the pod, the pod still remains in the until the plugin allow/reject/timeout(Especially when waiting for a long time). Why is this needed: We need to take the initiative to delete the data in the and terminate the process in waiting state of plugin to ensure data accuracy, if the pod has been deleted /cc /priority important-soon /assign /sig scheduling
I think we can update the event handler for deleting pods to reject the pod. Can you send a PR for that?
OKI will send a pr for it.
Change:
decision.Message = fmt.Sprintf("failed messageExpression: %s", err) } else if evalResult.EvalResult != celtypes.True { decision.Action = ActionDeny <ins> decision.Evaluation = EvalDeny </ins> if validation.Reason == nil { decision.Reason = metav1.StatusReasonInvalid } else {

Discussion:
This issue is about the function in . In this function, 's is evaluated in this line: and if is not , 's is set to : But remains empty string. should be set to . No response I imported public library <details</summary</details<details</details<details</details<details</details<details</details<details</details
/assign
/sig api-machinery
I am new to contributing to this repo can you please tell me what all things I should be familiar with to start contributing in kubernetes specifically this issue.
/cc /triage accepted
Change:
// NewAPIServer creates a new APIServer object with default parameters func NewAPIServer() *APIServer { s := APIServer{ <del> Port:                   8080, </del> <ins> WideOpenPort:           8080, </ins> Address:                util.IP(net.ParseIP("127.0.0.1")), PublicAddressOverride:  util.IP(net.ParseIP("")), ReadOnlyPort:           7080, APIRate:                10.0, APIBurst:               200, <del> SecurePort:             8443, </del> <ins> SecurePort:             6443, </ins> APIPrefix:              "/api", EventTTL:               48 * time.Hour, AuthorizationMode:      "AlwaysAllow",

Discussion:
Trying to hit the read-write kubernetes service from inside a cluster does not work. tailing the kube-proxy logs shows: And sure enough, kube-apiserver is not listening on the NIC on that port. 8080 is only for the localhost HTTP communications between master components (and nginx redirect after HTTPS termination). The "kubernetes" master service needs to get created with Port set to 443.
+1
This needs to be port 6443 the auth_port On Feb 6, 2015 10:14 AM, "Paulo Pires" wrote:
The code says 8443, but then a flag changes to 6443. Will fix. , Eric Tune wrote:
Holy macaroni this is a mess. , Tim Hockin wrote:
Change:
} iptInterface := fakeiptables.NewFake() sysctl := fakesysctl.NewFake() <del> execer := &fakeexec.FakeExec{} </del> <ins> execer := &fakeexec.FakeExec{ LookPathFunc: func(_ string) (string, error) { return "", errors.New("fake execer") }, } </ins> eventBroadcaster := record.NewBroadcaster() recorder := eventBroadcaster.NewRecorder(legacyscheme.Scheme, v1.EventSource{Component: "kube-proxy", Host: config.NodeName})

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: What happened: when i run hollow-node deploymenthollow-proxy will cause panic. hollow-node deployment is as follows: hollow-proxy container logs: I1012 12:37:13. 7 ] syncProxyRules took 622.278µs I1012 12:37:13. 7 asmamd64.s:573] Shutting down service config controller E1012 12:37:13.

7 ] Observed a panic: "invalid memory address or nil pointer dereference" (runtime error: invalid memory address or nil pointer dereference) /usr/local/go/src/runtime/asmamd64.s:573 /usr/local/go/src/runtime/asmamd64.s:2361 panic: runtime error: invalid memory address or nil pointer dereference [recovered] panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x2c68ad9] goroutine 74 [running]: (0x0, 0x0, 0x0) +0x107 panic(0x32dc9e0, 0x5c20d20) +0x229 (FakeExec).LookPath(0xc420ad4450, 0x3ac6dba, 0x9, 0xc4208c51d0, 0x0, 0xc4200a4800, 0x4e7e83) +0x39 (0x3e3c000, 0xc420ad4450, 0xc4208c51d0, 0x5, 0x5, 0x5, 0x5) +0x5e (0x3e3c000, 0xc420ad4450, 0xc420768c70, 0xc, 0x3abdd6d, 0x3, 0x0, 0x0) +0x17d (Proxier).syncProxyRules(0xc420d8fe40) +0xb643 (Proxier).OnServiceSynced(0xc420d8fe40) +0x62 (ServiceConfig).Run(0xc420ad5080, 0xc4200b62a0) +0x183 created by (*ProxyServer).Run +0x283 What you expected to happen: How to reproduce it (as minimally and precisely as possible): boot up hollow-proxy container with "--use-real-proxier=true" Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g.

): Install tools: Others: I found that in "kubemark/hollow-" we init a 'FakeExec' struct, but we don't init LookPathFunc in 'FakeExec' struct. So, execer.LookPathFunc is a vild pointer, so it cause panic.
/sig Testing
maybe we need init:
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
/remove-lifecycle stale
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
/remove-lifecycle stale I met this issue as well.
/sig scalability
Change:
return upgradeRoundTripper.NewConnection(resp) } <del> // DoRaw executes a raw request which is not subject to interpretation as an API response. func (r *Request) DoRaw() ([]byte, error) { </del> <ins> // request connects to the server and invokes the provided function when a server response is // received. It handles retry behavior and up front validation of requests. It wil invoke // fn at most once. It will return an error if a problem occured prior to connecting to the // server - the provided function is responsible for handling server errors. func (r *Request) request(fn func(*http.Request, *http.Response)) error { if r.err != nil { return r.err } // TODO: added to catch programmer errors (invoking operations with an object with an empty namespace) if (r.verb == "GET" || r.verb == "PUT" || r.verb == "DELETE") && r.namespaceSet && len(r.resourceName) > 0 && len(r.namespace) == 0 { return fmt.Errorf("an empty namespace may not be set when a resource name is provided") } if (r.verb == "POST") && r.namespaceSet && len(r.namespace) == 0 { return fmt.Errorf("an empty namespace may not be set during creation") } </ins> client := r.client if client == nil { client = http.DefaultClient

Discussion:
Storing r.req / r.resp internally (for use from DoRaw and Do) is probably not the right factoring. There should be a common method doRaw that returns request and body.
Change:
Pod:         st.MakePod().Name("test-prefilter").UID("test-prefilter").Obj(), NumAllNodes: 3, Diagnosis: framework.Diagnosis{ <del> NodeToStatusMap:      framework.NodeToStatusMap{}, </del> <ins> NodeToStatusMap: framework.NodeToStatusMap{ "node1": framework.NewStatus(framework.Unschedulable, "node(s) didn't satisfy plugin(s) [FakePreFilter2 FakePreFilter3] simultaneously"), "node2": framework.NewStatus(framework.Unschedulable, "node(s) didn't satisfy plugin(s) [FakePreFilter2 FakePreFilter3] simultaneously"), "node3": framework.NewStatus(framework.Unschedulable, "node(s) didn't satisfy plugin(s) [FakePreFilter2 FakePreFilter3] simultaneously"), }, </ins> UnschedulablePlugins: sets.Set[string]{}, PreFilterMsg:         "node(s) didn't satisfy plugin(s) [FakePreFilter2 FakePreFilter3] simultaneously", },

Discussion:
When PreFilter returns UnschedulableAndUnresolvable, we don't need to run the preemption, but currently we run. This unexpected preemption could cause errors from the preemption by trying to read non-exist PreFilter data. As pointed out (), actually we didn't run the preemption in such cases in the past versions, but introduced this bug. /kind bug /kind regression /sig scheduling /triage accepted /priority important-soon
/assign
will fix this.
Change:
tolerations: - key: "CriticalAddonsOnly" operator: "Exists" <ins> - operator: "Exists" effect: "NoExecute" - operator: "Exists" effect: "NoSchedule" </ins> nodeSelector: kubernetes.io/os: linux containers:

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 --Konnectivity Service gets evicted when node gets tainted with NoExecute. Just like CoreDNS and KubeProxy, Konnectivity-agent should not get evicted when Node gets a taint. Have a port-forward running from a service and taint a node with a NoExecute option. Konnectivity-agent is deleted and can't get scheduled on the Node again until taint is removed. All other system pods use a wildcard toleration and are not effected by node taints. Kubernetes version (use ): 1.19.11 Cloud provider or hardware configuration: Azure OS (e.g: ): Ubuntu Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
As I know, only kube-proxy tolerates NoExecute. coredns does not. konnectivity agent's setting is same as coredns.
/cc Like dns-node-cache and kube-proxy, daemonset seems to have the toleration. /assign kubeadm kube-proxy is using below.
/sig cloud-provider
/assign
GitHub didn't allow me to assign the following users: jkh52. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign 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
As long as this stays DaemonSet, these broader tolerations seem acceptable. With GKE we have switched to Deployment, and intentionally do not have these broad tolerations (to avoid poor interaction with cluster-autoscaler).
/triage accepted
Change:
cp -a "${SERVER_BINARY_TAR}" ${local_dir} cp -a "${SALT_TAR}" ${local_dir} <del> aws s3 sync --exact-timestamps ${local_dir} "s3://${AWS_S3_BUCKET}/${staging_path}/" </del> <ins> aws s3 sync --region ${s3_bucket_location} --exact-timestamps ${local_dir} "s3://${AWS_S3_BUCKET}/${staging_path}/" </ins> <del> aws s3api put-object-acl --bucket ${AWS_S3_BUCKET} --key "${server_binary_path}" --grant-read 'uri="http://acs.amazonaws.com/groups/global/AllUsers"' </del> <ins> aws s3api put-object-acl --region ${s3_bucket_location} --bucket ${AWS_S3_BUCKET} --key "${server_binary_path}" --grant-read 'uri="http://acs.amazonaws.com/groups/global/AllUsers"' </ins> SERVER_BINARY_TAR_URL="${s3_url_base}/${AWS_S3_BUCKET}/${server_binary_path}" local salt_tar_path="${staging_path}/${SALT_TAR##*/}" <del> aws s3api put-object-acl --bucket ${AWS_S3_BUCKET} --key "${salt_tar_path}" --grant-read 'uri="http://acs.amazonaws.com/groups/global/AllUsers"' </del> <ins> aws s3api put-object-acl --region ${s3_bucket_location} --bucket ${AWS_S3_BUCKET} --key "${salt_tar_path}" --grant-read 'uri="http://acs.amazonaws.com/groups/global/AllUsers"' </ins> SALT_TAR_URL="${s3_url_base}/${AWS_S3_BUCKET}/${salt_tar_path}" }

Discussion:
When I run: I get the following error: Waiting a bit and running got past this point because the bucket was ready the second time around, but the getting-started process should be more robust.
I experienced the same issue
We do try to query for the bucket existing, but perhaps S3 is even more eventually consistent than I thought! I did observe that we were very trusting about the user providing the correct S3 region, and have tried to fix this in . I don't think that was the problem here though (if you make_bucket, you can't have a region mismatch...) I guess we could retry the sync a few times; might help with e.g. a network interruption during the sync also.
I believe this to have been fixed by . I'm going to close, but if it happens again please do reopen.
FYI I got this with the latest k8s as of 10/13/15: I believe this is k8s 1.0.6 but I just tore down my AWS cluster and apparently kubectl needs to talk to the now-terminated master instance. I ran to get k8s. Waiting and running again doesn't show the issue since the bucket is fully created and accessible. I just provisioned a Vagrant cluster in hopes that would help show what version I'm using. Here's the output of :
Change:
// ReplicationController represents the configuration of a replication controller. type ReplicationController struct { <del> TypeMeta   `json:",inline"` </del> <ins> TypeMeta `json:",inline"` // If the Labels of a ReplicationController are empty, they are defaulted to be the same as the Pod(s) that the replication controller manages. </ins> ObjectMeta `json:"metadata,omitempty" description:"standard object metadata; see https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/api-conventions.md#metadata"` // Spec defines the desired behavior of this replication controller.

Discussion:
It doesn't make sense to define pod template with a set of labels that is strict subset of replicaSelector (or at least I can't find an use-case). For that reason I think that the labels in pod template part of replication controller should be optional and user should care about them only if he wants to define a superset of what replicaSelector already defines.
I've heard the same comments from a client. I think that it'd be more intuitive if we always specify pod labels in the template (so that we can copy&paste pod definition), and replicaSelector is optional (by default pod labels).
It would be reasonable for the selector to be a subset. I'm fine with intelligent defaulting but we need to be careful not to conflate the 2 concepts, which I think would increase the amount of confusion.
Setting RC selector from pod template labels SGTM. Any concerns It wouldn't have to work with separate templates, though it would be desirable if it did. It would be nice if we could add preconditions based on other objects (resource version of pod template in this case) to etcd transactions.
I think we agreed in another issue that defaulting the selector from the pod template labels is reasonable. No argument from me. One problem with pod templates is that we lose the strict relationship between selector and template, so if you change the template the RC needs to behave intelligently (I refuse to create more pods because the template selector doesn't match mine, etc)
We should do this, and we should default replicas to 1. We could also consider defaulting replication controller labels from pod template labels. That way, essentially the only thing that would need to be specified for a singleton RC would be the pod template.
I don't think we can default replicas to 1, since we can't tell the difference between an explicit zero and a default zero, and I think there are lots of reasonable cases where you want to set replicas == 0 on create. (esp. in the context of socket activation)
Responded on the PR: We can distinguish default from 0 if we make it a pointer.
Change:
1 /* expectedSetUpCallCount */, testKubelet.volumePlugin)) // Remove pod <del> kubelet.podWorkers.(*fakePodWorkers).removeRuntime = map[types.UID]bool{pod.UID: true} </del> <ins> kubelet.podWorkers.(*fakePodWorkers).setPodRuntimeBeRemoved(pod.UID) </ins> kubelet.podManager.SetPods([]*v1.Pod{}) assert.NoError(t, waitForVolumeUnmount(kubelet.volumeManager, pod))

Discussion:
pull-kubernetes-unit TestVolumeUnmountAndDetachControllerDisabled It failed on but after that the test is passing DATA RACE It seems that the data race is caused by below code It failing of test is Flaky, it was not reproducible on my local machine too, I have used below command to run the test output on my local machine I would like to work on this issue, is it possible to reproduce this issue locally?
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 testing
SIG Testing owns test frameworks, CI infrastructure, and other things to support testing. But this test is owned by SIG storage I believe since it tests their code, as we own tests that test our code.
Change:
} }) <ins> // quick validation of udp, next test confirms that this services update as well after endpoints are removed, but is slower. ginkgo.It("should support basic nodePort: udp functionality", func() { config := e2enetwork.NewNetworkingTestConfig(f, true, false) ginkgo.By(fmt.Sprintf("dialing(udp) %v (node) --> %v:%v (nodeIP) and getting ALL host endpoints", config.NodeIP, config.NodeIP, config.NodeUDPPort)) err := config.DialFromNode("udp", config.NodeIP, config.NodeUDPPort, config.MaxTries, 0, config.EndpointHostnames()) if err != nil { framework.Failf("Failure validating that nodePort service WAS forwarding properly: %v", err) } }) </ins> // Slow because we confirm that the nodePort doesn't serve traffic, which requires a period of polling. ginkgo.It("should update nodePort: udp [Slow]", func() { config := e2enetwork.NewNetworkingTestConfig(f, true, false)

Discussion:
What happened: In CAPA clusters, NodePorts are disabled for UDP but not for TCP, so when testing, we see a small hole in coverage that was luckily caught by the tests.... So, I noticed that we thus don't have a targetted ginkgo test for UDP + nodeports, but we do seem to have the Contract one, which I guess tests two things at once: UDP NodePort service works Conntrack can persist the service We do have but this test is obviously testing many other things as well. So, would like to have a test.... What you expected to happen: running the sig-network test suite, while skipping with UDP not working would result in a test failure specific to UDP and NodePorts. How to reproduce it (as minimally and precisely as possible): Run the test suite, skip , with a UDP firewall up - you'll see no relevant failures. Anything else we need to know?: Environment: Kubernetes version (use ): master
/sig network
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
There is already one testing NodePort UDP in
However, the more tests the better :+1:
Hiya Antonio. I think the one your talking about in granular checks is also tagged as "Slow"..... Is there a FAST one? If so I'll close this issue don't want to make a redundant test . :)
I honestly don't know the history of the Slow tag and I don't see it consistently applied, but if you think that you can improve the Granular check and have an additional faster test, then just go for it :muscle:
ok cool
Change:
CLEANUP=true GINKGO_FLAGS='--skip="[Flaky]|[Slow]|[Serial]"' SETUP_NODE=false <del> TEST_ARGS=--cgroups-per-qos=true </del> <ins> TEST_ARGS=--cgroups-per-qos=false </ins>

Discussion:
In node-e2e-test on Containervm image, the containers of the pods created by Kubernetes are subcontainers of docker-daemon/docker/. It means that the runtime resource usage (docker-daemon) is not correct, because all pods are included. This problem maybe due to container misconfiguration in node-e2e-test.
The kubelet on debian-based containervm image is misconfigured. Will fix it shortly.
Change:
func PodToSelectableFields(pod *api.Pod) labels.Set { return labels.Set{ "name":         pod.Name, <del> "Status.Phase": string(pod.Status.Phase), "Status.Host":  pod.Status.Host, </del> <ins> "status.phase": string(pod.Status.Phase), "status.host":  pod.Status.Host, </ins> } }

Discussion:
We use capitals for Pod fields (ex: Status.Host) and camelCase for Event fields (ex: involvedObject.resourceVersion). We should be consistent. Should it be capitals? camelCase? Or should we be case insensitive?
IMO, we should use camelCase for pod fields, to match the way it's serialized in JSON.
I agree with The goal here is to be consistent with the API, not with the internal Go representation.
I'd like to fix this before v1beta3 is cast in stone.
ok. Event field selectors are correct then. I will update the selectors for pods to make them camelCase.
I am wondering if I should change this only for v1beta3 or for 1 and 2 as well? This will be a breaking change for beta1 and 2 if we decide to do that.
v1beta3 only, though that's hard, we should reconsider. We're contemplating another "breakage day", and I doubt this is widely used.