jiebi/CodeConvo huggingface dataset:
Change:
lb.lock.RLock() defer lb.lock.RUnlock() state, exists := lb.services[svcPort] <del> // TODO: while nothing ever assigns nil to the map, *some* of the code using the map // checks for it.  The code should all follow the same convention. return exists && state != nil && len(state.endpoints) > 0 </del> <ins> if !exists || state == nil { return false } return len(state.endpoints) > 0 </ins> } // NextEndpoint returns a service endpoint.

Discussion:
As suggested in , some portions of the code contains the map checking for nil values in map, and others don't have. Even though we're never assigning nil values to this map, we should standardize the portions that does not have this check in module. Example: Should be like this: I can take care of this issue.
/sig network
There have been discussions of deprecating the user-space proxier. Maybe transfer it to . A question is if anybody still uses it. Seems like you do, so if possible please explain if you have a use-case where the user-space proxier is wanted/needed.
Hey Actually, I was casually reading the source code and I saw a over there regarding the nil checks. Regarding your question, we should check if anyone actually uses it though, or maybe discuss its usage or deprecation a little further.
Quick question though: I saw in the news that the user-space proxy porting was near completion, maybe it's worth talking to them in order to check upon the status.
I don't object to making it clearer or more consistent, if you want to spend time on it, but it's not a high priority. That said, I think a nil value in that map would be really bad (and should be impossible) and I don't know how we would raise a signal about it.
let us know if you want to try to fix it, otherwise we can just close this.
I already opened a PR with the clearer nil checks for this specific module in , so you can review it. I think whether this would have nil values into the service map we should discuss this apart and try to reproduce this case (if any would happen).
PR submitted, so let's review and discuss further there. /assign dcbw /triage accepted
Change:
"k8s.io/kubernetes/pkg/api" "k8s.io/kubernetes/pkg/apis/apps" "k8s.io/kubernetes/pkg/client/cache" <ins> fake_internal "k8s.io/kubernetes/pkg/client/clientset_generated/internalclientset/fake" "k8s.io/kubernetes/pkg/client/clientset_generated/internalclientset/typed/apps/unversioned" "k8s.io/kubernetes/pkg/client/clientset_generated/internalclientset/typed/apps/unversioned/fake" </ins> "k8s.io/kubernetes/pkg/controller" "k8s.io/kubernetes/pkg/util/errors" )

Discussion:
Is this a request for help? Nope What keywords did you search in Kubernetes issues before filing this one? petset replicas current desired Is this a BUG REPORT or FEATURE REQUEST? BUG Kubernetes version Client Version: version.Info{Major:"", Minor:"", GitVersion:"v0.0.0-master+", GitCommit:"", GitTreeState:"not a git tree", BuildDate:"2016-09-01T10:49:36Z", GoVersion:"go1.6.2", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"", Minor:"", GitVersion:"v0.0.0-master+", GitCommit:"", GitTreeState:"not a git tree", BuildDate:"2016-09-01T10:49:36Z", GoVersion:"go1.6.2", Compiler:"gc", Platform:"linux/amd64"} Environment: Cloud provider or hardware configuration: 24 cores, 64 GB RAM OS Arch Linux Kernel (e.g. ): Linux hostname 4.4.13-1-lts SMP Wed Jun 8 16:44:31 CEST 2016 x86_64 GNU/Linux Install tools: local-cluster- Others: What happened: While creating PetSet based on this tutorial: first PetSet pod was stuck in pending state due to lack of PersistentVolumes in cluster. When getting the petset info via I expected to see "CURRENT" set to 1, while the kubectl output was as follows: While clearly shows that only one pod is created: In json and yaml output, status.replicas value was also 2. What you expected to happen: I expected that CURRENT value shown by kubectl would be due to only one pod being created. How to reproduce it (as minimally and precisely as possible): Create via on empty cluster and run and . Anything else do we need to know: Nope
CURRENT is the number of pods that have been created, not that they are READY. See for example the latest api change for replica sets where we exactly for this reason. All controllers (petsets, daemonsets, deployments, etc.) should have ReadyReplicas cc:
See also
I guess it doesn't work anyway, since only one pod was created for this PetSet, but the CURRENT says that 2 were created. I will change bug description then.

