jiebi/CodeConvo huggingface dataset:
Change:
var map_EndpointConditions = map[string]string{ "":            "EndpointConditions represents the current condition of an endpoint.", <del> "ready":       "ready indicates that this endpoint is prepared to receive traffic, according to whatever system is managing the endpoint. A nil value indicates an unknown state. In most cases consumers should interpret this unknown state as ready. For compatibility reasons, ready should never be "true" for terminating endpoints.", </del> <ins> "ready":       "ready indicates that this endpoint is prepared to receive traffic, according to whatever system is managing the endpoint. A nil value indicates an unknown state. In most cases consumers should interpret this unknown state as ready. For compatibility reasons, ready should never be "true" for terminating endpoints, except when the normal readiness behavior is being explicitly overridden, for example when the associated Service has set the publishNotReadyAddresses flag.", </ins> "serving":     "serving is identical to ready except that it is set regardless of the terminating state of endpoints. This condition should be set to true for a ready endpoint that is terminating. If nil, consumers should defer to the ready condition.", "terminating": "terminating indicates that this endpoint is terminating. A nil value indicates an unknown state. Consumers should interpret this unknown state to mean that the endpoint is not terminating.", }

Discussion:
The EndpointSlice API says and it works as expected in normal circumstances I delete the pod and the endpoints conditions are the expected However, if during this time I set we run into an incoherence with the API doc, but it seems that we already documented this edge case in the code I think that at this point is just to amend this information to the API, no? /kind bug /kind documentation
/sig network /assign
I would like to work on this. I just want a bit more clarification on what needs to be done!
I proposed a solution, that is clarify it in the doc ... once we reach an agreement in this issue we implement it ...
+1 to docs. I'd make it a little more vague, like: """ when the normal readiness behavior is being explicitly overridden, for example when the associated Service has set the publishNotReadyAddresses flag. """
so, the thing is to update the docs here with Tim's suggestion and here and do to update the generated code and submit a PR
/assign
I am not able to run command in windows, I am checking it. This error message is coming: *
/triage accepted
Is there a PR for this? Happy to review
I will raise the PR if my above problem gets solved. I am trying to make an update but the error mentioned above is coming.
What platform are you on? If the Makefile were really broken EVERYTHING would be failing.
he's on windows ... you will need a linux/macos. see
Let me know if you want someone to take it over.
I think in that case, you can assign this to someone else.
Change:
# Set artifacts directory export ARTIFACTS_DIR=${WORKSPACE}/artifacts <del> retry go get github.com/tools/godep && godep version </del> export LOG_LEVEL=4 cd /go/src/k8s.io/kubernetes

