jiebi/CodeConvo huggingface dataset:
Code change:
) decoder := opts.StorageSerializer.DecoderToVersion( recognizer.NewDecoder(decoders...), <del> runtime.NewMultiGroupVersioner( </del> <ins> runtime.NewCoercingMultiGroupVersioner( </ins> opts.MemoryVersion, schema.GroupKind{Group: opts.MemoryVersion.Group}, schema.GroupKind{Group: opts.StorageVersion.Group},

Related discussion:
text: What happened: Set up a HA cluster with 1.9 and 1.10 API servers (occurs on any apiserver skew boundary where a cohabitating resource's storage version changed groups) Observed errors when modifying workload objects: when modified via the 1.10 server, saw this error in the 1.9 server: when modified via the 1.9 server, saw this error in the 1.10 server: When this error was encountered, all watchers for the resource in question would be dropped and have to re-establish, and the internal watchers feeding the watch cache would drop and re-establish What you expected to happen: Watch events from all supported storage versions are processed correctly How to reproduce it (as minimally and precisely as possible): Start a server from master (for inspectability, store in json). With Create a deployment (e.g. kube-dns in kube-system) Establish a watch via extensions (kubectl get deployments.extensions --all-namespaces -w) Establish a watch via apps (kubectl get --all-namespaces -w) Tail the kube-apiserver log Change the apps/v1 deployment in etcd to extensions/v1beta1: Observer client watches drop and server log errors: 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: /sig api-machinery /cc /priority critical-urgent
error is triggered by this returning false: constructed here: the info about expected cohabitating groups is not included in the list of acceptable inputs
Code change:
} func testZonalFailover(c clientset.Interface, ns string) { <del> nodes := framework.GetReadySchedulableNodesOrDie(c) nodeCount := len(nodes.Items) </del> cloudZones := getTwoRandomZones(c) class := newRegionalStorageClass(ns, cloudZones) claimTemplate := newClaimTemplate(ns)

Related discussion:
text: <!-- 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: Testgrid: https://k8s-
/assign
The test's assumption about test parameter is wrong. Previously it assumed the group name is the same across all zones, but they are different in regional clusters. Looking into using node taints as the permanent fix, as suggested by the TODO comment in the test.
Hm I think taint based evictions is still an alpha feature.
OK. I propose the following solution: Get the zone of Schedule the StatefulSet pod to that zone using node affinity; wait for the pod to run Remove the node affinity from StatefulSet Delete
Can it be simplified? Schedule the pod Figure out which zone that pod got scheduled in Delete the instance group of that zone
Unfortunately I don't know of a good way to look up the instance group given the zone, since there could be instance groups from multiple clusters in the same project
How about: Schedule the pod Figure out the zone Taint all the nodes in the zone Kill the pod
Taint with NoSchedule? yeah that sounds good
Code change:
if err != nil { return nil, err } <del> minion, err := rs.registry.GetMinion(ctx, minion.Name) </del> <ins> minionName := minion.Name minion, err := rs.registry.GetMinion(ctx, minionName) if err == ErrNotHealty { return rs.toApiMinion(minionName), nil } </ins> if minion == nil { return nil, ErrDoesNotExist }

Related discussion:
text: apiserver reports creation failure if a node is not ready (unhealthy, or kubelet is not ready), but the api object is already stored in master. extracted from and A short term solution is to have health_registry check node health upon creation, not just on retrieving. Or ignore unhealthy node. A long term solution might fall into the interface revamp
Why can't apiserver accept an unhealthy minion.
What's the point of having an unhealthy minion that we'll never be able to use? One reason I can think of is that the minion can later becomes healthy and thus a valid node in k8s. But for now, as we don't have the ability to handle unhealthy node, delegate the responsibility to user makes more sense. However, I admit the title is misleading. What I really what to convey is that kubernetes currently allow registrying unhealthy node, by storing it in RESTStorage. But the create operation reports fail because the node can't pass health checking. I don't think this is the right behavior. We can either return success and do health check later, or return failure and do not store it. (i prefer the latter one for the above reason).
I tend to think that we should accept unhealthy minions - minions may go in and out of health, or go up and down at any time - so trying ensure health at registration time seems like a fruitless effort since we have to handle the error cases anyway.
I've no problem with accepting unhealthy minions, and I agree with your point. The real problem here is that the apiserver returns an inconsistent status. For example, if I have an unhealthy minion that I want to registry. From user's perspective, the registration fails, because apiserver returns an error (resource not found). So I retry, but apiserver returns failure again; this time, the error is resource already exists, no matter the minion is healthy or not.
- yes, we should remove the health check as part of the registration and just report success. agree there is inconsistency.
+1 On Nov 7, 2014 8:48 AM, "Derek Carr" wrote:
Seems like it's a clients responsibility to warn the user that a node might not be available prior to it being , but the the master's responsibility to assume that all properly specified nodes are reachable before making decisions regarding using a node.
Code change:
if err != nil { return nil, err } <del> minion, err := rs.registry.GetMinion(ctx, minion.Name) </del> <ins> minionName := minion.Name minion, err := rs.registry.GetMinion(ctx, minionName) if err == ErrNotHealty { return rs.toApiMinion(minionName), nil } </ins> if minion == nil { return nil, ErrDoesNotExist }

Related discussion:
text: There's very little difference between an admin stopping a VM without clearing Kube and adding a node to the cluster prior to it being fully reachable (I think).
"clients responsibility" ? if we enable kubectl to create minions, it would be kubectl who should check if the minion is reachable and complain? I'm not sure what 'client' means. (but I agree 100%, don't report failure adding a minion just because it isn't reachable)
node controller plugin should also give warning
Code change:
defer nodePortOp.Finish() // try set ip families (for missing ip families) <del> if err := rs.tryDefaultValidateServiceClusterIPFields(service); err != nil { </del> <ins> if err := rs.tryDefaultValidateServiceClusterIPFields(oldService, service); err != nil { </ins> return nil, false, err }

Related discussion:
text: 1) start with a single stack cluster 2) create a PreferDualStack service 3) configure API server with a 2nd service CIDR 4) Confirm the above service is not dual-stack 5) Add a label to the above service 6) Observe that the service becomes dual-stack I think the correct answer is to have a "repair loop" that upgrades (and downgrades!) PreferDualStack Services to match the config. I think this is a GA blocker.
/triage accepted The current thought is: of type with are special new breed of api objects that I don't think we have any similar precedent in the apis, i could be wrong. Their behavior is tied to how the cluster is configured. Thus their behavior must change as the cluster behavior change. a way the user is stating . If it is cluster then i am good with two ClusterIPs. If it is single stack cluster then I am also good with a single ClusterIP. One can assume that if the user was ok was with getting a additional IP when possible then they must be ok with taking it away when it is no longer possible. Based on the above I believe best course of action is create a new repair loop or piggyback on any of the existing (or better: fix it in rest stack during list and get calls). The new logic takes care of matching to the .
reproducer and regression test if somebody takes this, feel free to add it
ack - Scheduled to tackle 3rd week of May. Will definitely include that patch.
Code change:
} /* <del> Testname: allowPrivilegeEscalation unset and uid != 0. Description: Configuring the allowPrivilegeEscalation unset, allows the privilege escalation operation. A container is configured with allowPrivilegeEscalation not specified (nil) and a given uid which is not 0. When the container is run, the container is run using uid=0. This test is marked LinuxOnly since Windows does not support running as UID / GID, or privilege escalation. </del> <ins> Release : v1.15 Testname: Security Context, allowPrivilegeEscalation unset, uid != 0. Description: Configuring the allowPrivilegeEscalation unset, allows the privilege escalation operation. A container is configured with allowPrivilegeEscalation not specified (nil) and a given uid which is not 0. When the container is run, container's output MUST match with expected output verifying container ran with uid=0. This e2e Can not be promoted to Conformance as it is Container Runtime dependent and not all conformant platforms will require this behavior. [LinuxOnly]: This test is marked LinuxOnly since Windows does not support running as UID / GID, or privilege escalation. </ins> */ It("should allow privilege escalation when not explicitly set and uid != 0 [LinuxOnly] [NodeConformance]", func() { podName := "alpine-nnp-nil-" + string(uuid.NewUUID())

Related discussion:
text: Which would you suggest is the best orientation to overcome the privilege mode setting and allow its promotion? Michelle Au If my understanding is correct, on some platforms, writing to /tmp requires privileged. I don't see a way to to remove that requirement.
If my understanding is correct, on some platforms, writing to /tmp requires privileged. I don't see a way to to remove that requirement. Yeah writing to host doesn't seem like a thing we can expect of conformance tests. I wonder if it makes sense to tag this test with something to denote the requirement, ie: I see some tests in test/e2e_node use
The hostpath tests in already have a comment explaining this. Maybe the comment should be updated to be more clear that that is the reason why we can't add it to conformance.
That's /tmp on the host or in the container filesystem?
/tmp on the host
ping what else remains to be done before we close this out? I am guessing that we want to close , is there anything beyond that?
Once tests under (issue- ) and are promoted we are good to close this issue. Short update for reference- None of [NodeConformance] tests from "test/e2e_node" seems eligible for [Conformance] promotion at this moment due to node level dependencies. Remaining [NodeConformance] tests from "test/e2e" has following status - Waiting for to be closed and then below tests would be promoted to Conformance Needs to be Promoted Can not be promoted to Conformance as //Slow by design Can not be promoted due to Node level dependency
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
/lifecycle frozen
/assign
Code change:
List<InetAddress> list = new ArrayList<InetAddress>(); String host = "https://kubernetes.default.cluster.local"; String serviceName = getEnvOrDefault("CASSANDRA_SERVICE", "cassandra"); <del> String path = "/api/v1/namespaces/default/endpoints/"; </del> <ins> String podNamespace = getEnvOrDefault("POD_NAMESPACE", "default"); String path = String.format("/api/v1/namespaces/%s/endpoints/", podNamespace); </ins> try { String token = getServiceAccountToken();

Related discussion:
text: The namespace seems to be hard coded :
cc:
Thanks. We can improve it after v1 release.
Code change:
cachedCreds *credentials exp         time.Time <del> onRotate func() </del> <ins> onRotateList []func() </ins> } type credentials struct {

Related discussion:
text: <!-- 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: Data race in client-go with below sample code: Data race: What you expected to happen: No data race How to reproduce it (as minimally and precisely as possible): Using above given sample code Kubernetes version (use ):Cloud provider or hardware configuration:OS (e.g: ): OSX
/sig api-machinery
I'd like to take it. /assign
/remove-sig api-machinery /sig auth cli
Bug triage for release 1.17 here. Since this issue has been tagged for the milestone, we would like to check it's status. Code freeze is on Nov. 14. Will this issue be resolved before then?
Another reminder here that code freeze is in less than two weeks (Nov. 14). We will need to move this issue out of the milestone if isn't going to be resolved before then.
Code change:
#     sleep 4 #     i=$[$i+1] #   done <del> apiVersion: v1beta1 </del> <ins> apiVersion: v1beta3 </ins> kind: Pod <del> id: synthetic-logger-0.25lps-pod desiredState: manifest: version: v1beta1 id: synth-logger-0.25lps containers: - name: synth-lgr image: ubuntu:14.04 command: ["bash", "-c", "i="0"; while true; do echo -n "`hostname`: $i: "; date --rfc-3339 ns; sleep 4; i=$[$i+1]; done"] labels: name: synth-logging-source </del>  No newline at end of file <ins> metadata: labels: name: synth-logging-source name: synthetic-logger-0.25lps-pod spec: containers: - args: - bash - -c - 'i="0"; while true; do echo -n "`hostname`: $i: "; date --rfc-3339 ns; sleep 4; i=$[$i+1]; done' image: ubuntu:14.04 name: synth-lgr </ins>

Related discussion:
text: Hi , I followed the instructions in examples/logging-demo, and there was no "external IP" field for elasticsearch-logging or kibana-logging, as shown below: I start up my cluster via cluster/kube- Did I miss something or is it a bug? Thanks.
Correct. This demo does not create an ELB so there is no external IP address. Access is via service proxy at the master. Type: and you should see the URLs for Elasticsearch and Kibana.
please let us know whether: a. Satnam's comment resolves your issue b. the demo should be updated to prevent this misunderstanding c. the issue isn't resolved Thank you!
Yes, Satnam's comment resolve the issue. I updated the demo in .
Awesome, thanks for sending the patch! We'll discuss there. Always fantastic to have docs updated regularly by folks trying them.
Code change:
type PredicateFailureError struct { PredicateName string <ins> PredicateDesc string </ins> } <del> func newPredicateFailureError(predicateName string) *PredicateFailureError { return &PredicateFailureError{PredicateName: predicateName} </del> <ins> func newPredicateFailureError(predicateName, predicateDesc string) *PredicateFailureError { return &PredicateFailureError{PredicateName: predicateName, PredicateDesc: predicateDesc} </ins> } func (e *PredicateFailureError) Error() string {

Related discussion:
text: <!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind feature The is not user friendly. There has been to make it better, but we still print in the pending message. We should change these errors to a more human readable message. For example, should be changed to something like . /sig scheduling
Code change:
awsServices := newMockedFakeAWSServices(TestClusterId) c, _ := newAWSCloud(strings.NewReader("[global]"), awsServices) <del> sg1 := "sg-000001" sg2 := "sg-000002" </del> <ins> sg1 := map[string]string{ServiceAnnotationLoadBalancerExtraSecurityGroups: "sg-000001"} sg2 := map[string]string{ServiceAnnotationLoadBalancerExtraSecurityGroups: "sg-000002"} sg3 := map[string]string{ServiceAnnotationLoadBalancerExtraSecurityGroups: "sg-000001, sg-000002"} </ins> tests := []struct { name string <del> extraSGsAnnotation string expectedSGs        []string </del> <ins> annotations map[string]string expectedSGs []string </ins> }{ <del> {"No extra SG annotation", "", []string{}}, {"Empty extra SGs specified", ", ,,", []string{}}, {"SG specified", sg1, []string{sg1}}, {"Multiple SGs specified", fmt.Sprintf("%s, %s", sg1, sg2), []string{sg1, sg2}}, </del> <ins> {"No extra SG annotation", map[string]string{}, []string{}}, {"Empty extra SGs specified", map[string]string{ServiceAnnotationLoadBalancerExtraSecurityGroups: ", ,,"}, []string{}}, {"SG specified", sg1, []string{sg1[ServiceAnnotationLoadBalancerExtraSecurityGroups]}}, {"Multiple SGs specified", sg3, []string{sg1[ServiceAnnotationLoadBalancerExtraSecurityGroups], sg2[ServiceAnnotationLoadBalancerExtraSecurityGroups]}}, </ins> } awsServices.ec2.(*MockedFakeEC2).expectDescribeSecurityGroups(TestClusterId, "k8s-elb-aid", "cluster.test")

Related discussion:
text: The reason for what we expect is that we have tight security constraints that require us to fine tune the IAM policies for the Instance profiles that the controllers use. With a statically named tag we were able, in 1.5, to restrict the permissions in the IAM policy to act only on the k8s managed resources (ELBs, security groups). Here is the relevant part of the IAM policy: Environment: Kubernetes version (use ):OS (e.g. from /etc/os-release):Others: </details
I believe they are moving away from the tag since there are many resources that can be shared by multiple clusters. could you use an annotation?
We removed the condition in roles in the end. Thank you for your suggestion.
That annotation affects the ELB but not any security groups that are created. can you please reopen this? You reported a real issue, and even if it no longer affects you, it needs to be tracked and fixed.
Indeed, this might be a feature that someone else would need.
In fact, this is a feature I need!
Food for thought: should we propagate the tags on the ELB to the SG, or should we introduce an annotation for the SG specifically?
Code change:
}) } } <ins> func TestConvertToAPIContainerStatusesDataRace(t *testing.T) { pod := podWithUIDNameNs("12345", "test-pod", "test-namespace") testTimestamp := time.Unix(123456789, 987654321) criStatus := &kubecontainer.PodStatus{ ID:        pod.UID, Name:      pod.Name, Namespace: pod.Namespace, ContainerStatuses: []*kubecontainer.Status{ {Name: "containerA", CreatedAt: testTimestamp}, {Name: "containerB", CreatedAt: testTimestamp.Add(1)}, }, } testKubelet := newTestKubelet(t, false) defer testKubelet.Cleanup() kl := testKubelet.kubelet // convertToAPIContainerStatuses is purely transformative and shouldn't alter the state of the kubelet // as there are no synchronisation events in that function (no locks, no channels, ...) each test routine // should have its own vector clock increased independently. Golang race detector uses pure happens-before // detection, so would catch a race condition consistently, despite only spawning 2 goroutines for i := 0; i < 2; i++ { go func() { kl.convertToAPIContainerStatuses(pod, criStatus, []v1.ContainerStatus{}, []v1.Container{}, false, false) }() } } </ins>

Related discussion:
text: What happened: One pod stuck at CreateContainerError and can't get recovered automatically. Kubelet log shows that the requested name (let's say Container2) is already in use. shows the Container2 Running, and it's created before Container1 This should never happen. How to reproduce it (as minimally and precisely as possible): I wish i knew. Anything else we need to know?: I know this can be caused by time shifting, but I didn't find any time shifting sign in system log and chrony log, and there is no rebooting between the create timestamp of Container1 and Container2, so this should be caused by something else. This happens intermittently in our env, like 3 times in half a year, and I didn't find any ime shifting sign each time. Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.6", GitCommit:"", GitTreeState:"clean", BuildDate:"2019-11-13T11:20:18Z", GoVersion:"go1.12.12", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.6", GitCommit:"", GitTreeState:"clean", BuildDate:"2020-08-28T11:18:26Z", GoVersion:"go1.12.12", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: OS (e.g: ): CentOS Linux release 7.5.1804 (Core) Kernel (e.g. ): Linux node-1 3.10.0-957.21.3.el7.x8664 SMP Wed Jul 17 06:57:50 UTC 2019 x8664 x8664 x86_64 GNU/Linux Install tools: kubeadm Network plugin and version (if this is a network-related bug): Others:
/sig node
Any update on this issue, we are also facing the same issue. EKS version : 1.14.9 Docker version: 19.03.6-ce AWS CNI: 1.6.2 Intermittently we are also facing this , what might the issue, could please guide us here? Below are the kubelet logs. )"
Code change:
}) } } <ins> func TestConvertToAPIContainerStatusesDataRace(t *testing.T) { pod := podWithUIDNameNs("12345", "test-pod", "test-namespace") testTimestamp := time.Unix(123456789, 987654321) criStatus := &kubecontainer.PodStatus{ ID:        pod.UID, Name:      pod.Name, Namespace: pod.Namespace, ContainerStatuses: []*kubecontainer.Status{ {Name: "containerA", CreatedAt: testTimestamp}, {Name: "containerB", CreatedAt: testTimestamp.Add(1)}, }, } testKubelet := newTestKubelet(t, false) defer testKubelet.Cleanup() kl := testKubelet.kubelet // convertToAPIContainerStatuses is purely transformative and shouldn't alter the state of the kubelet // as there are no synchronisation events in that function (no locks, no channels, ...) each test routine // should have its own vector clock increased independently. Golang race detector uses pure happens-before // detection, so would catch a race condition consistently, despite only spawning 2 goroutines for i := 0; i < 2; i++ { go func() { kl.convertToAPIContainerStatuses(pod, criStatus, []v1.ContainerStatus{}, []v1.Container{}, false, false) }() } } </ins>

Related discussion:
text: with CreatePodSandboxError: "CreatePodSandbox for pod "-f0fe-11ea-9872-)" failed: rpc error: code = Unknown desc = failed to create a sandbox for pod "aiqx-server-dep--b9lmv": operation timeout: context deadline exceeded" Sep 07 11:40:40 kubelet[2899]: W0907 11:40:40. 2899 ] No ref for container "docker://7b9c86b529530f15d941f8e68973a202c8f348ab5db864a8371e8c82ddbf9dc4" (r(-e845-11ea-bd96-) Sep 07 11:40:43 kubelet[2899]: W0907 11:40:43. 2899 ] Unable to create pod sandbox due to conflict. Attempting to remove sandbox "a73bd9a03d56bc7855e4e89e163e13c5e7173397f10edcc200fb686e1b6885c8" Sep 07 11:40:43 kubelet[2899]: E0907 11:40:43. 2899 ] Failed to remove the conflicting container "a73bd9a03d56bc7855e4e89e163e13c5e7173397f10edcc200fb686e1b6885c8": Error: No such container: a73bd9a03d56bc7855e4e89e163e13c5e7173397f10edcc200fb686e1b6885c8
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 .