jiebi/CodeConvo huggingface dataset:
Change:
--v $(KUBE_VERBOSE)                                          --logtostderr                                                -i "$$pkgs"                                                  <del> --extra-peer-dirs $$(echo $(addprefix $(PRJ_SRC_PATH)/, $(DEFAULTER_DIRS)) | sed 's/ /,/g')  </del> <ins> --extra-peer-dirs $$(echo $(DEFAULTER_EXTRA_PEER_PKGS) | sed 's/ /,/g')  </ins> -O $(DEFAULTER_BASENAME)                                     "$$@";                                                       fi

Discussion:
In the codegenerator we have: So basically we process only packages that are explicitly requested by the user and ignore ones that are imported. So in order to have the conversion func imported by the generator, the package where it lives has to be explicitly imported. So we should basically always pass all input packages to conversion generator. This is problematic, when regenerating conversions, we simply pass to input directories only those that were changed in the meantime: We should fix that - probably by passing all CONVERSIONDIRS as inputs to conversion-gen /kind-bug
I think this caused Not sure if was related yet.
It's the other way around - this is the main bug and root cause and the other that you linked is a consequence.
Also - FYI
I actually already started looking into it - so let me assign this.
is out for review
/triage accepted
Change:
func (pf *fakePortForwarder) PortForward(name string, uid types.UID, port uint16, stream io.ReadWriteCloser) error { defer stream.Close() <del> var wg sync.WaitGroup // client -> server wg.Add(1) go func() { defer wg.Done() // copy from stream into a buffer received := new(bytes.Buffer) io.Copy(received, stream) // store the received content pf.lock.Lock() pf.received[port] = received.String() pf.lock.Unlock() }() // server -> client wg.Add(1) go func() { defer wg.Done() </del> <ins> // read from the client received := make([]byte, len(pf.expected[port])) n, err := stream.Read(received) if err != nil { return fmt.Errorf("error reading from client for port %d: %v", port, err) } if n != len(pf.expected[port]) { return fmt.Errorf("unexpected length read from client for port %d: got %d, expected %d. data=%q", port, n, len(pf.expected[port]), string(received)) } </ins> <del> // send the hardcoded data to the stream io.Copy(stream, strings.NewReader(pf.send[port])) }() </del> <ins> // store the received content pf.lock.Lock() pf.received[port] = string(received) pf.lock.Unlock() </ins> <del> wg.Wait() </del> <ins> // send the hardcoded data to the client io.Copy(stream, strings.NewReader(pf.send[port])) </ins> return nil }

Discussion:
I wanted to drop a note that I haven't forgotten about this issue. I have spent some time investigating and have yet to determine why some test runs result in the data not being forwarded correctly. I hope to resume digging into this soon, but I've got some planning tasks I need to complete first.
I have determined the root cause of this. In the test case, it: a port forwarding session, listening on a local port a TCP connection to the local port a goroutine copies data from the local port to the remote a goroutine copies data from the remote to the local port data to the TCP connection data from the TCP connection port forwarding, which results in the client streams being closed The problem is that the data written in step 3 is only to the local TCP port. There's no guarantee that the goroutine in 2.i copies the data to the remote before step 5 happens. In fact, if you reverse steps 3 () and 4 () so the write happens immediately before you close the stopChan, this test fails very quickly. I am thinking about how to fix this...
Not done yet:
Saw this again today:
- this was a different failure than this one. I've just opened for it and closing this one
Change:
}, } <del> leaseTime := uint64(s.leaseTime) </del> <ins> // leaseTime needs to be in seconds leaseTime := uint64(s.leaseTime / time.Second) </ins> // NB: GuaranteedUpdate does not perform the store operation unless // something changed between load and store (not including resource

Discussion:
/kind bug The lease reconciler creates the kubernetes endpoint with a prefix of kube-apiserver-endpoint, however that is not the prefix that the rest of kube uses. The end result is that the kubernetes service doesn't have an endpoint, and kubectl won't list the kubernetes endpoint. The lease reconciler also creates lease files with a really long lease time instead of the default 15 seconds.
/cc
cc xref
kube-apiserver-endpoint is used for the lease itself, from what I remember. I don't think that's an issue by itself.
Oh but it does look like the endpointRegistry for the lease reconciler is misconfigured to use that
i'll look into it
what is the name that should be used?
services/endpoints afaik -
Yeah, making that change locally fixed it for me
But I'm not seeing the masterleases/apiServerIPInfo data in etcd, or I'm issuing the wrong command to find it
I had that same problem. The lease timeout is set way high, but for some reason that resulted in the lease files being created for only a very short time. I'm not sure why. Playing with the ttl amount got the lease files to stay around....forever. I've got a PR I'm about to push to fix both issues.
FYI has a PR for this now
cc
Change:
REGISTRY?=gcr.io/google-containers IMAGE?=debian-hyperkube-base <del> TAG=0.2 </del> <ins> TAG=0.3 </ins> ARCH?=amd64 CACHEBUST?=1