Discussion:
Didn't see an issue for this. Godep recently updated its version to v80. This broke several builds that directly godep, grabbing latest. /kind bug cc Example https://k8s- Here are some examples where we grab master:
We have helpers to grab godep. We should use them everywhere.
/cc
/assign
Change:
<del> ## Contributor guidelines 1. Please read our [contributor guidelines](https://github.com/kubernetes/kubernetes/blob/master/CONTRIBUTING.md). 1. See our [developer guide](https://github.com/kubernetes/kubernetes/blob/master/docs/devel/development.md). 1. Follow the instructions for [labeling and writing a release note for this PR](https://github.com/kubernetes/kubernetes/blob/master/docs/devel/pull-requests.md#release-notes) in the block below. (_this would also contain updated detail later about this new template_) ```release-note * Use the release-note-* labels to set the release note state * Clear this block to use the PR title as the release note -OR- * Enter your extended release note here ``` </del>

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: Using example for from documentation failed with: What you expected to happen: Example from documentation works. How to reproduce it (as minimally and precisely as possible): How should configuration look like for ? Environment: Kubernetes version (use ):OS (e.g: ):Kernel (e.g. ):
/sig scheduling
/triage accepted oh, I missed a dash. It should be: Would you mind sending a PR to kubernetes/website?
Change:
{ Name:    "busybox-container", Image:   "gcr.io/google_containers/busybox:1.24", <del> Command: []string{"sh", "-c", "ping -c 1 google.com; while true; do echo 'hello world' | tee /test-empty-dir-mnt/file ; sleep 1; done"}, </del> <ins> Command: []string{"sh", "-c", "ping -c 1 google.com; while true; do echo 'hello world' >> /test-empty-dir-mnt/file ; sleep 1; done"}, </ins> Resources: api.ResourceRequirements{ Limits: api.ResourceList{ // Must set memory limit to get MemoryStats.AvailableBytes

Discussion:
https://k8s- Failed: [] Summary API when querying /stats/summary should report resource usage through the stats api {E2eNode Suite}
The test failed because the busybox container was crash-looping, but I'm not sure why.
https://k8s- Failed: [] Summary API when querying /stats/summary should report resource usage through the stats api {E2eNode Suite}
https://k8s- Failed: [] Summary API when querying /stats/summary should report resource usage through the stats api {E2eNode Suite}
https://k8s- Failed: [] Summary API when querying /stats/summary should report resource usage through the stats api {E2eNode Suite}
https://k8s- Failed: [] Summary API when querying /stats/summary should report resource usage through the stats api {E2eNode Suite}
https://k8s- Failed: [] Summary API when querying /stats/summary should report resource usage through the stats api {E2eNode Suite}
https://k8s- Failed: [] Summary API when querying /stats/summary should report resource usage through the stats api {E2eNode Suite}
https://k8s- Failed: [] Summary API when querying /stats/summary should report resource usage through the stats api {E2eNode Suite}
- Any ideas what changed in the past week that would cause the Kubelet usage/working set memory usage to suddenly increase? It may be a non-issue, but it's concerning that this seems to have recently changed. - This is only happening on GCI. Did we change the GCI image being tested recently?
https://k8s- Failed: [] Summary API when querying /stats/summary should report resource usage through the stats api {E2eNode Suite}
Last image version update for testing was 11 days ago () though we are soon going to update it again ().
Since we increased the bound on (), we should also increase the bound on ( is usage - total inactive file). I think this may be the cause of this flake.
I agree that the bounds should match, but the cause of both flakes (why usage & workingset suddenly increased) is still unknown.
Usage workingset so it may not be necessary to bump both ;) I think this may be the caused by the gci mounter.

/cc
https://k8s- Failed: [] Summary API when querying /stats/summary should report resource usage through the stats api {E2eNode Suite}
https://k8s- Failed: [] Summary API when querying /stats/summary should report resource usage through the stats api {E2eNode Suite}
I checked the log from the last failure, didn't see anything related to gci mounter. The test failed on trusty node which mounter should not be used at all.
Yes, the latest failures are just a flake introduced by The bounds need to be adjusted for the misc container. I'll send a PR soon.
Change:
// of volume creation. epServiceName := dynamicEpSvcPrefix + p.options.PVC.Name epNamespace := p.options.PVC.Namespace <del> endpoint, service, err := p.plugin.createEndpointService(epNamespace, epServiceName, dynamicHostIps, p.options.PVC.Name) </del> <ins> endpoint, service, err := p.createEndpointService(epNamespace, epServiceName, dynamicHostIps, p.options.PVC.Name) </ins> if err != nil { glog.Errorf("glusterfs: failed to create endpoint/service: %v", err) deleteErr := cli.VolumeDelete(volume.Id)

Discussion:
several operations to the glusterfs mount operation that nodes are not permitted to perform: looks up arbitrary secrets based on storage class parameters. this will not succeed, as the node authorizer will only allow nodes access to secrets referenced by pods or persistent volumes used by the node attempts to create a service and endpoint using the node's API client. nodes do not have permission to create arbitrary endpoints and services. For both of those reasons, that recreate operation will fail when attempted from the node. The recreate operation should probably move to one of the storage-related controllers (provisioner or attach/detach) cc
Marking this with 1.7 milestone until we have a better idea of whether this is blocking or not for the 1.7 release.
CC Is the endpoint originally created by the user or by the volume plugin creating/deleting Endpoint objects? In addition to the concerns raised, having a volume create new API objects seems like a bad idea (abstraction layer violation?).
From on Slack: Unless there is justification otherwise, I will roll back the PR on Monday.
cc/
revert button doesn't work, have to do it manually
Revert PR is approved and awaiting merge (). Once that merges this issue can be closed.
Opened an E2E pr to catch this kind of behavior in the future. WIP, still exploring a method to reproduce and catch the behavior.
Change:
## Version 1.6 (Wed June 29 2016 Girish Kalele <gkalele@google.com>) - Godeps update for vendor code (skydns/mux) <ins> ## Version 1.7 (Wed August 24 2016 Zihong Zheng <zihongz@google.com>) - Add support for ExternalName services (pr #31159) </ins>

Discussion:
Now that merged, we need to build a new kube-dns release.
I just put in a PR yesterday to fix the missing changelog entry for kube-dns:1.6
Change:
http_archive( name = "io_bazel_rules_go", <del> sha256 = "f9cc31e9d66dad1154de3c214158916411040e2c2614e4fbc2bab67330e95f82", </del> <ins> sha256 = "27a13726ff8621cfa4592fbef116b253043c2b093c8814265dc4489a0e67d229", </ins> strip_prefix = "rules_go-82483596ec203eb9c1849937636f4cbed83733eb", urls = ["https://github.com/bazelbuild/rules_go/archive/82483596ec203eb9c1849937636f4cbed83733eb.tar.gz"], )

Discussion:
I don't see an existing issue, so opening one for tracking. PR builds are currently failing due to the SHA of a remote archive changing. ... $ sha256sum 27a13726ff8621cfa4592fbef116b253043c2b093c8814265dc4489a0e67d229 cc cc cc
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
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings: sig/release: Issue will be escalated to these SIGs if needed. priority/critical-urgent: Never automatically move out of a release milestone; continually escalate to contributor and SIG through all available channels. 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
cc
/assign We can probably just bump the sha, but I'm trying to figure out what changed...
I found a copy of the which matched the sha256sum (thanks There's no diff when I compare the extracted trees. There's also no diff if I compare the output on each. The new and old gzip'd tarballs are slightly different sizes (old bytes, new bytes). If I ungzip them, they are the same size ( bytes) but they still have different sha256sums. My best guess at this point is that there was some library change recently which is creating slightly different versions of these tarballs, but I don't know how it's different. I also don't know why the archive tarballs for other repos don't seem to have changed.
go 1.8 vs 1.9 gzip library maybe?
It seems like the order of some files in the tarball may have changed.
Yeah, we're not alone:
I guess we should start mirroring these archives somewhere rather than depending on GitHub.
Change:
if client.IsUnexpectedStatusError(err) { glog.FatalDepth(1, fmt.Sprintf("Unexpected status received from server: %s", err.Error())) } <del> glog.FatalDepth(1, fmt.Sprintf("Error: %s", err.Error())) </del> <ins> glog.FatalDepth(1, fmt.Sprintf("Client error: %s", err.Error())) </ins> } }

Discussion:
On a cluster running 0.13.2, I ran , picked out the name of a pod that only contains a single container, let's call it foo, and then ran . It prints nothing other than the message "Unexpected path for command running". If I add on the container name (), then it prints nothing, presumably because the pod has no logs. The docs for kubectl log say that the container name is optional if the pod only has one container, so I wouldn't expect this response.
+1, we're having to work around this on guides
Change:
defer cancel() vsi, err := vs.getVSphereInstance(nodeName) if err != nil { <ins> // If node doesn't exist, disk is already detached from node. if err == vclib.ErrNoVMFound { glog.Infof("Node %q does not exist, disk %s is already detached from node.", convertToString(nodeName), volPath) return nil } </ins> return err } // Ensure client is logged in and session is valid

Discussion:
/kind bug What happened: We had a pod with persistent storage. We drained the node. The node VM was deleted. The PV was not attached to the node that the Pod migrated too. The kube-controller-manager logs contained the following. What you expected to happen: The PV can be attached to the node it was migrated to. How to reproduce it (as minimally and precisely as possible): Create a 2 node cluster on vSphere Deploy a pod with persistent storage attached Drain the node Delete the node VM immediately after draining Anything else we need to know?: The issue seems to be in the call to getVSphereInstance. This will return an error if the Node doesn't exist. Precluding the logic on line 804-813 from being executed. A restart of the kube-controller-manager resolved the issue. The following e2e test is not triggered in vSphere environments - Which might expose the issue. Environment: Kubernetes version (use ): 1.9.5 Cloud provider or hardware configuration: vSphere OS (e.g. from /etc/os-release): ubuntu Kernel (e.g. ): Install tools: CFCR Others: /sig storage /sig vmware
More logs:
/assign
Change:
return nil, errors.New("must specify at least one ExtKeyUsage") } <ins> RemoveDuplicateAltNames(&cfg.AltNames) </ins> certTmpl := x509.Certificate{ Subject: pkix.Name{ CommonName:   cfg.CommonName,

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: Duplicate altnames in certs which generated by kubeadm ! What you expected to happen: No Duplicate altnames in certs which generated by kubeadm How to reproduce it (as minimally and precisely as possible): Anytime 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:
/sig cluster-lifecycle
/area kubeadm
Can you describe your detailed usage scenarios and reproduction steps, and explain the kubernetes version so that we can quickly locate
Thank for your response! I have found why and will fix it soon.
i have commented on the PR. /priority awaiting-more-evidence
/remove-priority awaiting-more-evidence /priority backlog
Change:
hdlr := NewExampleHandler(supportedVersions, false /* permitDeprecatedDir */) hdlr.AddPluginName(pluginName) <ins> c := make(chan struct{}) go func() { defer close(c) require.True(t, waitForEvent(t, exampleEventValidate, hdlr.EventChan(p.pluginName))) require.False(t, waitForPluginRegistrationStatus(t, p.registrationStatus)) }() </ins> w := newWatcherWithHandler(t, hdlr, false /* testDeprecatedDir */) defer func() { require.NoError(t, w.Stop()) }() <del> require.True(t, waitForEvent(t, exampleEventValidate, hdlr.EventChan(p.pluginName))) require.False(t, waitForPluginRegistrationStatus(t, p.registrationStatus)) </del> <ins> select { case <-c: return case <-time.After(wait.ForeverTestTimeout): t.Fatalf("Timeout while waiting for the plugin registration status") } </ins> } func waitForPluginRegistrationStatus(t *testing.T, statusChan chan registerapi.RegistrationStatus) bool {

Discussion:
What happened: A race condition in the plugin watcher might happen when a is created, started and immediately stopped and cleaned up. If executed several times, the unit test will expose this issue. The PR addressed part of the problem by serializing the handling of CREATE and DELETE events. However, a race might still happen in the function. describes in detail the problem. How to reproduce it (as minimally and precisely as possible): /sig storage /sig node
/assign
Change:
mu.Lock() for i := range *prioritizedList { host, score := (*prioritizedList)[i].Host, (*prioritizedList)[i].Score <ins> if glog.V(10) { glog.Infof("%v -> %v: %v, Score: (%d)", util.GetPodFullName(pod), host, ext.Name(), score) } </ins> combinedScores[host] += score * weight } mu.Unlock()

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : In pkg/scheduler/core/generic_scheduler# , add some debug info: each scheduler extender's score and its name for each pod, e.g. And we need add a function(e.g. ) in interface to get extender's name or similar identity. For , it might be enough to return its url . Why is this needed: If there are two or more scheduler extenders configured for scheduler(and we have now), it will be very useful to debug why kubelet nodes get so high/low score. <!-- DO NOT EDIT BELOW THIS LINE --/kind feature
/assign
Reiterating the mentions to trigger a notification: <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
Why don't you send a PR instead?
Thanks. PR is sent. PTAL.
Change:
return false, false, fmt.Errorf("context cancelled") case e := <-w.Events: switch e.Op { <del> case fsnotify.Write: </del> <ins> case fsnotify.Write, fsnotify.Rename, fsnotify.Remove, fsnotify.Chmod: </ins> return true, false, nil case fsnotify.Create: <del> fallthrough case fsnotify.Rename: fallthrough case fsnotify.Remove: fallthrough case fsnotify.Chmod: return true, true, nil </del> <ins> return true, filepath.Base(e.Name) == logName, nil </ins> default: klog.ErrorS(nil, "Received unexpected fsnotify event, retrying", "event", e) }

Discussion:
won't output logs after kubelet rotate log filer of the container. kubectl output logs correctly after the log file is rotated. the config to . So kubelet will rotate the log soon. Build a image with this program a deploy with the previous image. the command No response <details</details<detailsNone </details<details</details<details</details<details</details<details</details
/sig node
/area kubelet
/triage accepted /priority important-longterm
/assign since you sent a PR already
Ran into this issue!
Change:
// WalkFunc which is called for each file and directory in the pod cgroup dir visitor := func(path string, info os.FileInfo, err error) error { <ins> if err != nil { glog.V(4).Infof("cgroup manager encountered error scanning cgroup path %q: %v", path, err) return filepath.SkipDir } </ins> if !info.IsDir() { return nil } pids, err = getCgroupProcs(path) if err != nil { <del> glog.V(5).Infof("cgroup manager encountered error getting procs for cgroup path %v", path) </del> <ins> glog.V(4).Infof("cgroup manager encountered error getting procs for cgroup path %q: %v", path, err) </ins> return filepath.SkipDir } pidsToKill.Insert(pids...)

Discussion:
https://k8s- Failed: [] Downward API should provide default from node allocatable [Conformance] {E2eNode Suite}
this looks like the same issue fixed
For reference, this showed the following panic: which is fixed in referenced pr.
Change:
fuzz "github.com/google/gofuzz" runtimeserializer "k8s.io/apimachinery/pkg/runtime/serializer" "k8s.io/kubernetes/pkg/apis/batch" <ins> api "k8s.io/kubernetes/pkg/apis/core" </ins> "k8s.io/utils/pointer" )

Discussion:
pull-kubernetes-unit: TestRoundTripTypes Unknown No response No response /sig api-machinery
/kind bug /triage accepted
cc
cc I think fuzzing is missing a default for the newly type, so when fuzzing adds an entry, the original doesn't match the round-tripped data (which applies the API default)
/priority important-soon /remove-sig api-machinery /sig scheduling /assign
this will also need picking to release-1.25
/remove-sig scheduling /sig apps
/assign
/unassign
Change:
// ClearUDPConntrackForPeers uses the conntrack tool to delete the conntrack entries // for the UDP connections specified by the {origin, dest} IP pair. func ClearUDPConntrackForPeers(execer exec.Interface, origin, dest string) error { <del> parameters := parametersWithFamily(isIPv6(origin), "-D", "--orig-dst", origin, "--dst-nat", dest, "-p", "udp") </del> <ins> parameters := parametersWithFamily(IsIPv6String(origin), "-D", "--orig-dst", origin, "--dst-nat", dest, "-p", "udp") </ins> err := ExecConntrackTool(execer, parameters...) if err != nil && !strings.Contains(err.Error(), noConnectionToDelete) { // TODO: Better handling for deletion failure. When failure occur, stale udp connection may not get flushed.

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?: /kind bug What happened: There is a bug in ipv6, see: What you expected to happen: The judgement logic should be: 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: /sig network /area ipv6
/assign cc
Change:
}, ServiceNodePortRange: kubeoptions.DefaultServiceNodePortRange, } <del> s.ServiceClusterIPRanges = kubeoptions.DefaultServiceIPCIDR.String() </del> // Overwrite the default for storage data format. s.Etcd.DefaultStorageMediaType = "application/vnd.kubernetes.protobuf"

Discussion:
API server defaults the service CIDR. We should instead just fail if it is not specified. Defaulting is a wild guess and very likely to be wrong. /sig network /kind bug
For existing clusters that don't currently set it, is setting it to anything other than the current default a breaking change?
Yes. You can not really change it (well, you can expand it, but not totally move it), unless you delete ALL services, including kubernetes.default. I filed this aspirationally. It's not on fire, it's just a dumb thing to have provided a default for.
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved
Those labels are not set on the issue: <detailsIn response to : /remove-triage unresolved 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