jiebi/CodeConvo huggingface dataset:
Code change:
// Next, we compare the current list of endpoints with the list of master IP keys formatCorrect, ipCorrect, portsCorrect := checkEndpointSubsetFormatWithLease(e, masterIPs, endpointPorts, reconcilePorts) if formatCorrect && ipCorrect && portsCorrect { <del> return nil </del> <ins> return r.epAdapter.EnsureEndpointSliceFromEndpoints(corev1.NamespaceDefault, e) </ins> } if !formatCorrect {

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: EndpointSlice for masters was not created after enabling EndpointSlice on a pre-existing cluster. Only those EndpointSlices managed by kube-controller-manager were created. What you expected to happen: EndpointSlice for masters should be created after enabling EndpointSlice on a pre-existing cluster, the same as the EndpointSlices managed by kube-controller-manager. How to reproduce it (as minimally and precisely as possible): kubeadm to create a cluster: the EndpointSlice feature by editing the kube-apiserver, kube-controller-manager, kube-proxy manifest kube-apiserver and kube-controller-manager is restarted, the EndpointSlice in namespace will be missing. 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:
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved /assign
Code change:
local stack_skip="${3:-0}" stack_skip=$((stack_skip + 1)) <del> # Always print the error message, regardless of KUBE_VERBOSE value kube::log::error "${message}" # Additional debug information printed if KUBE_VERBOSE is 4 or greater </del> if [[ ${KUBE_VERBOSE} -ge 4 ]]; then local source_file=${BASH_SOURCE[${stack_skip}]} local source_line=${BASH_LINENO[$((stack_skip - 1))]}

Related discussion:
text: appears to have been trying to improve the logging in e2e test runs, but it seems to have affected much more than that, and now when a build fails, it logs so many useless messages that you have to scroll back to see why your compile actually failed. before: after: /assign cc (re )
GitHub didn't allow me to assign the following users: oxxenix. 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 : appears to have been trying to improve the logging in e2e test runs, but it seems to have affected much more than that, and now when a build fails, it logs so many useless messages that you have to scroll back to see why your compile actually failed. after: /assign cc (re ) 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
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
thanks for tracking this down. I agree that the additional error message is distracting and would like to see implemented differently so that it's not shown for manual invocations.
/sig release
do you have any tips or recommendations how to implement it differently? Thanks
It looks like that extra ouput is a from . I'd suggest to either revert or strip BASHCOMMAND from the error message if it's not that useful.
It looks like what you wanted in is the location and time stamp ("The update now displays both the specific location of the error in the code and a timestamp."), which is what we also get from the calltree after "make build". I would revert and then investigate why that shorter calltree is not shown after an E2E test failure. Keeping the calltree around as in Dan's "before" seems reasonable to me.
Code change:
local stack_skip="${3:-0}" stack_skip=$((stack_skip + 1)) <del> # Always print the error message, regardless of KUBE_VERBOSE value kube::log::error "${message}" # Additional debug information printed if KUBE_VERBOSE is 4 or greater </del> if [[ ${KUBE_VERBOSE} -ge 4 ]]; then local source_file=${BASH_SOURCE[${stack_skip}]} local source_line=${BASH_LINENO[$((stack_skip - 1))]}

