jiebi/CodeConvo huggingface dataset:
Change:
} SetMasterTaintTolerations(&kd.Deployment.Spec.Template.ObjectMeta) <del> SetMasterNodeAffinity(&kd.Deployment.Spec.Template.ObjectMeta) </del> <ins> SetNodeAffinity(&kd.Deployment.Spec.Template.ObjectMeta, MasterNodeAffinity(), NativeArchitectureNodeAffinity()) </ins> return kd }

Discussion:
Right now we create 3 daemonsets for in , but will only give use image names for , so this feature is broken. We should only deploy one daemon set for the native architecture, but ensure it has the right label selectors, so we don't try to run pods on nodes of different architecture. We should also make sure all addons have architecture labels, and not just . If user is building heterogeneous clusters, the will need to take about deploying addons for additional architectures, we shouldn't pre-deploy multiple things knowing that they will most likely remain unschedulable.
I have the same issue as well. I tried to create a cluster with x86 (Intel NUC) and arm (Raspberry-Pi) and I see that the kube-proxy is crashing. Here's the log entry from kube-proxy Logs from kube-proxy exec user process caused "exec format error" Attached is the kube-proxy yaml file. I see that its picking up arm image Don't know how to fix this.
Change:
"self.val1 + self.val2 == [1, 2, 3, 1, 2, 3]", "self.val1 + [4, 5] == [1, 2, 3, 4, 5]", }, <ins> errors: map[string]string{ // Mixed type lists are not allowed since we have HomogeneousAggregateLiterals enabled "[1, 'a', false].filter(x, string(x) == 'a')": "expected type 'int' but found 'string'", }, }, {name: "string lists", obj:    objs([]interface{}{"a", "b", "c"}), schema: schemas(listType(&stringType)), valid: []string{ // Join function "self.val1.join('-') == 'a-b-c'", "['a', 'b', 'c'].join('-') == 'a-b-c'", "self.val1.join() == 'abc'", "['a', 'b', 'c'].join() == 'abc'", }, </ins> }, {name: "listSets", obj:    objs([]interface{}{"a", "b", "c"}, []interface{}{"a", "c", "b"}),

Discussion:
Added this test to : this resulted in: The test should pass. Add the above test No response All versions where CEL is used. All Doesn't matter No response No response No response_
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
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
Opened to discuss the expected behavior in cel-go for this.
Change:
}, expectedElements: []string{"test", "State", "Terminated", "Ready", "True", "Restart Count", "7", "Image", "image", "Reason", "potato", "Started", "Finished", "Exit Code", "2"}, }, <ins> // Last Terminated { container: api.Container{Name: "test", Image: "image"}, status: api.ContainerStatus{ Name: "test", State: api.ContainerState{ Running: &api.ContainerStateRunning{ StartedAt: util.NewTime(time.Now()), }, }, LastTerminationState: api.ContainerState{ Terminated: &api.ContainerStateTerminated{ StartedAt:  util.NewTime(time.Now().Add(time.Second * 3)), FinishedAt: util.NewTime(time.Now()), Reason:     "crashing", ExitCode:   3, }, }, Ready:        true, RestartCount: 7, }, expectedElements: []string{"test", "State", "Terminated", "Ready", "True", "Restart Count", "7", "Image", "image", "Started", "Finished", "Exit Code", "2", "crashing", "3"}, }, </ins> // No state defaults to waiting. { container: api.Container{Name: "test", Image: "image"},

Discussion:
Problem When a container is killed and restarted because, for example, it hit memory limits, the output only shows an increasing but no reason for why the container was killed: We can find the reason by inspecting the pod object ( shows as with ): Suggested Solution Modify to print termination reason, if available.
When this merges, need to update Search for in that doc.
Solved with .
Change:
echo -e "${color_yellow}Attempt ${attempt} failed to create instance template $template_name. Retrying.${color_norm}" >&2 attempt=$(($attempt+1)) sleep $(($attempt * 5)) <ins> # In case the previous attempt failed with something like a # Backend Error and left the entry laying around, delete it # before we try again. gcloud compute instance-templates delete "$template_name" --project "${PROJECT}" &>/dev/null || true </ins> else break fi

