jiebi/CodeConvo huggingface dataset:
Change:
ClaimSize            string ExpectedSize         string PvCheck              func(claim *v1.PersistentVolumeClaim) <del> VolumeMode           *v1.PersistentVolumeMode </del> <ins> VolumeMode           v1.PersistentVolumeMode </ins> AllowVolumeExpansion bool }

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: I created a block EBS volume using dynamic provisioning. Then I resized the volume from 10GB to 20 GB. Both PV and block volume reflects the change, but the PVC's capacity is still 10GB. This could be caused by in-tree resize put the PVC condition under state, but no one is acting on the condition since it is block volume: /cc /sig storage What you expected to happen: PVC's capacity should be updated to 20GB How to reproduce it (as minimally and precisely as possible): Easy to reproduce using following specs: StorageClass: Claim: Pod: Anything else we need to know?: This will affect whether CSI migration should handle migration scenario for block volume resizing. Environment: Kubernetes version (use ):1.13 Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: kops Network plugin and version (if this is a network-related bug): Others:
/sig aws
/assign
Change:
fsGroupPolicyEnabled := utilfeature.DefaultFeatureGate.Enabled(features.ConfigurableFSGroupPolicy) <del> klog.Warningf("Setting volume ownership for %s and fsGroup set. If the volume has a lot of files then setting volume ownership could be slow, see https://github.com/kubernetes/kubernetes/issues/69699", mounter.GetPath()) </del> <ins> timer := time.AfterFunc(30*time.Second, func() { klog.Warningf("Setting volume ownership for %s and fsGroup set. If the volume has a lot of files then setting volume ownership could be slow, see https://github.com/kubernetes/kubernetes/issues/69699", mounter.GetPath()) }) defer timer.Stop() </ins> // This code exists for legacy purposes, so as old behaviour is entirely preserved when feature gate is disabled // TODO: remove this when ConfigurableFSGroupPolicy turns GA.