Discussion:
/kind bug What happened: When a cluster is provisioned using a containerised kubelet using the following images: Pods with PVCs are not created because kubelet cannot mount the disks. If you look at events, you can see that it's missing some binaries: This executable is . This problem can be resolved by mounting paths from the host into the rkt container, specifically and . Is this expected? mentioned in , that mounting operations are moving out from the main process into containers. Is this part of that effort? This caught me quite unexpected, and I didn't find any docs or changelog entries which indicated additional host mounts were necessary. If it's deliberate, I can close this until we perhaps document the breaking change. Is there a good place where we can document this? If it's not, I'll leave this open as a tracking issue. What you expected to happen: The hyperkube image to work without lots of host mounts. How to reproduce it (as minimally and precisely as possible): Run kubelet with rkt in one of the above listed images (see CoreOS' ). Environment: Kubernetes version (use ): Cloud provider or hardware configuration**: OpenStack OS (e.g. from /etc/os-release):Kernel (e.g. ):Install tools: tectonic-installer
/sig storage /sig node
Seems the base hyperkube image was changed: done in /cc
The pkg/util/mount/mount_linux source defaults to ext4 if a fstype is not selected. It makes sense to restore the e2fsprogs package within the hyperkube image.
cc cc cc This seems like something that should be in the 1.8 milestone. Can someone who owns the hyperkube image comment on that?
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings: sig/node sig/storage: Issue will be escalated to these SIGs if needed. priority/important-soon: Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. kind/bug: Fixes a bug discovered during the current release. <detailsAdditional instructions available <a href=""here</aThe commands available for adding these labels are documented <a href=""here</a</details
Containerization of mount is not going to happen until 1.9 at the earliest.

So if hyperkube is broken, it should be fixed before ship.
"modprobe" also went missing in 1.8 hyperkube images... Both kubelet and kube-proxy need it.
Are you noticing any buggy behaviour on those components without it? Would you mind creating an issue and/or PR to restore that dep
Done: And done: :)
Change:
/srv/kubernetes/abac-authz-policy.jsonl: file.managed: - source: salt://kube-apiserver/abac-authz-policy.jsonl <ins> - template: jinja </ins> - user: root - group: root - mode: 600

Discussion:
abac-authz- hardcodes "admin" instead of using the $KUBE_USER variable. This means that "admin" is the only basic-auth username that will work with that abac config.
To workaround until it is fixed, you can add a line to the master's abac-authz- file: and then restart the kube-apiserver (docker kill it, and let it restart).
Change:
err = gce.ensureInternalBackendService(bsName, "description", svc.Spec.SessionAffinity, cloud.SchemeInternal, "TCP", igLinks, "") require.NoError(t, err) <del> // Update the BackendService with new Instances </del> <ins> // Update the BackendService with new InstanceGroups </ins> if tc.mockModifier != nil { tc.mockModifier(gce.c.(*cloud.MockGCE)) } <del> newNodeNames := []string{"new-test-node-1", "new-test-node-2"} err = gce.ensureInternalBackendServiceGroups(bsName, newNodeNames) </del> <ins> newIGLinks := []string{"new-test-ig-1", "new-test-ig-2"} err = gce.ensureInternalBackendServiceGroups(bsName, newIGLinks) </ins> if tc.mockModifier != nil { assert.Error(t, err) return

Discussion:
Seeing several of the tests in ./pkg/cloudprovider/providers/gce flake 1 in 5-10 runs when run locally (I am logged in to gcloud). Is it possible one of the APIs is not correctly shimmed and is fetching real data?
you were the last folks in here - why would this and other internal_tests in here be flaking?
Happens in both master and 1.11 release branches
/cc cheftako
Change:
fakeremote "k8s.io/kubernetes/pkg/kubelet/cri/remote/fake" "k8s.io/kubernetes/pkg/kubelet/eviction" "k8s.io/kubernetes/pkg/kubelet/images" <ins> "k8s.io/kubernetes/pkg/kubelet/kuberuntime" </ins> "k8s.io/kubernetes/pkg/kubelet/lifecycle" "k8s.io/kubernetes/pkg/kubelet/logs" "k8s.io/kubernetes/pkg/kubelet/network/dns"