Discussion:
My reading is that the first attempt to create e2e-gce-minion-template looks like it failed with "Backend error", but it seems that the template was actually created, so subsequent attempts failed because it already existed.
From kubernetes-e2e-gce/ claims to have deleted: But it apparently wasn't. Looks like we need to improve handling of this: cc There were previous attempts to make instance template more robust, such as in .
And, after this failed, the subsequent test run failed the leaked-resource check.
Ha, an old TODO strikes again. :)
It's actually pretty disturbing that claimed when it wasn't. There may be an internal bug here, since the name should be available for use if delete occurred, in theory.
Do you think someone from your team could take a look at this one?
It sounds like the hypothesis is that the delete failed in , but gcloud reported 'deleted'. But the failure message from the first create operation in is one I haven't seen before: reads to me as "something went wrong, I don't know the state of the world". It looks like the template was created OK (ish), but we try recreating with the same name which then fails (as expected). Is there evidence that the delete actually failed in ? My inclination would be that we should have a retry loop that looks more like: (That is go-bash; neither go nor bash. Just be grateful there's no salt in there!)
- can you take a look at this one this morning?
I was out this morning but I'll see if I can look into it later this afternoon.
ping
This just happened again: I'm going too apply P0 label to the PR that is supposed to fix it.
Ah, this is the same as . We created an internal bug for this too, ref .
Change:
var secondaryServiceIPRange net.IPNet // process secondary range only if provided by user if s.SecondaryServiceClusterIPRange.IP != nil { <del> secondaryServiceIPRange, _, lastErr = master.DefaultServiceIPRange(s.SecondaryServiceClusterIPRange) </del> <ins> secondaryServiceIPRange, _, lastErr = master.ServiceIPRange(s.SecondaryServiceClusterIPRange) </ins> if lastErr != nil { return }

Discussion:
API server defaults the service CIDR. We should instead just fail if it is not specified. Defaulting is a wild guess and very likely to be wrong. /sig network /kind bug
For existing clusters that don't currently set it, is setting it to anything other than the current default a breaking change?
Yes. You can not really change it (well, you can expand it, but not totally move it), unless you delete ALL services, including kubernetes.default. I filed this aspirationally. It's not on fire, it's just a dumb thing to have provided a default for.
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved
Those labels are not set on the issue: <detailsIn response to : /remove-triage unresolved 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:
assert.Equal(t, test.expected, real, test.name) } } <ins> func TestIsNodeUnmanagedByProviderID(t *testing.T) { tests := []struct { providerID string expected   bool name       string }{ { providerID: CloudProviderName + ":///subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroupName/providers/Microsoft.Compute/virtualMachines/k8s-agent-AAAAAAAA-0", expected:   false, }, { providerID: CloudProviderName + "://", expected:   true, }, { providerID: ":///subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroupName/providers/Microsoft.Compute/virtualMachines/k8s-agent-AAAAAAAA-0", expected:   true, }, { providerID: "aws:///subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroupName/providers/Microsoft.Compute/virtualMachines/k8s-agent-AAAAAAAA-0", expected:   true, }, { providerID: "k8s-agent-AAAAAAAA-0", expected:   true, }, } az := getTestCloud() for _, test := range tests { isUnmanagedNode := az.IsNodeUnmanagedByProviderID(test.providerID) assert.Equal(t, test.expected, isUnmanagedNode, test.providerID) } } </ins>

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?: /kind bug What happened: When creating a Kubernetes 1.12.1 cluster in Azure with Availability Set backed masters and VMSS backed agents, the cloud-controller-manager is unable to parse the ProviderID returned by the Azure SDK. What you expected to happen: The providerID should be split and the cloud-controller-manager should be able to find a kubelet node IP from the cloud provider How to reproduce it (as minimally and precisely as possible): Stand up a master node in Azure within an availability set with the kubelet configured with Run the configured for Azure Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: Azure OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/sig azure
When switching over to vmType the following was encountered;
The fix in resolved the issue that was seen in this issue, closing
Change:
ETCD_DOWNLOAD_URL= "https://github.com/coreos/etcd/releases/download/v${ETCD_VERSION}/etcd-v${ETCD_VERSION}-linux-amd64.tar.gz" <del> # TODO(#33726): switch to dl.k8s.io </del> K8S_CLIENT_DOWNLOAD_URL= <del> "https://storage.googleapis.com/kubernetes-release/release/v${K8S_VERSION}/kubernetes-client-linux-amd64.tar.gz" </del> <ins> "https://dl.k8s.io/v${K8S_VERSION}/kubernetes-client-linux-amd64.tar.gz" </ins> K8S_SERVER_DOWNLOAD_URL= <del> "https://storage.googleapis.com/kubernetes-release/release/v${K8S_VERSION}/kubernetes-server-linux-amd64.tar.gz" </del> <ins> "https://dl.k8s.io/v${K8S_VERSION}/kubernetes-server-linux-amd64.tar.gz" </ins>

