jiebi/CodeConvo huggingface dataset:
Change:
tests := []struct { name           string mountPoint     string <ins> selinuxEnabled bool </ins> expectedResult bool }{ { <ins> "ext4 on / with disabled SELinux", "/", false, false, }, { </ins> "ext4 on /", "/", true, <ins> true, </ins> }, { "tmpfs on /var/lib/bar", "/var/lib/bar", <ins> true, </ins> false, }, { "nfsv4", "/media/nfs_vol", <ins> true, </ins> false, }, } for _, test := range tests { <del> out, err := GetSELinux(test.mountPoint, filename) </del> <ins> out, err := GetSELinux(test.mountPoint, filename, func() bool { return test.selinuxEnabled }) </ins> if err != nil { t.Errorf("Test %s failed with error: %s", test.name, err) }

Discussion:
On a busy system, kubelet failed to tell the container runtime that a pod's CSI volume supports SELinux and should be relabeled with pod's SELinux label. The pod then can't access the volume. Kubelet correctly detects that the CSI volume supports SELinux and tells the container runtime to relabel it. Unknown. Get a busy system and try hard? CSI volume plugin tried to detect that the volume supports SELinux during SetupAt. This check failed: Current CSI volume plugin code silently consumes the error and assumes that the volume does not support SELinux at all: Therefore, the volume is marked as mounted and given to the container runtime without the right SELinux options and the runtime does not relabel volume. <details22.0 </details<detailsNone </details<details</details<details</details<detailsCRI-O, but I think it's not really relevant. </details<details</details
/sig storage /triage accepted
We've updated kubelet in our clusters to v1.20.13 (which contains the cherry picked fix), but still observe the issue
Change:
// mountPropagation determines how mounts are propagated from the host // to container and the other way around. // When not set, MountPropagationHostToContainer is used. <del> // This field is alpha in 1.8 and can be reworked or removed in a future // release. </del> <ins> // This field is beta in 1.10. </ins> // +optional MountPropagation *MountPropagationMode }

Discussion:
<!-- 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?: What happened: Mount propagation feature was moved to beta in PR However the was not updated to reflect that it is now beta: What you expected to happen: Comment reflects feature is beta. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: /assign Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
There are no sig labels on this issue. Please add a sig label. <detailsA sig label can be by either: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. See the . The in method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals 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
I push a PR for it.
Oops, sorry. thanks for the PR.
oops, missing priority was my fault, moving back into milestone: /priority critical-urgent /remove-priority important-soon
Update to make bot happy: PR is approved and ready to merge
[MILESTONENOTIFIER] Milestone Issue: Up-to-date for process Note: This issue is marked as , and must be updated every 1 day during code freeze. Example update: <details open<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
Change:
func NewResourceManager(path string) ResourceManager { scheme := runtime.NewScheme() <del> // Register conversion for apidiscovery apidiscoveryv2.SchemeBuilder.Register(apidiscoveryv2conversion.RegisterConversions) </del> utilruntime.Must(apidiscoveryv2.AddToScheme(scheme)) utilruntime.Must(apidiscoveryv2beta1.AddToScheme(scheme)) <ins> // Register conversion for apidiscovery utilruntime.Must(apidiscoveryv2conversion.RegisterConversions(scheme)) </ins> codecs := serializer.NewCodecFactory(scheme) rdm := &resourceDiscoveryManager{

Discussion:
Seeing data race flakes in unit tests: Appears to have just been in /sig api-machinery /priority critical-urgent /assign /cc
This code is mutating the package-level schemebuilder: I think it should be adding the conversions to the local scheme instead:
Fixed in (found several instances)
/triage accepted
Change:
for _, container := range pod.Spec.Containers { expectedHash := dockertools.HashContainer(&container) <ins> dockerContainerName := dockertools.BuildDockerName(uid, podFullName, &container) </ins> if dockerContainer, found, hash := dockerContainers.FindPodContainer(podFullName, uid, container.Name); found { containerID := dockertools.DockerID(dockerContainer.ID) glog.V(3).Infof("pod %q container %q exists as %v", podFullName, container.Name, containerID)

Discussion:
-- is the old old format for names.
Just to be sure, is "pod [podFullName] container [container.Name]" the new preferred format? I also see some places comma separating that form.
The new form should either be a list of fields, a strict, or the result of BuildDockerName(...) On Jan 15, 2015 5:37 AM, "commonlisp" wrote:
Closed with
Change:
assert.Equal(t, 1, len(fnh.UpdatedNodes), "Node was not updated") assert.Equal(t, "node0", fnh.UpdatedNodes[0].Name, "Node was not updated") <del> assert.Equal(t, 1, len(fnh.UpdatedNodes[0].Status.Addresses), "Node status unexpectedly updated") </del> <ins> assert.Equal(t, 3, len(fnh.UpdatedNodes[0].Status.Addresses), "Node status unexpectedly updated") </ins> cloudNodeController.Run()

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If this may be security issue, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: When using the flag on the kubelet, the node's list no longer reports , , addresses. What you expected to happen: That I can explicitly set to an IP, but the other addresses will still show up. How to reproduce it (as minimally and precisely as possible): Create a new kops cluster, modify the kubelet to use the flag with the eth0 on the node. Run Anything else we need to know?: This change will probably take place in  This came up as a result of Environment: Kubernetes version (use ): 1.9.x Cloud provider or hardware configuration: AWS OS (e.g. from /etc/os-release): any Kernel (e.g. ): any Install tools: kops /sig network /sig node I'll make a PR for this change shortly
Change:
// updateResourceQuotaUntilUsageAppears updates the resource quota object until the usage is populated // for the specific resource name. func updateResourceQuotaUntilUsageAppears(c clientset.Interface, ns, quotaName string, resourceName v1.ResourceName) error { <del> return wait.Poll(framework.Poll, 1*time.Minute, func() (bool, error) { </del> <ins> return wait.Poll(framework.Poll, resourceQuotaTimeout, func() (bool, error) { </ins> resourceQuota, err := c.CoreV1().ResourceQuotas(ns).Get(context.TODO(), quotaName, metav1.GetOptions{}) if err != nil { return false, err

Discussion:
Which jobs are flaking: Which test(s) are flaking: Testgrid link: Reason for failure: Anything else we need to know: Triage: Spyglass: /sig api-machinery
/sig scheduling /remove-sig api-machinery I get the log from the artifacts. ResourceQuota check for best-effort pod failed for a pod that is not scheduled due to below error that is expected as The scheduling error is expected. no error/warning messages in kube controller manager with resourcequotacontroller. The case was failed after 30 seconds. Try to fix it like for configmap check. It seems that resource quota status/used updating is not that quick.
/remove-sig scheduling /sig api-machinery
BTW, if we want to fix it in kube-controller-manager side. Increase the namespace syncs concurrent may help If there are some metrics, it can be proved to be right or wrong.
/cc /triage accept
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /cc /triage accept 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
/triage accepted
past weeks looks good to me, can we move it to observe?
Change:
if err != nil { glog.V(4).Infof("azureDisk - GetStorageAccount:%s err %s", storageAccountName, err.Error()) <del> return false, err </del> <ins> return false, nil // error performing the query - retryable </ins> } if provisionState == storage.Succeeded { return true, nil } <del> glog.V(4).Infof("azureDisk - GetStorageAccount:%s not ready yet", storageAccountName) // leave it for next loop/sync loop return false, fmt.Errorf("azureDisk - Account %s has not been flagged Succeeded by ARM", storageAccountName) </del> <ins> glog.V(4).Infof("azureDisk - GetStorageAccount:%s not ready yet (not flagged Succeeded by ARM)", storageAccountName) return false, nil // back off and see if the account becomes ready on next retry </ins> }) // we have failed to ensure that account is ready for us to create // the default vhd container if err != nil { <ins> if err == kwait.ErrWaitTimeout { return fmt.Errorf("azureDisk - timed out waiting for storage account %s to become ready", storageAccountName) } </ins> return err } }

Discussion:
I was looking for examples of our exponential backoff usage, and found some suspicious code. wait.ExponentialBackoff exits immediately if But in this loop, we always return , so we will never retry.
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
That does look suspicious. What's the expected return of a retryable function (ConditionFunc)? for 'succeeded', for 'fatal error, do not retry' and for 'retryable error, let the retry policy decide whether to try again' (and it's up to the retryable function to log such errors as it encounters them rather than propagating the last error to its caller)? (Forgive me if this is a newbie question, I am... a newbie.)
Your description sounds right. The pattern seems to be to log the error in the case. Some other callers seem to stash the error for future use, but most simply return timeout on a timeout (not the "real" error, hence the need to log it). It's a pretty caller hostile API, IMO :-)
Change:
dnsPolicy: Default containers: - name: fluentd-gcp <del> image: gcr.io/google-containers/fluentd-gcp:2.0.4 </del> <ins> image: gcr.io/google-containers/fluentd-gcp:2.0.5 </ins> # If fluentd consumes its own logs, the following situation may happen: # fluentd fails to send a chunk to the server => writes it to the log => # tries to send this message to the server => fails to send a chunk and so on.

Discussion:
Fuentd-gcp image in version , used in contained a bad version of the fluentd (0.14), which introduced regression, detected by the load tests /cc
Change:
etcd.SetLogger(log.New(os.Stderr, "etcd ", log.LstdFlags)) controllerManager := registry.MakeReplicationManager(etcd.NewClient([]string{*etcd_servers}), <del> kube_client.Client{ </del> <ins> client.Client{ </ins> Host: "http://" + *master, })

Discussion:
It would be great to have an easy way to run a kubernetes master/minion locally. Currently, it's not that easy to set up. We should have a convenient script to make it work.
The integration test binary is pretty close. It'd be pretty simple to glue in the kubelet to that binary. Brendan On Jun 10, 2014 2:53 PM, "Daniel Smith" wrote:
I'll take a look.
+1 for this -- especially in script form rather than a go executable.
what exactly do you mean by "script form"? Were you thinking of something like a version of cloudcfg that can be run without needing to have started up a daemon first?
Basically, what I had in mind, is a shell script that looks something like
Ah, ok. That's very similar to local-; the only difference is that everything is packaged into a single go binary. We probably will switch to using individual binaries for this when we start running our components inside docker containers.
The script just makes things more obvious how to run things for those who are looking to integrate them into non-GCE environments.
That's a good point. I'll look into this some more later.
Create a pad as follows: Name: non-persistent-redis Container image: redis Named-volum with name: cache-control Mount path: /data/redis It should launch in the pre-prod namespace and the volume MUST NOT be persistent. apiVersion: v1 kind: Pod metadata: name: non-persistent-redis namespace: pre-prod spec: containers: name: non-persistent-redis image: redis volumeMounts: name: cache-control mountPath: "/data/redis" volumes: name: cache-control emptyDir: {}

I cannot find such a service when . Same thing applies for . My cluster runs fine. cc:
Ah, good catch... everything is run as a container now, will update the documentation on where to get the logs.

When I'm accessing persistentVolumes and persistentVolumeClaims, I'm getting nil instead of empty list of items, as happening in other entities when there are no items. { "kind": "PersistentVolumeList", "apiVersion": "v1", "metadata": { "selfLink": "/api/v1/persistentvolumes", "resourceVersion": "" } }
Yes, this seems like a bug. I see an empty list when I access pods: And items is nil when I access persistent volumes:
Items shouldn't be tagged with omitempty:
cc
PersistentVolumeList and PersistentVolumeClaimList appear to be the only resource types with this problem.
Please see for fix.
Change:
"github.com/onsi/ginkgo" ) <del> var _ = ginkgo.Describe("[sig-architecture] PodTemplates", func() { </del> <ins> var _ = ginkgo.Describe("[sig-node] PodTemplates", func() { </ins> f := framework.NewDefaultFramework("podtemplate") <del> ginkgo.It("should run the lifecycle of PodTemplates", func() { </del> <ins> /* Release : v1.19 Testname: PodTemplate lifecycle Description: Attempt to create a PodTemplate. Patch the created PodTemplate. Fetching the PodTemplate MUST reflect changes. By fetching all the PodTemplates via a Label selector it MUST find the PodTemplate by it's static label and updated value. The PodTemplate must be deleted. */ framework.ConformanceIt("should run the lifecycle of PodTemplates", func() { </ins> testNamespaceName := f.Namespace.Name podTemplateName := "nginx-pod-template-" + string(uuid.NewUUID())

Discussion:
This issue proposes the writing of a new test for the API endponts , , , and with the intention of promoting it to Conformance. This issue contains a very basic mock test in order to start the conversation about what a good e2e test would look like for this endpoint. The code below is verified to be hitting the intended endpoint, show as per the queries in APIsnoop's live view of the cluster's audit logs. According to these results from APIsnoop, we are lacking in test coverage and conformant tests for PodTemplate. We chose these three following endpoints for this mock test: - - Outline: PodTemplates, Expect no PodTemplates a PodTemplate (1), Expect no error PodTemplate (1), Ensure the same as how it was created PodTemplate (1) with label a=1, Expect no error PodTemplate (1), Expect label in returned data to be present PodTemplates by label a=1, Expect one PodTemplate PodTemplate (1) Expect no error PodTemplates, Expect no PodTemplates Fetch dependencies: This mock test is using client-go's standard functions to talk to the PodTemplate part of the API. If a test with these calls gets merged in, conformance will go up by 3 endpoints. /sig architecture /area conformance
We decided not to deprecate. We can link to that, but otherwise this is OK to write / promote.
ref: for the decision not to deprecate
/reopen
Reopened this issue. <detailsIn response to : /reopen 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:
store *genericregistry.Store } <ins> var _ = rest.Patcher(&StatusREST{}) </ins> // New creates a new VolumeAttachment resource func (r *StatusREST) New() runtime.Object { return &storageapi.VolumeAttachment{}

Discussion:
This came up as a follow up to Also rather than opening 5 different issues - we are going to use this github issue to track all follow up items mentioned here -
/sig storage
/assign /assign
: PR
and the rest is fixed in
Change:
}, } <ins> pvcConfig := e2epv.PersistentVolumeClaimConfig{ StorageClassName: &ns, } </ins> numPVs, numPVCs := 1, 1 pvols, claims, err = e2epv.CreatePVsPVCs(ctx, numPVs, numPVCs, c, f.Timeouts, ns, pvHostPathConfig, pvcConfig) framework.ExpectNoError(err, "Failed to create the requested storage resources")

Discussion:
master-informing: ! Last 2 runs failed consecutively, first failure: No response /sig storage
/cc
I will take a look this week.
/triage accepted
/assign
Change:
} } <del> func newContainerStats(libcontainerStats *libcontainer.Stats) *info.ContainerStats { </del> <ins> func newContainerStats(libcontainerStats *libcontainer.Stats, withPerCPU bool) *info.ContainerStats { </ins> ret := &info.ContainerStats{ Timestamp: time.Now(), } if s := libcontainerStats.CgroupStats; s != nil { <del> setCpuStats(s, ret) </del> <ins> setCpuStats(s, ret, withPerCPU) </ins> setDiskIoStats(s, ret) setMemoryStats(s, ret) }

Discussion:
/kind feature This is the once-per-release cut of a new cAdvisor release, which corresponds to the next kubernetes release. cAdvisor v0.29 corresponds to kubernetes v1.10. /sig node /priority important-soon
self-reminder to add per-cpu stats to ignore metrics when vendoring. reminder to add a release notice that one of the container labels fields is being removed.
/kind bug turns out most of the changes are bug-fixes
please mark this issue as approved-for-milestone, since it certainly seems to be, and it's now code slush. Thanks!
Change:
args: args{initialCapacity: 5, maxCapacity: 10, sizes: []int{8, 4}}, cap:  8, }, <ins> { name: "with existing capacity and length above max", args: args{initialCapacity: 12, initialLen: 5, maxCapacity: 10, sizes: []int{8, 4}}, cap:  12, len:  5, }, { name: "with existing capacity and length below max", args: args{initialCapacity: 5, initialLen: 3, maxCapacity: 10, sizes: []int{8, 4}}, cap:  8, len:  3, }, </ins> } for _, tt := range tests { t.Run(tt.name, func(t *testing.T) { if tt.args.initialCapacity > 0 { <del> tt.args.v = reflect.ValueOf(make([]example.Pod, 0, tt.args.initialCapacity)) </del> <ins> val := make([]example.Pod, tt.args.initialLen, tt.args.initialCapacity) for i := 0; i < tt.args.initialLen; i++ { val[i].Name = fmt.Sprintf("test-%d", i) } tt.args.v = reflect.ValueOf(val) </ins> } <del> // reflection requires that the value be addressible in order to call set, </del> <ins> // reflection requires that the value be addressable in order to call set, </ins> // so we must ensure the value we created is available on the heap (not a problem // for normal usage) if !tt.args.v.CanAddr() {

Discussion:
has by default, and since 1.22 has the same. They seem to return wrong results in certain situations combined with / . And / also use , so they also don't work correctly. outputs partial list of pods on the node, doesn't evict some of the pods. To make it work correctly, I had to specify works correctly with any , since it's just a performance optimizing parameter. I can't provide an actual concrete example (no = default ), but instead I show how to reproduce it with a smaller I believe that the same problem occurs with create two deployments. there are 5 pods in each. with --selector=app=another-server and , it shows only 4 pods. I could confirm that the problem happens in both case of and regardless namespace, even with , or <details</details<detailsGCP / GKE Standard </details<details</details<details</details<details</details<details</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
/sig api-machinery
/sig node
I think this is indeed a bug, after some simple testing, it seems to be an bug unique to 1.24, let me fix it. /assign
/assign
I can reproduce this error in a 1.24 cluster, but not in a 1.23.6 cluster. All clusters are created via kind, and I'm guessing gke may have cherry-picked some commits or had some of their own changes to their branch. So I think this fix should at least cherry-pick to 1.23 to help other distributions fix this issue.
/remove-sig api-machinery
Change:
# Channels Setup,Windows PowerShell Channels     application,system,security Tag          winevent.raw <del> DB           winlog.sqlite   # </del> <ins> DB           winlog.sqlite   # </ins> # Json Log Example:

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: There's a race condition between starting Windows service and when the VMs network is actually available to communicate with the VM's metadata server. If the service starts first and cannot communicate with the metadata server or start talking to the stackdriver logging service it'll crash and not resume because the service is not configured to restart on failure. Typically a is used for a service like this but Windows does not support privileged containers so a standard Windows Service is used. What you expected to happen: If the service fails to start it should be automatically be restarted. How to reproduce it (as minimally and precisely as possible): This is a flaky issue but a way to repro this is to effectively by RDP'ing into the node and running: Anything else we need to know?: Environment: Kubernetes version (use ): v1.16 and onward Cloud provider or hardware configuration: GCE OS (e.g: ): Windows Kernel (e.g. ): Windows (any version) Install tools: cluster/gce/windows/README-GCE-Windows-kube- Network plugin and version (if this is a network-related bug): Others:
/sig windows
/assign jeremyedwards
GitHub didn't allow me to assign the following users: jeremyedwards. 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 jeremyedwards 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