Discussion:
spans are not being parented to other spans - propagation of context seems broken. More context: spans should be parented to other spans enable kubelet tracing at v1.28 and hook up a tracing backend. No response <detailsv1.28 at least </details<detailsNot sure this matters. </details<details</details<details</details<details</details<details</details
/sig instrumentation /assign
/triage accepted
!
repro steps:
/assign Thanks for helping to look into this! Feel free to post the findings here you shared with me on slack
GitHub didn't allow me to assign the following users: fatsheep9146. Note that only with read permissions, 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 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
Thanks! I will post this ASAP
The broken issue is due to the pr , which try to propagate context brought by pod worker to syncPod function in order to let the syncPod can be interrupted in time by other asynchronous routines, for example eviction. But in the line we did not pass the context which contain the parent span and trace into function, so the trace is broken. So I want to fix this by passing the into , which is also desired in comment But passing the ctx into syncPod may have something other to do as described in comments, so I tried to fix as comments advised.
cc
Change:
// When GetVolumesToReportAttached is called by node status updater, the current status // of this node will be updated, so set the flag statusUpdateNeeded to false indicating // the current status is already updated. <del> asw.updateNodeStatusUpdateNeeded(nodeName, false) </del> <ins> if err := asw.updateNodeStatusUpdateNeeded(nodeName, false); err != nil { glog.Errorf("Failed to update statusUpdateNeeded field when getting volumes: %v", err) } </ins> } return volumesToReportAttached

Discussion:
was the fix in sufficient, or do you want to bubble the error past SetNodeStatusUpdateNeeded?
do you want this in v1.7?
can you retitle this to be meaningful or close it?
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. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
I checked the sources, now returns as requested here. /close
Change:
"":              "Defines a set of pods (namely those matching the labelSelector relative to the given namespace(s)) that this pod should be co-located (affinity) or not co-located (anti-affinity) with, where co-located is defined as running on a node whose value of the label with key <topologyKey> matches that of any node on which a pod of the set of pods is running", "labelSelector": "A label query over a set of resources, in this case pods.", "namespaces":    "namespaces specifies which namespaces the labelSelector applies to (matches against); null or empty list means "this pod's namespace"", <del> "topologyKey":   "This pod should be co-located (affinity) or not co-located (anti-affinity) with the pods matching the labelSelector in the specified namespaces, where co-located is defined as running on a node whose value of the label with key topologyKey matches that of any node on which any of the selected pods is running. For PreferredDuringScheduling pod anti-affinity, empty topologyKey is interpreted as "all topologies" ("all topologies" here means all the topologyKeys indicated by scheduler command-line argument --failure-domains); for affinity and for RequiredDuringScheduling pod anti-affinity, empty topologyKey is not allowed.", </del> <ins> "topologyKey":   "This pod should be co-located (affinity) or not co-located (anti-affinity) with the pods matching the labelSelector in the specified namespaces, where co-located is defined as running on a node whose value of the label with key topologyKey matches that of any node on which any of the selected pods is running. Empty topologyKey is not allowed.", </ins> } func (PodAffinityTerm) SwaggerDoc() map[string]string {