Discussion:
We have a new vanity url, , which redirects to the GCS release bucket - e.g. Right now, the https endpoint doesn't work, since isn't in the list of domains on the certificate. Once it works, we should switch all references over to the nicer vanity URL. x-ref
So what it required to make this issues actionable? Where to add this for the certificate?
the issue tracking that is
This needs to be triaged as a release-blocker or not for 1.5
not a release blocker.
Is it appropriate to move this to the next milestone or clear the 1.5 milestone? (and remove the non-release-blocker tag as well)
can this be closed?
I forgot to get to this in 1.6, but it'd still be good to do.
do you want this in v1.7? is there a sig to own this?
doesn't need to block 1.7, no.
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list .
/sig release
Change:
// this new kubelet so reconcile() calls SetUp and re-mounts the // volume if it's necessary. volumeNeedReport = append(volumeNeedReport, reconstructedVolume.volumeName) <ins> if cachedInfo, ok := rc.skippedDuringReconstruction[reconstructedVolume.volumeName]; ok { gvl = cachedInfo } gvl.addPodVolume(reconstructedVolume) </ins> rc.skippedDuringReconstruction[reconstructedVolume.volumeName] = gvl klog.V(4).InfoS("Volume exists in desired state, marking as InUse", "podName", volume.podName, "volumeSpecName", volume.volumeSpecName) continue

Discussion:
This issue is very similar to , they have the same symptom: remote volumes of the pods are becoming local mount point after rebooting the Node. And this issue is triggered by The difference is that in , kubelet didn't call , so the global mount point is local, but it will still call for the pod to bind mount the pod volume to the global mount point. Whereas in this issue, kubelet neither call globally nor call for the pod. This is more harmful: After writing some data to the pod volume, pod can't be deleted because kubelet encounter error while unmounting the pod volume: ! Reproduce steps: a cluster with one Node a deployment with two replicas(say and ) using Non-attachable volume (for example Azurefile) the Node with option (Use force deletion to simulate the situation that mount point was left over before rebooting the Node.) back the Node is always in Running state, however, after rebooting, it won't call and the volume it uses is local volume. should call . As mentioned above. No response <details</details<detailsN/A </details<details</details<details</details<details</details<details</details
Clusters with enabled is not impacted.
/sig node storage (for triage)
/remove-sig node sig-storage please triage this first. Thanks
/triage accepted
Change:
Type=oneshot RemainAfterExit=yes ExecStartPre=/usr/bin/mkdir -p /opt/cni <del> ExecStartPre=/usr/bin/curl --fail --silent --show-error --location --create-dirs --output /opt/downloads/cni.tar.gz https://storage.googleapis.com/kubernetes-release/network-plugins/cni-8a936732094c0941e1543ef5d292a1f4fffa1ac5.tar.gz </del> <ins> ExecStartPre=/usr/bin/curl --fail --silent --show-error --location --create-dirs --output /opt/downloads/cni.tar.gz https://storage.googleapis.com/kubernetes-release/network-plugins/cni-9d5e6e60e79491207834ae8439e80c943db65a69.tar.gz </ins> ExecStart=/usr/bin/tar xf /opt/downloads/cni.tar.gz -C /opt/cni/ - name: kubernetes-download-manifests.service

