jiebi/CodeConvo huggingface dataset:
Code change:
expectedErrMsg:      fmt.Errorf("getError"), }, { <del> name:                "NodeAddresses should report error if VMSS instanceID is invalid", nodeName:            "vm123456", metadataName:        "vmss_$123", vmType:              vmTypeVMSS, useInstanceMetadata: true, expectedErrMsg:      fmt.Errorf("failed to parse VMSS instanceID %q: strconv.ParseInt: parsing %q: invalid syntax", "$123", "$123"), }, { </del> name:                "NodeAddresses should report error if cloud.vmSet is nil", nodeName:            "vm1", vmType:              vmTypeStandard,

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: If computer name prefix does not match VMSS name, then Azure cloud provider will use VMSS API instead of using metadata service data. This leads to throttling, because every affected kubelet is making API requests. What you expected to happen: Azure cloud provider should use metadata service data instead of calling VMSS API when instance is current. How to reproduce it (as minimally and precisely as possible): Set computer name prefix of the VMSS to something different than default. You should observe Azure provider making requests to the VMSS API rather than using metadata service, which leads to throttling if you have multiple kubelets with this bug. Anything else we need to know?: This is bug was introduced by - returns false even if instance is current, because it expects node name to match VMSS name + instance id, however node name is derived from the computer-name-prefix which can be different than VMSS name. Node name should be matched against , not against . Environment: Kubernetes version (use ): 1.18.x and higher Cloud provider or hardware configuration: azure /sig cloud-provider
/sig cloud-provider
/area provider/azure
CC
/remove-sig cloud-provider /sig cloud-provider (trying to remove the label)
/sig cloud-provider
Thanks for the reporting. Unfortunately, computer name prefix is not included in IMDS, so it can't be used without VMSS API for constructing the NodeName. Would check what could we do to workaround the issue.
Can you memorize the computer name prefix in the first request to the Azure API and then use it for the isCurrentInstance check?
opened to fix the issue. Would you like to have a look?
I can confirm that your change should fix the problem I reported. Do you know if your fix will be to 1.18.x?
is working on the cherry pick
Thank you for quick fix!
Code change:
// GetOldReplicaSets returns the old replica sets targeted by the given Deployment; get PodList and ReplicaSetList from client interface. // Note that the first set of old replica sets doesn't include the ones with no pods, and the second set of old replica sets include all old replica sets. func GetOldReplicaSets(deployment *extensions.Deployment, c clientset.Interface) ([]*extensions.ReplicaSet, []*extensions.ReplicaSet, error) { <del> rsList, err := ListReplicaSets(deployment, rsListFromClient(c)) </del> <ins> rsList, err := ListReplicaSets(deployment, RsListFromClient(c)) </ins> if err != nil { return nil, nil, err }

Related discussion:
text: IMO it feels like a bad practice to have mutating resource handlers. The deletePod handler is used for queueing a Recreate deployment once it has no pods running. It should merely look at the ReplicaSets that have owner refs as opposed to using dc.getReplicaSetsForDeployment. The orphaning/adoption dance is already happening inside the reconcilation loop.
I'd like to work on this
feel free to grab it. I can't assign the issue to you so I'll add myself; ping me on the PR when you have one.
Code change:
klog.V(3).Infof("Pod %q is terminated, but some containers have not been cleaned up: %s", format.Pod(pod), statusStr) return false } <del> // pod's sandboxes should be deleted if len(runtimeStatus.SandboxStatuses) > 0 { var sandboxStr string for _, sandbox := range runtimeStatus.SandboxStatuses { sandboxStr += fmt.Sprintf("%+v ", *sandbox) } klog.V(3).Infof("Pod %q is terminated, but some pod sandboxes have not been cleaned up: %s", format.Pod(pod), sandboxStr) return false } </del> if kl.podVolumesExist(pod.UID) && !kl.keepTerminatedPodVolumes { // We shouldn't delete pods whose volumes have not been cleaned up if we are not keeping terminated pod volumes klog.V(3).Infof("Pod %q is terminated, but some volumes have not been cleaned up", format.Pod(pod))