Discussion:
The field is marked as optional: The comment also describes a use case for empty topologykey: But the validation rule says it's required:
cc
cc could you take a look? Thank you. The validation rule is by
the release note of should go into the "action-required" section of the , but it's currently in "Other notable changes".
/assign
It seems that we should also update the external api type comments. Right?
I will look into it today.
If you didn't work on this, I am pleasure to send PR to fix this. :)
yeah sure. thanks.
Change:
} var left, right interface{} <del> if len(lefts) != 1 { </del> <ins> switch { case len(lefts) == 0: continue case len(lefts) > 1: </ins> return input, fmt.Errorf("can only compare one element at a time") } left = lefts[0].Interface()

Discussion:
On , will fail to evaluate a filter when the member does not exist: For instance, if I were to execute Where not all in that namespace had the annotation, this would fail with the error message: This is confusing as it leads me to think more than one item was selected, so while it is not technically incorrect the error message is misleading. I would furthermore expect to more gracefully handle this case -- a missing here means that the filter should fail, not error.
What do you mean by ? How is it different from ?
As in, don't add that item to the list of items on which the following access is made. When I do: And there is no annotation on , I just get nothing back -- no error, just nothing. Similarly, i would have expected the filtered expression to give me the for all of the pods that have an annotation with value . That, anyway is what I understand the JSONPath syntax to mean. When you write You are saying:
cc since you authored and I'm not sure how we want to fix this.
Taking a look now
it looks like you need to do this (note that the annotations portion is wrapped by ): I wrote a unit test and it worked as expected. PTAL!
I'm pretty sure that was a typo on my end but let me check -- do you have a reproducer script?
I see an entirely different error today... weird:
Ok so you have 1 object with annotations, and 1 without. Let me look into that case.
Let me add another annotation to
No difference if both have annotations:
Ok, I'll have to test using kubectl
I'm the Origin bundled but I don't think there are any patches on JSONPath there:
I'm able to reproduce in the unit test when 1 object has annotations and the other does not, if allowMissingKeys is true for the jsonpath parser.
I see. Let me know if I can be of more help.
I think I have a fix. PR coming soon.
Possible
Change:
import ( "fmt" <ins> "sync" </ins> "time" v1 "k8s.io/api/core/v1"

Discussion:
pull-kubernetes-unit, see example failure in It appears to be a new test in No response No response No response /sig
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
Repro's locally:
/cc can you PTAL? It seems related to new test in
flaking regularly -
actually, I'm not sure this is a test-only race... it looks like self mutates , and that is called in a goroutine in parallel with other methods that access rootDirectory: I suspect this has always been a race, and the unit test is exercising / catching it more
moving the filepath.Clean to init time: and changing the check in setupDataDirs to be a validation rather than a mutation: might resolve the immediate race
/assign
is open to fixing it. The data race we find here should be fixed. However, is another one that we need to fix. I add a new commit to fix that as well.
did you see that race as well or did you just see the issue opened? that was in a code path that should be feature gated so I wouldn't have expected it to trigger in the kubemark unit tests
I may mixed problems together. Yes. will not trigger in the kubemark unit tests. Using stressing, I find the data race cannot fix the problem completely. Then I saw and cherry-picked the fix to my PR. But the hollowNode test still flakes and I looked into it and find it is the volumeManager problem. is just another potential data race in .

the rootDirectory and volumeManagerSyncTime race fixes are easy to reason about and fix code that looks like it could really race in currently enabled-by-default code looks like a real race in disabled-by-default code. I'll defer to kubelet folks and whether to mix that fix into
I think I should drop that fix. This will make things more clear.
Change:
defer f.statusLock.Unlock() return f.removeRuntime[uid] } <ins> func (f *fakePodWorkers) setPodRuntimeBeRemoved(uid types.UID) { f.statusLock.Lock() defer f.statusLock.Unlock() f.removeRuntime = map[types.UID]bool{uid: true} } </ins> func (f *fakePodWorkers) ShouldPodContentBeRemoved(uid types.UID) bool { f.statusLock.Lock() defer f.statusLock.Unlock()

Discussion:
pull-kubernetes-unit TestVolumeUnmountAndDetachControllerDisabled It failed on but after that the test is passing DATA RACE It seems that the data race is caused by below code It failing of test is Flaky, it was not reproducible on my local machine too, I have used below command to run the test output on my local machine I would like to work on this issue, is it possible to reproduce this issue locally?
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 testing
SIG Testing owns test frameworks, CI infrastructure, and other things to support testing. But this test is owned by SIG storage I believe since it tests their code, as we own tests that test our code.
Change:
// update security rules dirtySg := false var updatedRules []network.SecurityRule <del> if sg.SecurityRules != nil { updatedRules = *sg.SecurityRules </del> <ins> if sg.SecurityGroupPropertiesFormat != nil && sg.SecurityGroupPropertiesFormat.SecurityRules != nil { updatedRules = *sg.SecurityGroupPropertiesFormat.SecurityRules </ins> } for _, r := range updatedRules {

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: BUG REPORT /kind bug What happened: Created a service of type on Azure. The service is created successful and a LoadBalancer with public IP is created on Azure. kube-controller-manager goes into a crashloop What you expected to happen: LoadBalancer service receives public IP and is available for traffic How to reproduce it (as minimally and precisely as possible): provision a loadbalancer service on Azure with v1.10.3. 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 api-machinery /sig azure
Logs of the initial request to create the load balancer service:
/remove-sig api-machinery
fyi
FYI
BTW, this is with an Availability Set.
Update: my was missing: Once I it LoadBalancer services work. Still, we shouldn't panic in the main loop on this.
Thanks I think we can close this issue. Create another for handling errors in both the cloud provider and the controller.
/cc
/assign
Filed to fix this