Discussion:
We should update cni binaries to containernetworking/cni and release binaries for all arches. I do not have push access to the repo, so I guess some googler have to do it.
Thanks. I have this on my plate.
Change:
HardPodAffinitySymmetricWeight: pointer.Int32Ptr(1), HealthzBindAddress:             pointer.StringPtr("0.0.0.0:12345"), MetricsBindAddress:             pointer.StringPtr("0.0.0.0:12345"), <ins> DebuggingConfiguration: componentbaseconfig.DebuggingConfiguration{ EnableProfiling:           &enable, EnableContentionProfiling: &enable, }, </ins> LeaderElection: kubeschedulerconfigv1alpha1.KubeSchedulerLeaderElectionConfiguration{ LeaderElectionConfiguration: componentbaseconfig.LeaderElectionConfiguration{ LeaderElect:       pointer.BoolPtr(true),

Discussion:
What would you like to be : Enable profiling by default in the scheduler. We can do this by defaulting the CC flags to true. Why is this needed: It is useful when debugging the performance of a running cluster. API server already enables profiling by default. /sig scheduling /help /milestone v1.17
/assign /remove-help
Change:
return err } <del> // TODO (verult) retry with exponential backoff, possibly added in csi client library. </del> ctx, cancel := context.WithTimeout(context.Background(), csiTimeout) defer cancel()

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!--What happened: If kubelet plugin registration fails during the registration process, the kubelet never attempts to register the socket again (assuming the error was transient), unless the socket for the driver is deleted & recreated to trigger a new registration. What you expected to happen: Maybe retry with exponential backoff when kubelet plugin registration fails instead of just logging and waiting for another filesystem event like it does today. Of course, if a socket returns a terminal error (does not implement the kubelet plugin registration service, for example), we should not retry. Follow up on /milestone v1.14 /sig storage How to reproduce it (as minimally and precisely as possible): 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: <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
I'd like to work on this issue
/assign
Re opening. was a temporary work around for this. is the permanent fix.
Hello! We are starting Bug Freeze for 1.15. Is this issue still planned on being incorporated into 1.15?
the dependent PR is not yet merged. can we get this in for 1.15?
said that is the "permanent fix." and that has merged. So let's close this out /close
Closing this issue. <detailsIn response to : said that is the "permanent fix." and that has merged. So let's close this out 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:
err = framework.WaitForDeploymentComplete(c, deploy) Expect(err).NotTo(HaveOccurred()) <del> framework.Logf("Checking its ReplicaSet has the right controllerRef") </del> <ins> framework.Logf("Verifying Deployment %q has only one ReplicaSet", deploymentName) rsList := listDeploymentReplicaSets(c, ns, podLabels) Expect(len(rsList.Items)).Should(Equal(1)) framework.Logf("Obtaining the ReplicaSet's UID") orphanedRSUID := rsList.Items[0].UID framework.Logf("Checking the ReplicaSet has the right controllerRef") </ins> err = checkDeploymentReplicaSetsControllerRef(c, ns, deploy.UID, podLabels) Expect(err).NotTo(HaveOccurred()) <del> framework.Logf("Deleting Deployment %q and orphaning its ReplicaSets", deploymentName) </del> <ins> framework.Logf("Deleting Deployment %q and orphaning its ReplicaSet", deploymentName) </ins> err = orphanDeploymentReplicaSets(c, deploy) Expect(err).NotTo(HaveOccurred())

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Deployment's collision avoidance mechanism assumes that if a replicaset's PodTemplateSpec is semantically deep equal with the deployment's PodTemplateSpec, then the replicaset is the new replicaset for the deployment. This assumption does not take into account the case when the user updates only a field of the replicaset that does not reside within the replicaset's PodTemplateSpec, in which the collision avoidance mechanism should also be triggered. What you expected to happen: The collision avoidance mechanism should be triggered when a non-PodTemplateSpec field (e.g., field) of the replicaset is changed. After making changes to (), the e2e test can be elaborated () to verify the mechanism works as expected. How to reproduce it (as minimally and precisely as possible): a Deployment for ReplicaSet and its Pod(s) to become ready a non-PodTemplateSpec field of the ReplicaSet that Deployment does not create a new ReplicaSet /sig apps /cc
To clarify, we don't actually care about RS label changes in this case. What we do care about is the change of ownership between Deployment and its RSes.
Update description of the issue. Tell me if it is still confusing.
Thanks for pointing to the e2e test.
Change:
for _, minion := range list { status, err := health.Check(h.makeMinionURL(minion), h.client) if err != nil { <del> return result, err </del> <ins> glog.Errorf("%s failed health check with error: %s", minion, err) continue </ins> } if status == health.Healthy { result = append(result, minion)

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 --Exclude node from LoadBalancer (via kubectl label node node1) leads to failing reconciliation of the existing load balancer services in the cluster with following error: The legacy provider azure is not using an AvailablilitySet as it it running with those cloudprovider config: Creating new load balancer services have the effect that they are stuck in due to same issue. Service reconciliation should succeed. Create an Azure k8s cluster with with an Azure cloud controller manager based on legacy-cloud-provider azure in the corresponding k8s version Configure the cloud controller manager to use the feature gate Create a service of type LoadBalancer in the cluster and wait until it was created Label a node with Check the cloud-controller-manager logs New load balancer services will now stuck in Pending state Maybe related to but should be fixed with Kubernetes version (use ): Cloud provider or hardware configuration: Azure OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /kind bug /sig cloud-provider /area provider/azure cc
/assign
/triage accepted
/assign
, thanks for the fix. Can you also create a cherry-pick to kubernetes/kubernetes
we hit a similar issue in in-tree provider as well, could you please help cherry-pick the fix to 1.20 and later release? Thanks.
Here are the cherry-picks to k/k:
Change:
ioStreams, _, _, _ := genericclioptions.NewTestIOStreams() cmd := test.cmd(tf, ioStreams) <ins> var recovered interface{} </ins> sawFatal := false func() { defer func() { // Recover from the panic below. <del> _ = recover() </del> <ins> recovered = recover() </ins> // Restore cmdutil behavior cmdutil.DefaultBehaviorOnFatal() }()

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: kubectl drain crashed with panic when apiserver connection disappeared while there were pods that couldn't be evicted/deleted (sorry, the problem is a bit hard to reproduce and the log was lost) What you expected to happen: kubectl drain should exit with a proper error message How to reproduce it (as minimally and precisely as possible): Try kubectl drain multiple times, interrupting the connection during eviction/deletion Anything else we need to know?: The here can be in case if returns an error, and will panic upon accessing : This causes the c Environment: Kubernetes version (use ): The problem is present as of but is also present in earlier versions (I have a fix for this bug)
/priority important-longterm /sig cli