Related discussion:
text: What happened: It's most visible in the test <img width="323" alt="Screen Shot 2020-05-20 at 6 09 10 PM" src="https://user-"It shows up in kind, kube- and kops jobs The regression was introduced somewhere within , possible culprits are: (FYI (FYI (FYI There are more tests affected, just not as prominently (visually inspecting ) [sig-apps] StatefulSet [] Basic StatefulSet functionality [StatefulSetBasic] should perform rolling updates and roll backs of template modifications with PVCs [sig-apps] StatefulSet [] Basic StatefulSet functionality [StatefulSetBasic] should perform rolling updates and roll backs of template modifications [Conformance] [sig-storage] In-tree Volumes [Driver: nfs] [Testpattern: Inline-volume (default fs)] volumes should store data [sig-storage] In-tree Volumes [Driver: nfs] [Testpattern: Pre-provisioned PV (default fs)] volumes should store data I wasn't sure whether to tag this as kind/regression or not, I'll leave that up to or someone /sig node /sig api-machimery /sig scheduling
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : What happened: It's most visible in the test (FYI (FYI (FYI StatefulSet [] Basic StatefulSet functionality [StatefulSetBasic] should perform rolling updates and roll backs of template modifications with PVCs [sig-apps] StatefulSet [] Basic StatefulSet functionality [StatefulSetBasic] should perform rolling updates and roll backs of template modifications [Conformance] [sig-storage] In-tree Volumes [Driver: nfs] [Testpattern: Inline-volume (default fs)] volumes should store data [sig-storage] In-tree Volumes [Driver: nfs] [Testpattern: Pre-provisioned PV (default fs)] volumes should store data /sig api-machimery /sig scheduling 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.
Code change:
klog.V(3).Infof("Pod %q is terminated, but some containers have not been cleaned up: %s", format.Pod(pod), statusStr) return false } <del> // pod's sandboxes should be deleted if len(runtimeStatus.SandboxStatuses) > 0 { var sandboxStr string for _, sandbox := range runtimeStatus.SandboxStatuses { sandboxStr += fmt.Sprintf("%+v ", *sandbox) } klog.V(3).Infof("Pod %q is terminated, but some pod sandboxes have not been cleaned up: %s", format.Pod(pod), sandboxStr) return false } </del> if kl.podVolumesExist(pod.UID) && !kl.keepTerminatedPodVolumes { // We shouldn't delete pods whose volumes have not been cleaned up if we are not keeping terminated pod volumes klog.V(3).Infof("Pod %q is terminated, but some volumes have not been cleaned up", format.Pod(pod))