Related discussion:
text: It shows a little bit more location info with the change. Here is how failure looks like with the change (but without BASH_COMMAND: and without the change:
I mean, the call tree is pretty useless in the "compile error" case... if your problem is that the code doesn't compile, you don't need to be told what part of the build scripts it is that invokes . It's just that before it was a small amount of useless output that was easy to ignore, whereas now it's a lot of useless output, which completely pushes the useful output offscreen. But IMO, "no backtrace" would be nicer than "short backtrace"... (I realize there are probably other cases where the backtrace is useful, and I'm not saying we should get rid of it in those cases, whatever they are.)
I agree, stack trace for compilation errors is quite useless. Unfortunately a lot of targets 'make test-e2e-node' included, build binaries, so we can't easily show traceback in one case and don't show in another. Removing BASH_COMMAND from the output looks like a good trade-off to me, though. It has a little bit more info(sometimes usefull) about callstack and less verbose than currently. I'm also ok with reverting and investigating later.
/assign
Code change:
if err != nil { return nil, err } <ins> // Fall back to ARM API if the address is empty string. // TODO: this is a workaround because IMDS is not stable enough. // It should be removed after IMDS fixing the issue. if strings.TrimSpace(ipAddress.PrivateIP) == "" { return addressGetter(name) } // Use ip address got from instance metadata. </ins> addresses := []v1.NodeAddress{ {Type: v1.NodeInternalIP, Address: ipAddress.PrivateIP}, {Type: v1.NodeHostName, Address: string(name)},

Related discussion:
text: <!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /sig azure What happened: The internal IP address is got from instance metadata. I suspect the instance metadata may not be stable, e.g. it has undocumented rate limits (refer ). Cross refer What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
Code change:
// ValidateServiceStatusUpdate tests if required fields in the Service are set when updating status. func ValidateServiceStatusUpdate(service, oldService *core.Service) field.ErrorList { allErrs := ValidateObjectMetaUpdate(&service.ObjectMeta, &oldService.ObjectMeta, field.NewPath("metadata")) <del> allErrs = append(allErrs, ValidateLoadBalancerStatus(&service.Status.LoadBalancer, field.NewPath("status", "loadBalancer"))...) </del> <ins> allErrs = append(allErrs, ValidateLoadBalancerStatus(&service.Status.LoadBalancer, field.NewPath("status", "loadBalancer"), &service.Spec)...) </ins> return allErrs }

Related discussion:
text: xref I think this may be one of the few cases where we can actually change the behavior in a "breaking" way. User creates service with , is empty Controller or user updates the status subresource, sets (not wiped or validated, should be) User updates in any way, is wiped It's clear that the is not meant to be set when is not "LoadBalancer". The question is: 1) Fail validation? 2) Silently discard the value? 3) Warn and then discard the value? 4) Just warn and leave it. Because we allowed it in the past, but it is so volatile, I lean towards 3. and - the people most familair with this type. Edit: PrepareForUpdate() runs before warnings. So: (1) is easy (2) is easy (4) is slightly less easy than (2) (3) is slightly less easy than (4)
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
OMG change it to clusterIP as expected Status is wiped update status as ClusterIP ... and if I edit the service back to loadbalancer it keeps the status??
/kind bug
/retitle Service can be set when !=
We talked about this one at the SIG Network meeting today. suggested we use the feature gate for deprecation option to phase the current (problematic) functionality out.
/triage accept
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /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
Code change:
testKubelet := newTestKubelet(t) kl := testKubelet.kubelet kl.nodeLister = testNodeLister{nodes: []api.Node{ <del> {ObjectMeta: api.ObjectMeta{Name: "testnode", Labels: map[string]string{"key": "B"}}}, </del> <ins> {ObjectMeta: api.ObjectMeta{Name: testKubeletHostname, Labels: map[string]string{"key": "B"}}}, </ins> }} testKubelet.fakeCadvisor.On("MachineInfo").Return(&cadvisorApi.MachineInfo{}, nil) testKubelet.fakeCadvisor.On("DockerImagesFsInfo").Return(cadvisorApiv2.FsInfo{}, nil)

Related discussion:
text: Looks like some kubelet unit tests perform a lookupIp which ends up depending on the health of the local resolver. Specifically has this failing: Which leads to the test in: And we recently swapped out the node names from testnode to 127.0.0.1, so probably the culprit?
/ref
Interesting. I did swap out the node names in the unit test as part of to be 127.0.0.1, party because I thought that it wouldn't have any problems resolving during unit tests.
/cc
Code change:
testKubelet := newTestKubelet(t) kl := testKubelet.kubelet kl.nodeLister = testNodeLister{nodes: []api.Node{ <del> {ObjectMeta: api.ObjectMeta{Name: "testnode", Labels: map[string]string{"key": "B"}}}, </del> <ins> {ObjectMeta: api.ObjectMeta{Name: testKubeletHostname, Labels: map[string]string{"key": "B"}}}, </ins> }} testKubelet.fakeCadvisor.On("MachineInfo").Return(&cadvisorApi.MachineInfo{}, nil) testKubelet.fakeCadvisor.On("DockerImagesFsInfo").Return(cadvisorApiv2.FsInfo{}, nil)

Related discussion:
text: cc
What is the environment where you are running the tests? They pass for me on my mac, a linux box, and shippable seems to be passing them as well.
I couldn 't reproduce the failure either.
I'm out right now; i'll try them when i get back. For the record, I run hack/test- Paul Morie wrote:
Ahem FTR This acronym is going to go quad-plat Paul Morie wrote:
I ran on both platforms and saw the tests pass.
I'm still seeing it. Won't have bandwidth to dig in personally until tomorrow.
seeing a similar failure after a git pull
I knew I wasn't crazy
environment: fedora 21, golang: 1.4, docker: 1.6
I think I see the problem. When I set the node name to in the test I was assuming it would parse as a valid ip address and not end up at the LookupIP call. But only the node name (and not the kubelet hostname) is being set (except in my new test where I ) so it's trying to do a lookup. Do you think you could test just changing the default hostname from "testnode" to "127.0.0.1" and see if that fixes it for you?
Trying now
I still get failures but no panic / threaddump.
gist coming
this looks like again?
Good that it isn't panicing any longer. I can dig into the test failures tomorrow (I think it should be relatively simple to resolve).
cool, thanks for looking
Passes in master now for me. Closing.
FYI, they will break again once goes in, and then we can merge my PR to see if that fixes it for you.
:+1:
is in -- are these tests breaking again?
I just rebased which I think will fix them.
They are breaking again.
is on it.
Code change:
} } <ins> func TestMinionRESTWithHealthCheck(t *testing.T) { minionRegistry := registrytest.NewMinionRegistry([]string{}, api.NodeResources{}) minionHealthRegistry := HealthyRegistry{ delegate: minionRegistry, client:   &notMinion{minion: "m1"}, } ms := NewREST(&minionHealthRegistry) ctx := api.NewContext() c, err := ms.Create(ctx, &api.Minion{ObjectMeta: api.ObjectMeta{Name: "m1"}}) if err != nil { t.Errorf("insert failed") } result := <-c if m, ok := result.Object.(*api.Minion); !ok || m.Name != "m1" { t.Errorf("insert return value was weird: %#v", result) } if _, err := ms.Get(ctx, "m1"); err == nil { t.Errorf("node is unhealthy, expect no result from apiserver") } } </ins> func contains(nodes *api.MinionList, nodeID string) bool { for _, node := range nodes.Items { if node.Name == nodeID {

Related discussion:
text: apiserver reports creation failure if a node is not ready (unhealthy, or kubelet is not ready), but the api object is already stored in master. extracted from and A short term solution is to have health_registry check node health upon creation, not just on retrieving. Or ignore unhealthy node. A long term solution might fall into the interface revamp
Why can't apiserver accept an unhealthy minion.
What's the point of having an unhealthy minion that we'll never be able to use? One reason I can think of is that the minion can later becomes healthy and thus a valid node in k8s. But for now, as we don't have the ability to handle unhealthy node, delegate the responsibility to user makes more sense. However, I admit the title is misleading. What I really what to convey is that kubernetes currently allow registrying unhealthy node, by storing it in RESTStorage. But the create operation reports fail because the node can't pass health checking. I don't think this is the right behavior. We can either return success and do health check later, or return failure and do not store it. (i prefer the latter one for the above reason).
I tend to think that we should accept unhealthy minions - minions may go in and out of health, or go up and down at any time - so trying ensure health at registration time seems like a fruitless effort since we have to handle the error cases anyway.
I've no problem with accepting unhealthy minions, and I agree with your point. The real problem here is that the apiserver returns an inconsistent status. For example, if I have an unhealthy minion that I want to registry. From user's perspective, the registration fails, because apiserver returns an error (resource not found). So I retry, but apiserver returns failure again; this time, the error is resource already exists, no matter the minion is healthy or not.
- yes, we should remove the health check as part of the registration and just report success. agree there is inconsistency.
+1 On Nov 7, 2014 8:48 AM, "Derek Carr" wrote:
Seems like it's a clients responsibility to warn the user that a node might not be available prior to it being , but the the master's responsibility to assume that all properly specified nodes are reachable before making decisions regarding using a node.
Code change:
} } <ins> func TestMinionRESTWithHealthCheck(t *testing.T) { minionRegistry := registrytest.NewMinionRegistry([]string{}, api.NodeResources{}) minionHealthRegistry := HealthyRegistry{ delegate: minionRegistry, client:   &notMinion{minion: "m1"}, } ms := NewREST(&minionHealthRegistry) ctx := api.NewContext() c, err := ms.Create(ctx, &api.Minion{ObjectMeta: api.ObjectMeta{Name: "m1"}}) if err != nil { t.Errorf("insert failed") } result := <-c if m, ok := result.Object.(*api.Minion); !ok || m.Name != "m1" { t.Errorf("insert return value was weird: %#v", result) } if _, err := ms.Get(ctx, "m1"); err == nil { t.Errorf("node is unhealthy, expect no result from apiserver") } } </ins> func contains(nodes *api.MinionList, nodeID string) bool { for _, node := range nodes.Items { if node.Name == nodeID {

Related discussion:
text: There's very little difference between an admin stopping a VM without clearing Kube and adding a node to the cluster prior to it being fully reachable (I think).
"clients responsibility" ? if we enable kubectl to create minions, it would be kubectl who should check if the minion is reachable and complain? I'm not sure what 'client' means. (but I agree 100%, don't report failure adding a minion just because it isn't reachable)
node controller plugin should also give warning
Code change:
defer backendServer.Close() defer func() { <del> if called != tc.ExpectCalled { </del> <ins> if called := atomic.LoadInt32(&timesCalled) > 0; called != tc.ExpectCalled { </ins> t.Errorf("%s: expected called=%v, got %v", tcName, tc.ExpectCalled, called) } }()

Related discussion:
text: 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
/sig api-machinery
Code change:
#     sleep 4 #     i=$[$i+1] #   done <del> apiVersion: v1beta1 </del> <ins> apiVersion: v1beta3 </ins> kind: Pod <del> id: synthetic-logger-10lps-pod desiredState: manifest: version: v1beta1 id: synth-logger-10lps containers: - name: synth-lgr image: ubuntu:14.04 command: ["bash", "-c", "i="0"; while true; do echo -n "`hostname`: $i: "; date --rfc-3339 ns; sleep 0.1; i=$[$i+1]; done"] labels: name: synth-logging-source </del> <ins> metadata: creationTimestamp: null labels: name: synth-logging-source name: synthetic-logger-10lps-pod spec: containers: - args: - bash - -c - 'i="0"; while true; do echo -n "`hostname`: $i: "; date --rfc-3339 ns; sleep 0.1; i=$[$i+1]; done' image: ubuntu:14.04 name: synth-lgr </ins>

Related discussion:
text: Hi , I followed the instructions in examples/logging-demo, and there was no "external IP" field for elasticsearch-logging or kibana-logging, as shown below: I start up my cluster via cluster/kube- Did I miss something or is it a bug? Thanks.
Correct. This demo does not create an ELB so there is no external IP address. Access is via service proxy at the master. Type: and you should see the URLs for Elasticsearch and Kibana.
please let us know whether: a. Satnam's comment resolves your issue b. the demo should be updated to prevent this misunderstanding c. the issue isn't resolved Thank you!
Yes, Satnam's comment resolve the issue. I updated the demo in .
Awesome, thanks for sending the patch! We'll discuss there. Always fantastic to have docs updated regularly by folks trying them.
Code change:
if err != nil { return err } <ins> if len(rsrc.Versions) == 0 { return fmt.Errorf("ThirdPartyResource %s has no defined versions", rsrc.Name) } </ins> plural, _ := meta.KindToResource(unversioned.GroupVersionKind{ Group:   group, Version: rsrc.Versions[0].Name,

Related discussion:
text: FYI. Currently the field of TPR is marked as which is wrong, actually if you try to create a TPR with empty versions, it will cause api server panic. Versions should be necessary field of TPR, we should validate this somehow.
Code change:
return unmountedVolumes } <ins> func (asw *actualStateOfWorld) SyncReconstructedVolume(volumeName v1.UniqueVolumeName, podName volumetypes.UniquePodName, outerVolumeSpecName string) { asw.Lock() defer asw.Unlock() if volumeObj, volumeExists := asw.attachedVolumes[volumeName]; volumeExists { if podObj, podExists := volumeObj.mountedPods[podName]; podExists { if podObj.outerVolumeSpecName != outerVolumeSpecName { podObj.outerVolumeSpecName = outerVolumeSpecName asw.attachedVolumes[volumeName].mountedPods[podName] = podObj } } } } </ins> func (asw *actualStateOfWorld) newAttachedVolume( attachedVolume *attachedVolume) AttachedVolume { return AttachedVolume{

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 --We have even encountered such case that pod continuously reports “Unable to attach or mount volumes for pod;...” when kubelet restarted. The reasons are listed in details as below: , as result of apiserver instantaneous unstablility, dswp get pvc‘s pv spec failed, then the pvc volume does not be to dsw. , syncStates() lists all the volume directories locally, and recontructs the volume from local volume, if the volume isn't in dsw, it will put the recontructed volume to asw, but now the volume.OuterVolumeSpecName isn't correct. chance, at this time, In , the fail to pvc volume is to dsw again normally in reconcile() -mountAttachVolumes(), it compares dsw and asw by volume's innerVolumename, it's all the same. but it could not sense the OuterVolumeSpecName dismatch. so it will not re-mount again to update asw cache , it checks pod's volume attach or mount success by comparing volume.OuterVolumeSpecName and , but this pv'c OuterVolumeSpecName isn't correct in asw. so pod continuously reports “Unable to attach or mount volumes for pod;...” reconcile() could sense the reconstruct volume's dismatch to the dsw, then re-mount again to make volume cache consistency Kubernetes version (use ): 1.19.4 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 node
/triage accepted
/assign
CC
I think this is a point that can be optimized. /cc
I will give a fix for this
Thanks for reporting the issue, this innerSpecName and outerSpecName are confusing and cause issues. Please ping me for review when you have a fix. Thanks!
Please don't triage your own issues immediately, give someone else a chance to review them :( /sig storage
okay, I know
Code change:
// DetachDisk detaches the disk specified by vmDiskPath func (vm *VirtualMachine) DetachDisk(ctx context.Context, vmDiskPath string) error { <del> vmDiskPath = RemoveStorageClusterORFolderNameFromVDiskPath(vmDiskPath) </del> device, err := vm.getVirtualDeviceByPath(ctx, vmDiskPath) if err != nil { klog.Errorf("Disk ID not found for VM: %q with diskPath: %q", vm.InventoryPath, vmDiskPath)

Related discussion:
text: When user creates a static PV using folder name in path: on vSAN backed datastore then detach disk does not work because check fails - The code expects folder name to be UUID but it does not and hence it determines disk is not attached to the node and hence no detach is ever performed. /sig storage cc