Discussion:
What happened: there are many kubelet warnings in the systemd logs I initialized the cluster with kubeadm init (no modifications) What you expected to happen: Not to have that many kubelet warnings in the system logs Anything else we need to know?: Environment: Kubernetes version (use kubectl version):Cloud provider or hardware configuration:OS (e.g: cat /etc/os-release):Kernel (e.g. uname -a):Install tools:
I have the same issue
should add a option or an annotationo to resolve this /sig node /area kubelet
Same issue kops, kubernetes 1.18.3, aws cloudprovider
Same issue on v1.17.4 installed with rancher
Same issue on v1.18.0 ~
Same issue on 1.17.6
Happens on v1.18.3 as well. This issue only occurs when container has some fsGroup set in its securityContext AND volume being mounted is either secret or a configmap. I guess they are being re-mounted every 70s or so. It's okay when the volume being mounted is a standard PV - log only appears once and doesn't get repeated.
I'm seeing the same issue. I'm willing to fix it.
I've digged into this a little bit further. I believe this is just a annoying warning message. AFAICS, it does not show any issue... I was reading the kubelet, its volume manager and the volume plugins source files. It seems that's the expected behavior. The desiredStateOfWorldPopulator sync loop always call the . The finds the volume plugin and check if the plugin requires mount. Secret plugin, wich is the plugin in discussion, always returns . Thus, the of the volume manager remounts the volume every time. I think the problem is in the which prints the warning message. It's more and I believe it does not take these plugins into account. The secret plugin is as it is now since . Is that make sense to you?
/assign
Change:
func (m *azureDiskMounter) GetAttributes() volume.Attributes { readOnly := false volumeSource, err := getVolumeSource(m.spec) <del> if err != nil && volumeSource.ReadOnly != nil { </del> <ins> if err != nil { glog.Infof("azureDisk - mounter failed to get volume source for spec %s %v", m.spec.Name(), err) } else if volumeSource.ReadOnly != nil { </ins> readOnly = *volumeSource.ReadOnly } return volume.Attributes{

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: I deployed a spec using an AzureDisk that triggered an "invalid memory address or nil pointer dereference". The deployment was initializing a pod and mounting an AzureDisk volume after downloading the container. Here are the kubelet logs on the node during the time the error was thrown: The line that throw the exception was , which accesses when the likely returned nil (in this ). What you expected to happen: An error message related to failed disk mounting is returned instead of a nil pointer deference. How to reproduce it (as minimally and precisely as possible): Not very easy to reproduce, but we were in the process of moving pods between nodes running 1.5 -1.8. We suspect there may have been unexpected interactions that caused both and to be missing when the AzureDisk is fetched. Our pod spec uses AzureDisk volumes, not PersistentVolumes. Anything else we need to know?: I'd expect to not access if an error was propagated up. We worked around this issue by deleting the deployment and re-applying our spec, which did the trick, probably since the application of the config took place in an entirely 1.8 setting rather than a hybrid cluster (1.5 and 1.8 worker nodes). Environment: Kubernetes version (use ): kubelet 1.8.1 & master running 1.8.1 Cloud provider or hardware configuration: Azure OS (e.g. from /etc/os-release): CoreOS 1548.4.0 Kernel (e.g. ): Linux master 4.13.9-coreos SMP Thu Oct 26 03:35:38 UTC 2017 x86_64 Intel(R) Xeon(R) CPU E5-2673 v3 @ 2.40GHz GenuineIntel GNU/Linux Install tools: Others:
Hello Issue reported should be from while should be is nil, equals Maybe should we print this error into log ? Thanks very much !
Make sense.
/sig azure
thanks for the reporting, this issue is duplicate of which is fixed by and the fix is also in v1.8 now, while it's not in v1.8.1, line 48 in v1.8.1 is
Change:
func TestAccept(t *testing.T) { _, s := framework.RunAMaster(t) <del> defer s.Close() </del> <ins> // TODO: Uncomment when fix #19254 // defer s.Close() </ins> resp, err := http.Get(s.URL + "/api/") if err != nil {

Discussion:
http://pr- is another failure.
Also seen in http://pr-
Again. Not assigned to anyone, so I am sending to for routing
Again: Is there anyone working on this? I will spend some time looking into this.
I think that the name of this issue is misleading - the issue seems to be unrelated to etcd_watcher Basically, if you look into this part of log: So it seems that, the WaitGroup that is problematic is in httptest.Server. So my feeling is that we are simply talking to a server that is already being close and this is ~roughly duplicate of We should just find where exactly the problem is and try to work-around it.
I think this is exactly what we had before. I will send a PR with the fix today.
Change:
continue } killedContainers[containerID] = empty{} <ins> if podChanged { // Also kill associated pod infra container if the pod changed. if podInfraContainer, found, _ := dockerContainers.FindPodContainer(podFullName, uid, dockertools.PodInfraContainerName); found { if err := kl.killContainer(podInfraContainer); err != nil { glog.V(1).Infof("Failed to kill pod infra container %q: %v", podInfraContainer.ID, err) continue } } } </ins> } // Check RestartPolicy for container

Discussion:
cAdvisor API is not accessible from the node. It is accessible from inside the cadvisor container though. This is the reason for the cadvisor e2e test to fail and the recent heapster errors reported by users. The cadvisor version itself hasn't changed recently though.
cc
There were some changes recently around port forwarding ( that may be the cause.
From the node: From the cadvisor container:
reported the same issue today. Restarting the container seems to fix it. So, its something to do with the initial setup.
Could this be due to Docker 1.5? On Feb 23, 2015 6:12 PM, "Rohit Jnagal" wrote:
test machine is running Docker 1.4.1 It looks like cadvisor container is sharing its networking with the pause container as usual, but the pause container got restarted, so the networking setup isn't working anymore. Restarting cadvisor connects it to the newer instance of the pause container and it starts working again. However docker inspect shows that cadvisor is connected to network of a different pause container: And that container died soon after it started Kubelet killed the pause container. I think this is kubelet's doing. It tried to restart both pause and cadvisor container. It kills and restarts cadvisor container which connects to existing pause container. Then, it goes ahead and kills/restarts the pause container, leaving the new cadvisor container hanging. Maybe this is related to infra pods issue reported by earlier, or maybe just an ordering issue in kubelet.
Thanks for the detailed debugging :) with your report I think I found the issue. In we check if the container has changed and print the message above. After that we the POD container. We should be doing this before the container restart as you pointed out. I'm assigning this to myself and I will fix tomorrow. Will also rename the bug and re-purpose it.
cool, I was just staring at that code. All yours :+1:
Thanks for debugging the issue. This is a regression we introduced lately.
And when the test, we all assumed it was the test failing. Sorry, :)
I fell for that until I realized that the basic networking can also fail :)
Change:
// Update implements Manager. func (f *managedFieldsUpdater) Update(liveObj, newObj runtime.Object, managed Managed, manager string) (runtime.Object, Managed, error) { self := "current-operation" <del> formerSet := managed.Fields()[manager] </del> object, managed, err := f.fieldManager.Update(liveObj, newObj, managed, self) if err != nil { return object, managed, err

Discussion:
I created an object with , and later I updated the same object with another . After that I looked at the object's managedFields, and saw nothing about the update. Here is what I got after the second apply: I expected managedFields to get updated by the second . No response <details</details<detailsnone </details<details</details<detailskubeadm </details<detailsdocker </details<details</details
/cc
I also saw the timestamp not updated when I updated using client-go and typed client stubs, Apply method, patch type .
/assign /triage accepted
/cc
The is not updated because you are not changing the structure of the object (adding or removing fields). According to , the time is updated if and only if the fieldSet is changed. It does not take into account the value of fields. One option would be to not compare the fieldSets but directly compare the liveObject & newObject for differences and update the field accordingly. Is it the desired behavior to update the time of when only the value is updated?
Yes! Look at the first paragraph of .
is that documentation correct? Is this what we intended?
I don't see any mention to the timestamp in that first paragraph. We've clarified recently the exact semantic of the timestamp, as defined here: I think you've identified the wrong code if you want to go ahead and fix it, go ahead, I'll happily review!
Change:
# This is defined in root Makefile, but some build contexts do not refer to them KUBE_BASE_IMAGE_REGISTRY?=registry.k8s.io BASE_IMAGE_VERSION?=bookworm-v1.0.0 <del> BASEIMAGE?=${KUBE_BASE_IMAGE_REGISTRY}/build-image/debian-base-${ARCH}:${BASE_IMAGE_VERSION} # Keep debian releases (e.g. debian 11 == bullseye) consistent # between BASE_IMAGE_VERSION and DISTROLESS_IMAGE images DISTROLESS_IMAGE?=base-debian11 RUNNERIMAGE?=gcr.io/distroless/${DISTROLESS_IMAGE}:latest </del> <ins> RUNNERIMAGE?=${KUBE_BASE_IMAGE_REGISTRY}/build-image/debian-base-${ARCH}:${BASE_IMAGE_VERSION} </ins> TEMP_DIR:=$(shell mktemp -d -t conformance-XXXXXX)

Discussion:
N/A 07/18 02:38 PDT No response /sig release
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
Slack thread:
/sig cli
Change:
return false } <del> // checkIptabless to check expected iptables chain and rules </del> <ins> // checkIptables to check expected iptables chain and rules. The got rules must have same number and order as the // expected rules. </ins> func checkIptables(t *testing.T, ipt *iptablestest.FakeIPTables, epIpt netlinktest.ExpectedIptablesChain) { for epChain, epRules := range epIpt { rules := ipt.GetRules(epChain) <del> for _, epRule := range epRules { if !hasJump(rules, epRule.JumpChain, epRule.MatchSet) { t.Errorf("Didn't find jump from chain %v match set %v to %v", epChain, epRule.MatchSet, epRule.JumpChain) </del> <ins> if len(rules) != len(epRules) { t.Errorf("Expected %d iptables rule in chain %s, got %d", len(epRules), epChain, len(rules)) continue } for i, epRule := range epRules { rule := rules[i] if rule[iptablestest.Jump] != epRule.JumpChain || !strings.Contains(rule[iptablestest.MatchSet], epRule.MatchSet) { t.Errorf("Expected MatchSet=%s JumpChain=%s, got MatchSet=%s JumpChain=%s", epRule.MatchSet, epRule.JumpChain, rule[iptablestest.MatchSet], rule[iptablestest.Jump]) </ins> } } }

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 --ipvs mode didn't preserve client IP for NodePort Service with protocol SCTP and ExternalTrafficPolicy Local. iptables mode works fine. ipvs mode with TCP and UDP protocol works fine. Client IP for NodePort Service should be preseved when ExternalTrafficPolicy is Local regardless of the mode and the protocol. kube-proxy mode to ipvs a NodePort service with protocol SCTP and ExternalTrafficPolicy Local the NodePort service, the client IP was not preserved This is caused by wrong order of iptables rules that match kubeNodePortLocalSetSCTP and kubeNodePortSetSCTP: Kubernetes version (use ): v1.22.0 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 network /assign
/triage accepted
Change:
err:              fmt.Errorf("A weird error"), }, } <del> done := make(chan struct{}) eventBroadcaster := NewBroadcaster() defer eventBroadcaster.StartRecordingToSink( &testEventSink{ </del> <ins> eventCorrelator := NewEventCorrelator(util.RealClock{}) randGen := rand.New(rand.NewSource(time.Now().UnixNano())) for caseName, ent := range table { attempts := 0 sink := &testEventSink{ </ins> OnCreate: func(event *api.Event) (*api.Event, error) { <del> if event.Message == "finished" { close(done) return event, nil } item, ok := table[event.Message] if !ok { t.Errorf("Unexpected event: %#v", event) return event, nil } item.attemptsMade++ if item.attemptsMade < item.timesToSendError { return nil, item.err </del> <ins> attempts++ if attempts < ent.timesToSendError { return nil, ent.err </ins> } return event, nil }, <del> }, ).Stop() clock := &util.FakeClock{time.Now()} recorder := recorderWithFakeClock(api.EventSource{Component: "eventTest"}, eventBroadcaster, clock) for caseName := range table { clock.Step(1 * time.Second) recorder.Event(ref, api.EventTypeNormal, "Reason", caseName) runtime.Gosched() } recorder.Event(ref, api.EventTypeNormal, "Reason", "finished") <-done for caseName, item := range table { if e, a := item.attemptsWanted, item.attemptsMade; e != a { t.Errorf("case %v: wanted %v, got %v attempts", caseName, e, a) </del> <ins> } ev := &api.Event{} recordToSink(sink, ev, eventCorrelator, randGen) if attempts != ent.attemptsWanted { t.Errorf("case %v: wanted %d, got %d attempts", caseName, ent.attemptsWanted, attempts) </ins> } } }

Discussion:
Have not reproduced locally even after a few tens of runs.
which version of Go are you using locally? This probably only repros on 1.5.1.
This was from Jenkins runs.
This is caused because an attempts counter is being read/written to without synchronization. I think this is caused by the event creation order not being guaranteed. I am looking a little deeper to track this down.
Got a fix with 130k+ runs and no failures. Will send out PR shortly.
Change:
glog.Errorf("Could not create volume mounter for pod %s: %v", pod.UID, err) return nil, err } <del> if mounter == nil { return nil, errUnsupportedVolumeType } </del> // some volumes require attachment before mounter's setup. // The plugin can be nil, but non-nil errors are legitimate errors.

Discussion:
in there is a generic error variable defined that is used when a failure occurs and no other error is surfaced, it is a catch-all when something goes wrong. Think this should be reworded to something that is more reflective of the true issue and not so confusing for users. This error mostly comes when a builder can not be created and it is typically not true that the volume type is unsupported, but rather some other underlying issue, such as missing secrets or endpoints or etc... propose something like: or
are you working on this?
- yes, I would like to submit the PR for this

fyi When using PV/PVC for Persistent Volume volume mounts, if something goes wrong in the builder, a generic error is surfaced in the 'kubectl describe' with the following event error description *unsupported volume type": This only occurs when using the PV/PVC abstraction and not directly using a volume plugin. These type of errors are common when using volume plugins for mounts and would be useful for users to have an easy way to identify the errors rather than searching the logs for root cause. I think there are two issues: Why is the original error surfaced from the volume plugins (, , etc...) getting eaten when they return back to the I can see in the logs that 2 volume types are processed for any pod - the first is the actual underlying type (i.e. ) and this is where the actual real error is surfaced, then immediately after this the 2nd type is processed which is the general persistent claim type (i.e. ) and this when the first type error is eaten A simple work around would be to simply add a recorder event in the when there is a builder failure. This ensures the error is recorded and displayed as an event for the describer and will handle all like errors from other volume plugin types. full modifed function for reference from This will produce a better user experience when trying to see what went wrong - in this example, I am doing glusterfs PV/PVC but am missing end points which you can clearly see now in the events of the describe: rbd example: (Missing or Couldn't get secret)
I haven't had a chance to look at your proposal in detail yet, but I agree this is one of the most confusing things new users hit
another one is when gluster endpoints are missing, we get 'unsupported volume type' with your work extrapolating the permissions for NFS to automatically set supplemental groups, is there also a way to indicate more properly it's a permissions issue for it not mounting?
- the above discussion highlights the missing endpoints as the first example, it also discusses a similar rbd issue (missing secret file) but the point is, any of those type of volume plugin type of errors would be surfaced by adding the event in the
I like it! Is there a PR?
Change:
specs := []*goopenapispec.Swagger{} for _, v := range crd.Spec.Versions { // Defaults are not pruned here, but before being served. <del> s, err := builder.BuildSwagger(crd, v.Name, builder.Options{V2: false, StripValueValidation: true, StripNullable: true, AllowNonStructural: true}) </del> <ins> s, err := builder.BuildSwagger(crd, v.Name, builder.Options{V2: false, StripValueValidation: true, StripNullable: true, AllowNonStructural: false}) </ins> if err != nil { return nil, err }

Discussion:
With in a CRD we get: This is because gnostic's OpenAPI proto types have no nullable support. Luckily CRDs keep working because in the upper error case we don't stop serving, just set the SSA schema to nil.
Thanks for reporting!
I think it should be "This is because gnostic's OpenAPI v2 proto types have no nullable support.". The problem is that we're not supposed to pass-in v3.
Source:
OK, We'll write a test and fix this, thanks Stefan!
/reopen This still happens in slightly different shape: This comes from :
That's a fairly different bug but yes, thanks!
Is this related to the stating that use of "anyOf" wouldn't be allowed after 1.16? We're seeing issue on OpenFaaS after going to 1.17.5 and 1.18. Usually upgrading K8s versions hasn't caused breaking changes and we're trying to figure out where to start with this one.
No. That post was about structural schemas. v1 CRDs are limited to structural schemas. v1beta1 CRDs can continue to create non-structural schemas until v1beta1 is no longer served (in 1.22) Also, is not completely disallowed, specific restrictions inside an clause (like ) are what are not allowed ("logical constraints using oneOf, allOf, anyOf, not are allowed").
extracted the newly found issue to to track separately with isolated reproducer /close
Closing this issue. <detailsIn response to : extracted the newly found issue to to track separately 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:
These guides are maintained by CoreOS and deploy Kubernetes the "CoreOS Way" with full TLS, the DNS add-on, and more. These guides pass Kubernetes conformance testing and we encourage you to [test this yourself](https://coreos.com/kubernetes/docs/latest/conformance-tests.html). <ins> [**AWS Multi-Node**](https://coreos.com/kubernetes/docs/latest/kubernetes-on-aws.html) Guide and CLI tool for setting up a multi-node cluster on AWS. CloudFormation is used to set up a master and multiple workers in auto-scaling groups. <hr/> </ins> [**Vagrant Multi-Node**](https://coreos.com/kubernetes/docs/latest/kubernetes-on-vagrant.html) Guide to setting up a multi-node cluster on Vagrant. The deployer can independently configure the number of etcd nodes, master nodes, and worker nodes to bring up a fully HA control plane.

Discussion:
Our docs say this: I think though that example is out of date (?). We should make sure to point it to the right place.
cc
where should this point?
The official CoreOS guides are documented/linked here: The decision made a few months ago was to leave the previous community content, but should we revisit that?
Side note, a link to our AWS tool/guide probably needs to be there as well
What file contains that sentence?