Related discussion:
text: </details
/cc
will increase the time for deletion of pod and it should be expected because currently pod is deleted from apiserver before removing the sandbox container but after this fix pod will be deleted from the apiserver only after deleting the sandbox container.
/remove-sig scheduling doesn't affect scheduling running time at all.
Yeah, is almost definitely the culprit. Last time we changed that code path, it also caused a regression. The degradation in performance is expected, but a 5x slowdown is definitely larger than it should be.
do we know if that's because the status used by the path is stale, or if removing sandboxes is actually that slow?
if there's not a quick fix, should we revert and bring it back in once the root issue is understood?
I think a revert is appropriate in this case.
ok, I'll open it
open at
I agree with that 5x is something which shouldn't happen and i can take a look on why thats happening and that might require changing the way how the sandbox is currently deleted which is only during GC.
Code change:
} for key, cluster := range config.Clusters { if len(cluster.CertificateAuthorityData) > 0 { <del> cluster.CertificateAuthorityData = redactedBytes </del> <ins> cluster.CertificateAuthorityData = dataOmittedBytes </ins> } config.Clusters[key] = cluster }

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST?: What happened: shows: The use of "REDACTED" for a CA here is misleading, since it's a public certificate that is not a secret. What you expected to happen: I expected to see the full CA in pem format (like when you cat ) or something like "SUPPRESSED" or "TRUNCATED" How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Nope Environment: Kubernetes version (use ):Cloud provider or hardware configuration:OS (e.g. from /etc/os-release):Kernel (e.g. ):
(for thoughts)
Reiterating the mentions to trigger a notification: <detailsIn response to : (for thoughts) 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
use you can see the complete certificate authority data
Hey Thank you - I have tracking that . The point of this issue is that at best it's a bad UX; at worst it's a miseducation on pki. "REDACTED" isn't the right word here
If there are multiple clusters displaying certificates, the configuration will be too long, so this switch is turned off by default. But we can add an example to help use. thanks
Hey I don't personally view truncation the responsibility of the CLI... users can pipe things to a pager if they really care. That being said, I'm not concerned about the length. The issue is purely about the word choice of "REDACTED". The term means: The use of the term "REDACTED" in the output implies that a CA public key is remove for security when (as you've pointed out) it is removed for truncation. Truncation and redaction are fundamentally different things, and k8s is misusing the word redacted for this use case.
Not quite a bug, but I think you're right a better term could be used there as it is a public key, not a private key. /remove-kind bug
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.
Code change:
} for key, cluster := range config.Clusters { if len(cluster.CertificateAuthorityData) > 0 { <del> cluster.CertificateAuthorityData = redactedBytes </del> <ins> cluster.CertificateAuthorityData = dataOmittedBytes </ins> } config.Clusters[key] = cluster }

Related discussion:
text: 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'm not sure what I need to do here. This was marked as a feature. Do you need something more from me?
We are waiting for someone to fix this.
/remove-good-first-issue I don't think this fits our definition of a :
So I have to keep replying to the comment bot every 30 days so it doesn't get auto-closed? That feels... odd
thanks for the education :) unfortunately other issues are higher priority and no one has stepped up to fix this. The autocloser is a form of bug bankruptcy that keeps our issue load in check. The contribex special interest group is definitely open to feedback on the bot.
The biggest hurdle in this is that Kubernetes is using some base64 trickery to display the string (basically setting the certificate data to the decoded bytes from ). We can change this to or but not (it has to be a valid base64 encoded string). I tried exploring multiple options for the text, but I couldn't find a suitable one. Given that we already print the user tokens and other credentials this is a bit weird. Should we redact those too? Is it okay if we print the CA certificate instead of truncating it?
I can't help but laugh at: I'm not wed to any particular name. I also have no problem displaying the entire certificate. The crux of the issue is that a CA public key is not secret or sensitive. It's a public key
I agree. The issue is with the constraints imposed by how this is implemented currently. I tried to come up with a suitable string (given the constraint) and couldn't find anything acceptable... The only suitable option that worked for me is . I personally prefer to print the CA certificate since we are already printing user tokens and client certs that are actual secrets.
I agree. Who do we need to get in agreement that printing the full CA is the best path forward?
the data is not omitted for security purposes, but to make the output more readable. see REDACTED is misleading... it should probably be "elided" or "..."
you can run to view full content
that's the crux of this issue - REDACTED is misleading.
Code change:
} for key, cluster := range config.Clusters { if len(cluster.CertificateAuthorityData) > 0 { <del> cluster.CertificateAuthorityData = redactedBytes </del> <ins> cluster.CertificateAuthorityData = dataOmittedBytes </ins> } config.Clusters[key] = cluster }