Hmm, the idea is to sync every pet periodically, but only create them one at a time. The logic that counts status.replicas is wrong. This counter shouldn't be incremented in the case where we didn't update/sync or create a pet: Today we do increment it all pet creation is blocked on the first pet becoming unhealthy. Should be an easy fix if anyone wants to jump in ( fyi) otherwise I'll get to it once 1.4 is out.
I can try to fix it if that's OK. Thanks for the pointer to the source code!
Please do, co-assigned
Change:
capPath := specPath.Child("capacity") for r, qty := range pv.Spec.Capacity { allErrs = append(allErrs, validateBasicResource(qty, capPath.Key(string(r)))...) <ins> allErrs = append(allErrs, ValidatePositiveQuantityValue(qty, capPath.Key(string(r)))...) </ins> } if len(string(pv.Spec.PersistentVolumeReclaimPolicy)) > 0 { if !supportedReclaimPolicy.Has(string(pv.Spec.PersistentVolumeReclaimPolicy)) {

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: BUG REPORT /kind bug What happened: If someone requests a zero (0) capacity PVC and an administrator creates a zero (0) capacity PV, Kubernetes will happily bind them together. Unfortunately, any use of this PVC/PV combination by a pod will fail. It fails because the zero capacity PV cannot be formatted or mounted successfully. Note: The same issue happens for dynamically provisioned PVs. What you expected to happen: I expect that Kubernetes would not allow creation of invalid PVC and PV objects, aka zero (0) capacity PVs and PVCs. How to reproduce it (as minimally and precisely as possible): Create a pod that requests a zero capacity PVC, using dynamic PV provisioning is simpler than creating your own zero (0) capacity PV. The pod will fail to reach a running state, since the related PV fails to be formatted and mounted successfully. Here is the error that I received for a test I performed requesting a zero capacity PVC using ceph rbd: Anything else we need to know?: Here is a related item with a specific fix for external ceph rbd provisioner: Environment: Nothing specific to environment
/sig storage
/assign
Change:
return e2epod.NewPodClient(f).Create(ctx, pod) } <del> func expectSoftRejection(status v1.PodStatus) { </del> <ins> func expectRejection(status v1.PodStatus) { </ins> args := []interface{}{"PodStatus: %+v", status} <del> gomega.Expect(status.Phase).To(gomega.Equal(v1.PodPending), args...) </del> <ins> gomega.Expect(status.Phase).To(gomega.Equal(v1.PodFailed), args...) </ins> gomega.Expect(status.Reason).To(gomega.Equal("AppArmor"), args...) gomega.Expect(status.Message).To(gomega.ContainSubstring("AppArmor"), args...) <del> gomega.Expect(status.ContainerStatuses[0].State.Waiting.Reason).To(gomega.Equal("Blocked"), args...) </del> } func isAppArmorEnabled() bool {

Discussion:
/kind failing-test <!-- If this is a flake, please add: /kind flake --/sig node
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
Failures look like started when landed
Change:
} refRelated, err := reference.GetReference(recorder.scheme, related) if err != nil { <del> klog.Errorf("Could not construct reference to: '%#v' due to: '%v'.", related, err) </del> <ins> klog.V(9).Infof("Could not construct reference to: '%#v' due to: '%v'.", related, err) </ins> } if !util.ValidateEventType(eventtype) { klog.Errorf("Unsupported event type: '%v'", eventtype)

Discussion:
Per the comments in v1beta1 Event: The field claimed to be optional, but an error is dumped if it's illegal - including the case: This doesn't look right as it means the caller which passes in Related field will always get an err, for example, the scheduler binding event: If appropriate, I'm gonna raise a PR to tolerate the nil case. please advice.
/sig scheduling /sig api-machinery
/assign I'll update the log to info or warning cc
It shouldn't be warning - it's a valid and allowed case. I'm wondering if we even should be logging info, but maybe we can for now.
/assign
Change:
// Check that the hostname known by the master matches the hostname // the kubelet knows hostname := s.host.GetHostname() <del> if masterHostname != hostname { </del> <ins> if masterHostname != hostname && masterHostname != "127.0.0.1" && masterHostname != "localhost" { </ins> s.error(w, errors.New("Kubelet hostname ""+hostname+"" does not match the hostname expected by the master ""+masterHostname+""")) return }

Discussion:
We've run into issues like where the Kubelet was up but not healthy. The monit monitoring for Kubelet should ensure it is "healthy" rather than just alive. We need to define what healthy means in this context and monitor it based on that. An alternate option is for the Kubelet to exit when it gets into a situation it can't serve from. This may lead to crashloops so we'd need to be careful going this route. The answer is probably a bit of both.
Courtesy of healthchecking with monit:
Health check is under this umbrella issue:
Will send a PR shortly.
Change:
}, Spec: batchv1.CronJobSpec{ Schedule:          "* * * * ?", <del> ConcurrencyPolicy: batchv1.AllowConcurrent, </del> <ins> ConcurrencyPolicy: "Allow", </ins> JobTemplate: batchv1.JobTemplateSpec{ ObjectMeta: metav1.ObjectMeta{ Labels:      map[string]string{"a": "b"},

Discussion:
in TestControllerV2SyncCronJob, there are many listing the properties that don't matter (like nil, false). and many constants F and T, which is unnecessary. As per 's request, We shouldn't be listing the properties that don't matter (like nil, false). And get rid of constants F and T check No response <details</details<detailsNone </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
/assign I would like to work on the optimization
It's not an optimization. It's just about readability.
/remove-kind bug /kind cleanup
/sig apps
Change:
"github.com/GoogleCloudPlatform/kubernetes/pkg/api" "github.com/GoogleCloudPlatform/kubernetes/pkg/client" <ins> "github.com/GoogleCloudPlatform/kubernetes/pkg/client/cache" "github.com/GoogleCloudPlatform/kubernetes/pkg/controller/framework" </ins> "github.com/GoogleCloudPlatform/kubernetes/pkg/fields" "github.com/GoogleCloudPlatform/kubernetes/pkg/labels" <ins> "github.com/GoogleCloudPlatform/kubernetes/pkg/runtime" </ins> "github.com/GoogleCloudPlatform/kubernetes/pkg/util" "github.com/GoogleCloudPlatform/kubernetes/pkg/util/wait" <ins> "github.com/GoogleCloudPlatform/kubernetes/pkg/watch" </ins> "github.com/golang/glog" . "github.com/onsi/ginkgo"

Discussion:
Currently the density tests are ok if all the pods come up eventually. We should verify there are no failure/error events while the pods are coming up. This could indicate issues dealing with the number of pods and should be investigated.
has been merged, and there's already an issue filed for followup actions, so I think we can close this.
Change:
// before Remove event, in which case the state would change from Assumed to Added. case ok && !cache.assumedPods[key]: if currState.pod.Spec.NodeName != pod.Spec.NodeName { <del> glog.Errorf("Pod %v removed from a different node than previously added to.", key) </del> <ins> glog.Errorf("Pod %v was assumed to be on %v but got added to %v", key, pod.Spec.NodeName, currState.pod.Spec.NodeName) </ins> glog.Fatalf("Schedulercache is corrupted and can badly affect scheduling decisions") } err := cache.removePod(currState.pod)

Discussion:
/kind bug There are several error messages in the scheduler cache that are confusing to read, at least one of these surfaced up to end users via Events. I noticed these two in particular but there may be others: Whether or not these should actually be surfacing as events, the messages should be cleaned up.
cc
Seems that these are internal or implement details in scheduler, do our end users can fully understand what the events really mean? I think it is depend on our own implement. idea?
I believe, the problem is with in the message but I am not able to reproduce it, can you please share steps to reproduce this.
No unfortunately, one of our users reported seeing it when there system was in a bad state, not in a reproducible way. The point of the issue is just that the grammar in those messages is bad, which should be fixable even if you can't get them to fire.
Change:
source := &v1.HostPathVolumeSource{ Path: "/tmp", } <del> pod := testPodWithHostVol(volumePath, source, true) </del> <ins> // we can't spawn privileged containers on Windows, nor do we need to. privileged := !framework.NodeOSDistroIs("windows") pod := testPodWithHostVol(volumePath, source, privileged) </ins> pod.Spec.Containers[0].Args = []string{ fmt.Sprintf("--new_file_0644=%v", filePath),

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --/sig testing /sig windows /area conformance Which jobs are failing: N/A Which test(s) are failing: [sig-storage] HostPath should support r/w [NodeConformance] [sig-storage] HostPath should support subPath [NodeConformance] Since when has it been failing: Before 2019-03-07. Since then, the Windows nodes' kubelet service has been passed the , which allows the test to pass. Testgrid link: (older than 2019-03-07) Reason for failure: The tests are trying to spawn pods with a HostPath volume ( folder has 777 file permissions by default, meaning it should pass without privileged access. The tests have turned green in the linked testgrid because the Windows Kubelet flag ` has been set to true, but it shouldn't have been necessary in the first place. Anything else we need to know:
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. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Change:
"net/http" "github.com/GoogleCloudPlatform/kubernetes/pkg/health" <ins> "github.com/golang/glog" </ins> ) type HealthyMinionRegistry struct {

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 --Exclude node from LoadBalancer (via kubectl label node node1) leads to failing reconciliation of the existing load balancer services in the cluster with following error: The legacy provider azure is not using an AvailablilitySet as it it running with those cloudprovider config: Creating new load balancer services have the effect that they are stuck in due to same issue. Service reconciliation should succeed. Create an Azure k8s cluster with with an Azure cloud controller manager based on legacy-cloud-provider azure in the corresponding k8s version Configure the cloud controller manager to use the feature gate Create a service of type LoadBalancer in the cluster and wait until it was created Label a node with Check the cloud-controller-manager logs New load balancer services will now stuck in Pending state Maybe related to but should be fixed with Kubernetes version (use ): Cloud provider or hardware configuration: Azure OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /kind bug /sig cloud-provider /area provider/azure cc
/assign
/triage accepted
/assign
, thanks for the fix. Can you also create a cherry-pick to kubernetes/kubernetes
we hit a similar issue in in-tree provider as well, could you please help cherry-pick the fix to 1.20 and later release? Thanks.
Here are the cherry-picks to k/k:
Change:
Adding new fields or API types *is* expected to modify these fixtures. To regenerate them, run: ```sh <del> UPDATE_COMPATIBILITY_FIXTURE_DATA=true go test ./vendor/k8s.io/api -run //HEAD </del> <ins> UPDATE_COMPATIBILITY_FIXTURE_DATA=true go test k8s.io/api -run //HEAD </ins> ``` ## Previous versions

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 --I tried rebasing an old open PR, and got merge conflicts on api testdata. I read and tried the command listed there for regenerating the test data. It failed as follows. I expected successful regeneration of the api test data. Checkout and issue the command exhibited above. Kubernetes version (use ): is at commit right nowCloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/cc
ah, latest go versions changed the invocation to
fixed in
/triage accepted
Change:
t.Errorf("unexpected error: %v", err) } if len(times) != 1 { <del> t.Errorf("expected 2 start times, got: , got: %v", times) </del> <ins> t.Errorf("expected 1 start times, got: %v", times) </ins> } else if !times[0].Equal(T2) { t.Errorf("expected: %v, got: %v", T1, times[0]) }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: Unit test error message match the conventional Go style: For example: if got, want := set.Status.Replicas, 3; got != want { t.Errorf("set.Status.Replicas = %v; want %v", got, want) }
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 testing
/assign
/reopen
Change:
} ?> ``` <del> To play with the service itself, find the name of a frontend, grab the external IP of that host from the Google Cloud Console, and visit http://&lt;host-ip&gt;:8080, note you may need to open the firewall for port 8080 using the console or the gcloud tool. </del> <ins> To play with the service itself, find the name of a frontend, grab the external IP of that host from the Google Cloud Console, and visit http://&lt;host-ip&gt;:8080. Note, you may need to open the firewall for port 8080 using the console or the gcloud tool. </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 --What happened: The image () used to run the per-pod infra/pause container logs to stdout about once per second. What you expected to happen: Pause container not logging anything. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Kubelet does not expose, nor manage these logs. Writing the logs wastes resources and takes up disk space, which may not be properly accounted by kubelet. The pause image used for the e2e tests seems much better: 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:
/assign Will also rebuild with
Change:
} if event.Type == watch.Error { util.HandleError(fmt.Errorf("error from watch during sync: %v", errors.FromObject(event.Object))) <ins> // Clear the resource version, this may cause us to skip some elements on the watch, // but we'll catch them on the synchronize() call, so it works out. *resourceVersion = "" </ins> continue } glog.V(4).Infof("Got watch: %#v", event) rc, ok := event.Object.(*api.ReplicationController) if !ok { <ins> if status, ok := event.Object.(*api.Status); ok { if status.Status == api.StatusFailure { glog.Errorf("failed to watch: %v", status) // Clear resource version here, as above, this won't hurt consistency, but we // should consider introspecting more carefully here. (or make the apiserver smarter) // "why not both?" *resourceVersion = "" continue } } </ins> util.HandleError(fmt.Errorf("unexpected object: %#v", event.Object)) continue }

Discussion:
wrote: I just ran across this the other day. but I am seeing the error in the service. Here is a sample of the output. I am running v0.8.2. I can get the behavior to go away temporarily by rebooting the node or restarting the service but it always seems to come back eventually.