Related discussion:
text: However, pointed out that other "long" fields are still completely printed in plain text such as client certs, so I think we need to revisit the "readability" argument. What do you think?
they are not... client cert/key are elided in the same way for the same reason: something like "++data+omitted++" could be better If the intent of config view without --raw specified is to be readable (which it currently is), printing many extremely long fields isn't great
Hmm what about: I'm pretty sure that would give us a valid b64 string (8+12=20%4=0) and it would subtly hint that the data isn't a secret.
Only valid characters are . And adding a prefix from the certificate only complicates things. is a suitable usable option. I'll submit a PR to continue the discussion there.
Code change:
} return result, autorest.DetailedError{ StatusCode: http.StatusNotFound, <del> Message:    "Not such PIP", </del> <ins> Message:    "No such PIP", } } func (fAPC *fakeAzurePIPClient) GetVirtualMachineScaleSetPublicIPAddress(ctx context.Context, resourceGroupName string, virtualMachineScaleSetName string, virtualmachineIndex string, networkInterfaceName string, IPConfigurationName string, publicIPAddressName string, expand string) (result network.PublicIPAddress, err error) { fAPC.mutex.Lock() defer fAPC.mutex.Unlock() if _, ok := fAPC.FakeStore[resourceGroupName]; ok { if entity, ok := fAPC.FakeStore[resourceGroupName][publicIPAddressName]; ok { return entity, nil } } return result, autorest.DetailedError{ StatusCode: http.StatusNotFound, Message:    "No such PIP", </ins> } }

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: Node external IP of azure VMSS cannot be obtained when cloud-controller-manager is enabled. Corresponding logs are shown as follows:
/sig azure
/milestone v1.16
Code change:
oldPVC.Status.Conditions = nil newPVC.Status.Conditions = nil <ins> // TODO(apelisse): We don't have a good mechanism to // verify that only the things that should have changed // have changed. Ignore it for now. oldPVC.ObjectMeta.ManagedFields = nil newPVC.ObjectMeta.ManagedFields = nil </ins> // ensure no metadata changed. nodes should not be able to relabel, add finalizers/owners, etc if !apiequality.Semantic.DeepEqual(oldPVC, newPVC) { return admission.NewForbidden(a, fmt.Errorf("node %q is not allowed to update fields other than status.capacity and status.conditions: %v", nodeName, diff.ObjectReflectDiff(oldPVC, newPVC)))

Related discussion:
text: Alpha environment tests are failing - The root cause of the tests failing in alpha environment appears to be: So basically kubelet is not allowed to update PVC. Which is weird. Need to investigate further. Also for multizone environment - This line looks weird from e2e: So the deployment is straight up not getting started. /sig storage /assign
For multizone failure it looks like the pod has a node selector that conflicts with the zone where the PV was provisioned
I think failures on alpha cluster is related to generated api code: Obviously none of the PVC patch code sets this stuff and yet is showing up in object diff. I am wondering why. cc
/wg apply /cc
It looks like we may have to reset field before comparing PVCs for admitting them as well.
Yeah, server side apply has an alpha feature to kube-apiserver that allows to track ownership of fields. This is what you see in the managedFields field. It’s automatically when objects are modified. If you want to compare your object against a staticly compiled expected object, you should be emptying/setting the managedField to nil.
this is the code in question: Thing is, we don't actually want the kubelet taking ownership of any fields other than the one it changed. If we nil out the managed field for the comparison, that allows the kubelet to mess with managedFields in any way it wants to
can you pick this up to fix failure in alpha clusters? Reading last comment - it doesn't seem like a storage issue.
/unassign /assign
/milestone v1.14 We're entering and this looks relevant to the 1.14 release. Please if I am incorrect
We don't have a good way to do what is suggesting now, so I suspect we will have to default to ignore this field specifically when comparing (by setting it to null on both sides), at least for now.
will you be able to submit a PR to fix this?
As per /remove-sig storage /sig api-machinery
Sure, I'll try to send a pr this morning
Code change:
//FilenameParam(enforceNamespace, o.Filenames...). FilenameParam(enforceNamespace, &o.FilenameOptions). Flatten() <del> if !o.Local { </del> <ins> if !cmdutil.GetDryRunFlag(cmd) { </ins> builder = builder. SelectorParam(o.Selector). ResourceTypeOrNameArgs(o.All, args...).

Related discussion:
text: from https://k8s-
Really suspect this is
This is putting us into test-go post-commit run is broken
cc:
marked this p0 - if a fix isn't easy let's try to identify what introduced this and revert.
This flake on: 2016-10-30 07:19 PDT First instance: : It is flaking frequently, blocking PRs from getting merged, and slowing the submit queue ( at 75%). As on-call, I'm going to try and identify the cluprit and revert. Can use all help in doing so.
can you investigate whether your additional tests could cause this (by breaking the deployment of those pods, for instance) , Saad Ali wrote:
PR looks most suspect to me. It mucked with , and the errors we are seeing in each of the failures is related to : That PR was merged at Oct 30, 2016, 6:18 AM PDT and the first flake in was at Oct 30, 2016, 7:19 AM PDT. Thoughts? CC
I'm going to initiate a revert of to see if that fixes the issue
IMO we can just change the flaky test to not get pods but some other resources, such as deployments. We can't really expect to clean up pods immediately.
I'm going to proceed with revert (). Please feel free to send a follow up PR to handle this more gracefully.
Going to leave this opened until we have a few hours of runs with the revert. Want to verify, with some degree of certainty, that the revert took care of this flake.
We had 15 green runs of in a row. Considering this flake fixed.
Code change:
// pod setup jobKeyForget  bool restartCounts []int32 <ins> podPhase      v1.PodPhase </ins> // expectations expectedActive          int32

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: I create a job with initcontainer with restartPolicy : when the initContainer exec failed and it will be restarted, the pod Phase will be pending all the time. but in JobController, the only care the running pod. So this pod will be always restarted. What you expected to happen: when restart count to backoffLimit, the job failed. 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: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig apps
/assign
Code change:
roleRef: kind: Role name: external-attacher-cfg <ins> apiGroup: rbac.authorization.k8s.io </ins>

Related discussion:
text: xref: When running the GCE PD CSI Driver against all dynamic provisioning tests from this PR: We encounter the following test failures that need to be resolved: /kind bug /sig storage /cc
So it seems that the flag is getting passed all the way through to the driver and it is behaving as we would expect it to in terms of mounting. All the correct commands are being run: When exec-ing into the gce-pd-driver container we can observe that the mounted point is indeed read only. However, when viewed from the host node's perspective the mount is still read write. And therefore since the subpath folder is created by the host, the folder is still being created successfully which fails the test. This behavior suggests that is either not properly propagating the read only option on remount, or not properly remounting at all. I can't figure out how to "view mount events" if that's even possible, some help would be appreciated if anyone is aware of how to do that. That would help me narrrow down which of those two options is happening. I have also attempted (from inside the gce pd driver container) to unmount the point (successful) and bind mount it back with the readonly option directly (not using remount trick, still unsuccessful). Suggesting that maybe it is the that is not being mount propagated and not a problem with in particular. /cc
/assign
/milestone v1.13 /priority important-soon
Code change:
// Create the controller and run it until we close stop. stop := make(chan struct{}) <ins> defer close(stop) </ins> go framework.New(cfg).Run(stop) // Let's add a few objects to the source. <del> for _, name := range []string{"a-hello", "b-controller", "c-framework"} { </del> <ins> testIDs := []string{"a-hello", "b-controller", "c-framework"} for _, name := range testIDs { </ins> // Note that these pods are not valid-- the fake source doesn't // call validation or anything. source.Add(&api.Pod{ObjectMeta: api.ObjectMeta{Name: name}}) } // Let's wait for the controller to process the things we just added. <del> time.Sleep(500 * time.Millisecond) close(stop) </del> <ins> outputSet := util.StringSet{} for i := 0; i < len(testIDs); i++ { outputSet.Insert(<-deletionCounter) } </ins> <del> outputSetLock.Lock() </del> for _, key := range outputSet.List() { fmt.Println(key) }

Related discussion:
text: From shippable, I noticed there are several failed cases, for example, E0413 17:34:38. ] watch of *api.Pod ended with: Stop requested --- FAIL: Example (0.61s) got: want: a-hello b-controller c-framework FAIL coverage: 85.9% of statements FAIL 7.652s cc/
another example:
ah-- this is a different thing. I will fix this, too.
I'm seeing this from an unrelated change
Yeah I think that's the one I expected to see.