jiebi/CodeConvo huggingface dataset:
Change:
"WatchEvent", ) <ins> var commonKinds = []string{"ListOptions", "DeleteOptions"} // verify all external group/versions have the common kinds like the ListOptions, DeleteOptions are registered. func TestCommonKindsRegistered(t *testing.T) { for _, kind := range commonKinds { for _, group := range testapi.Groups { gv := group.GroupVersion() if _, err := api.Scheme.New(gv.WithKind(kind)); err != nil { t.Error(err) } } } } </ins> var nonInternalRoundTrippableTypes = sets.NewString("List", "ListOptions", "ExportOptions") var nonRoundTrippableTypesByVersion = map[string][]string{}

Discussion:
It seems to me like all of the garbage collection integration tests produce a ton of log messages of the form:
Change:
if err != nil { return nil, err } <del> // TODO: search by UID if it's set fields := labels.Set{ "involvedObject.kind":      ref.Kind, "involvedObject.namespace": ref.Namespace, "involvedObject.name":      ref.Name, }.AsSelector() </del> if e.namespace != "" && ref.Namespace != e.namespace { return nil, fmt.Errorf("won't be able to find any events of namespace '%v' in namespace '%v'", ref.Namespace, e.namespace) } <del> return e.List(labels.Everything(), fields) </del> <ins> fields := labels.Set{} if ref.Kind != "" { fields["involvedObject.kind"] = ref.Kind } if ref.Namespace != "" { fields["involvedObject.namespace"] = ref.Namespace } if ref.Name != "" { fields["involvedObject.name"] = ref.Name } if ref.UID != "" { fields["involvedObject.uid"] = ref.UID } return e.List(labels.Everything(), fields.AsSelector()) </ins> }

Discussion:
We introduced UID / UUID to provide time-based uniqueness, but UID / UUID are not user friendly. We are going to have this kind of issues in general at client side.
Yeah, describe does a "get" first, so it has the UID available.
Pretty sure this is a feature until we have a way to lookup dead pods. On Nov 21, 2014 2:47 PM, "Daniel Smith" wrote:
Change:
done } <del> # Given a yaml file, add or mutate the given env variable </del> <ins> # Quote something appropriate for a yaml string. </ins> # <del> # TODO(zmerlynn): Yes, this is an O(n^2) build-up right now. If we end # up with so many environment variables feeding into Salt that this # matters, there's probably an issue... function add-to-env { ${KUBE_ROOT}/cluster/gce/kube-env.py "$1" "$2" "$3" </del> <ins> # TODO(zmerlynn): Note that this function doesn't so much "quote" as # "strip out quotes", and we really should be using a YAML library for # this, but PyYAML isn't shipped by default, and *rant rant rant ... SIGH* function yaml-quote { echo "'$(echo "${@}" | sed -e "s/'/''/g")'" </ins> } # $1: if 'true', we're building a master yaml, else a node

Discussion:
I tried to spin up GCE kube environment using kube-up and got the following error: The script would then hang on a subsequent command. The verify-prereqs for kube-up should require yaml support for python and fail early. To rectify, I had to do the following:
Thanks for the report Derek!
Yeah, this broke our Jenkins a while ago, and I thought I fixed it, but didn't. The real fix is in
Change:
errOut:          errOut, }.IsConditionMet, nil <del> case strings.HasPrefix(lowercaseCond, "jsonpath="): jsonPathInput := strings.TrimPrefix(lowercaseCond, "jsonpath=") </del> <ins> case strings.HasPrefix(condition, "jsonpath="): jsonPathInput := strings.TrimPrefix(condition, "jsonpath=") </ins> jsonPathExp, jsonPathValue, err := processJSONPathInput(jsonPathInput) if err != nil { return nil, err

Discussion:
In v1.31.0-rc.1 commands hang, see relevant thread for details. Second command should work, as it does with kubectl v1.30.3 Reproducer against a 1.30.3 server: No response <details</details<details</details<details</details<details</details<details</details<details</details
cc
looks like a regression introduced in /assign
thanks so much for the very detailed and timely report, great to catch this before the .0 release
Change:
framework.ExpectEqual(foundSvc, true, "could not find service 'kubernetes' in service list in all namespaces") }) <del> ginkgo.It("should test the lifecycle of an Endpoint", func() { </del> <ins> /* Release : v1.19 Testname: Endpoint resource lifecycle Description: Create an endpoint, the endpoint MUST exist. The endpoint is updated with a new label, a check after the update MUST find the changes. The endpoint is then patched with a new IPv4 address and port, a check after the patch MUST the changes. The endpoint is deleted by it's label, a watch listens for the deleted watch event. */ framework.ConformanceIt("should test the lifecycle of an Endpoint", func() { </ins> testNamespaceName := f.Namespace.Name testEndpointName := "testservice" testEndpoints := v1.Endpoints{

Discussion:
[x] Original approval issue: [x] Two weeks soak end date: This issue is created to allow edit by /wip /hold This issue proposes the writing of a new test for the API endponts , , , with the intention of promoting it to Conformance. This issue contains a very basic mock test in order to start the conversation about what a good e2e test would look like for this endpoint. The code below is verified to be hitting the intended endpoint, show as per the queries in APIsnoop's live view of the cluster's audit logs. According to this APIsnoop query, there are still some remaining Endpoints endpoints which are untested. a Service in a namespace all Endpoints in all Namespaces find the created Service(1) /update the Namespaced Endpoint for the Service(1) the Namespaced Endpoint for the Service(1) the Namespaced Endpoint for the Service(1) Namespaced Endpoint(1) via a Collection with a LabelSelector Discover useragents: If a test with these calls gets merged, Conformance coverage will go up by 4 points* /sig testing /sig architecture /area conformance
/reopen Wait for Promotion PR to Merge.
Reopened this issue. <detailsIn response to : /reopen Wait for Promotion PR to Merge. 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:
// We omit vowels from the set of available characters to reduce the chances // of "bad words" being formed. <del> var alphanums = []rune("bcdfghjklmnpqrstvwxz0123456789") </del> <ins> var alphanums = []rune("bcdfghjklmnpqrstvwxz2456789") </ins> // String generates a random alphanumeric string, without vowels, which is n // characters long.  This will panic if n is less than zero.

Discussion:
/kind feature What happened: In playing with the nginx ingress controller deployment, I noticed the following pod name: nginx-ingress-controller--c0ck5 I figure we should possibly put something in place to prevent accidental l33t profanity ;-). What you expected to happen: The following pod name: nginx-ingress-controller--r0ck5
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
My first github (k8s) issue. I've no idea which SIG would cover this topic. /sig product-management
/sig api-machinery
Previously we removed vowels in . We can 3xt3nd the idea with 0, 1 (can stand for ) and 3. would you like to send a PR? If not, I can work on this.
/assign jamesawebb1
Reassign to me if you do not want to contribute a PR.
Change:
// Delete a ReplicaSet and all pods it spawned func DeleteReplicaSet(clientset clientset.Interface, internalClientset internalclientset.Interface, ns, name string) error { By(fmt.Sprintf("deleting ReplicaSet %s in namespace %s", name, ns)) <del> rc, err := clientset.Extensions().ReplicaSets(ns).Get(name, metav1.GetOptions{}) if err != nil { if apierrs.IsNotFound(err) { Logf("ReplicaSet %s was already deleted: %v", name, err) return nil } return err } reaper, err := kubectl.ReaperFor(extensionsinternal.Kind("ReplicaSet"), internalClientset) </del> <ins> rs, err := clientset.Extensions().ReplicaSets(ns).Get(name, metav1.GetOptions{}) </ins> if err != nil { if apierrs.IsNotFound(err) { Logf("ReplicaSet %s was already deleted: %v", name, err)

Discussion:
As the title said, we need update touse server side reaper. xref:
/sig apps
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
/assign
Change:
Nameservers: []string{testInjectedIP}, Searches:    []string{testSearchPath}, } <ins> testUtilsPod.Spec.NodeSelector = map[string]string{ "kubernetes.io/os": "windows", } </ins> testUtilsPod, err := f.ClientSet.CoreV1().Pods(f.Namespace.Name).Create(context.TODO(), testUtilsPod, metav1.CreateOptions{}) framework.ExpectNoError(err) framework.Logf("Created pod %v", testUtilsPod)

Discussion:
What happened: Some of our windows tests (in this case ) dont add enough scheduling metadata to behave predictably in environments where, for example, is required to interpret a pods proper location. A "bug" in EKS CNI actually causes EKS, for example, to not properly label such pods with IP addresses (because it uses an adm controller to add metadata before a pod is created, and that md is sent to eks's cni). In any case adding this metadata is a standard in Sig-windows, per conv with yesterday, so we'll want to add these in. As an example of the test failure which results when you dont have this selector.... Looking at the pod Spec: 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: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
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 windows
Change:
"fmt" "math" "strconv" <del> "sync" </del> "time" "github.com/GoogleCloudPlatform/kubernetes/pkg/api"

Discussion:
The issue is to follow up discussions in : running conformance test with the commonly used tool, sonobuoy, failed because the tool's test runner is lack of permission towards . The original issue was resolved by changing the e2e (conformance) test of to an integration test. Several problems remained: privilege requirement in is outdated. discovery is one of the least-privileged permissions, and is expected to be granted to every authenticated user but is not actually. the result returned by should be part of conformance? 1st and 2nd are straightforward to fix, not sure about 3rd, should we add a separate test or add a verification step in existing one like With the fix of 2nd, e2e for should no longer fail with any test runner. cc - should be reflect the accurate permission requirement discovery permission should be granted to all authenticated users. test should check the result returned by . Inapplicable No response <details</details<details</details<details</details<details</details<details</details<details</details
/sig api-machinery /sig testing
I agree with this. We have conformance tests around things like webhooks and custom resource definitions. I'd recommend rephrasing that as "limits itself to capabilities exposed via APIs (e.g., does not require root on nodes, access to raw network interfaces) and does not require write access to system namespaces (like kube-system)" I'm not sure I agree with this. No binaries Kubernetes provides (that I'm aware of) and nothing in client-go needs to make use of root discovery information. I'd be very slow to expand endpoints included in . Unless we have compelling reasons for people to use and rely on this data, I would lean towards no.
can we fix 1 , that seems that everybody agree and looks like the most clear one? the other sound more contentious
thanks for your comments. Created for 1 and closed the other one.
Thanks all. Agree on this outcome.
/triage accepted
Change:
} // remaining node conditions should also be set to Unknown <del> remainingNodeConditionTypes := []v1.NodeConditionType{v1.NodeOutOfDisk, v1.NodeMemoryPressure, v1.NodeDiskPressure} </del> <ins> remainingNodeConditionTypes := []v1.NodeConditionType{ v1.NodeOutOfDisk, v1.NodeMemoryPressure, v1.NodeDiskPressure, // We don't change 'NodeInodePressure' condition, as it'll be removed in future. // v1.NodeInodePressure, // We don't change 'NodeNetworkUnavailable' condition, as it's managed on a control plane level. // v1.NodeNetworkUnavailable, } </ins> nowTimestamp := nc.now() for _, nodeConditionType := range remainingNodeConditionTypes { _, currentCondition := nodeutil.GetNodeCondition(&node.Status, nodeConditionType)

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: If node is unreachable, NodeController only set , , to unknown; it's better to also set NetworkUnavailable & InodePressure to unknown.
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 node
Isn't a known condition if node is unreachable?
is the status of container, e.g. CNI is not ready. If node is unreachable, it should be Unknown.
Thanks for explanation!
will not set NetworkUnavailable & InodePressure to unknown, refer to .
Change:
if numCpus < 1 { e2eskipper.Skipf("insufficient CPU available for kubelet restart test") } <ins> if numCpus > 18 { // 950m * 19 = 1805 CPUs -> not enough to block the scheduling of another 950m pod e2eskipper.Skipf("test will return false positives on a machine with >18 cores") } </ins> // create as many restartNever pods as there are allocatable CPU // nodes; if they are not correctly accounted for as terminated

Discussion:
node-kubelet-serial Kubelet should correctly account for terminated pods after restart Since test was created, flakes 10-20% of the time. Not entirely clear why, I haven't looked. No response /assign /sig node
Introduced by , maybe we should use to replace See the log below, a pod becomes Succeed may exhaust tens of seconds
/triage accepted
Yeah I only tested this locally and not in CI, it seems that in CI the pods take much longer. Timings just need to be tweaked.
/reopen still a number of flakes since the attached PR merged, I don't think that fixed it.
Reopened this issue. <detailsIn response to : /reopen 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
from this link, I see all suites passed, which flakes do you mean?
I see this failure in
so this problem should have been fixed by
From gubernator: In all cases, it's timing out. I'll try upping the startTimeout.
/reopen still flaking
Reopened this issue. <detailsIn response to : /reopen 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
Luckily the kubelet log is clear as to what's going on. From (flake ) The test should work fine if we drop the CPU request a bit, let me tweak it to make up for the possible extra 100m scheduled. I'm not sure what's causing that (aren't these tests serial? what the heck is getting scheduled) but we should be resilient to it. Also, needs to be fixed. This test will no longer detect the regression it was designed to show after that change. I will revert it and also fix the resource requirements and that should fix this test.
/milestone v1.23 need to fix this before test freeze
Change:
return nil } <del> _, err = cs.CoreV1().Pods(old.Namespace).Patch(ctx, old.Name, types.StrategicMergePatchType, patchBytes, metav1.PatchOptions{}, "status") return err </del> <ins> patchFn := func() error { _, err := cs.CoreV1().Pods(old.Namespace).Patch(ctx, old.Name, types.StrategicMergePatchType, patchBytes, metav1.PatchOptions{}, "status") return err } return retry.OnError(retry.DefaultBackoff, net.IsConnectionRefused, patchFn) </ins> } // DeletePod deletes the given <pod> from API server

Discussion:
If there is a connection failure when updating the Pod status, we don't retry. Furthermore, due to , we won't have another chance until much later. The problem is that if we don't mark the Pod as Unschedulable, other controllers (such as cluster-autoscaler) wouldn't react to these pods. We should have stronger guarantees to mark a Pod as Unschedulable. You need an unschedulable Pod (for example, a Pod with a non matching node affinity) and a flaky connection to apiserver. No response master This is particularly problematic in 1.24, due to . Any <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
/sig scheduling
That is bad, retrying in place on transient errors should probably be ok.
I'll address it. /assign
Thanks!
Change:
glog.Infof("eviction manager: pods ranked for eviction: %s", format.Pods(activePods)) <ins> //record age of metrics for met thresholds that we are using for evictions. for _, t := range thresholds { timeObserved := observations[t.Signal].time if !timeObserved.IsZero() { metrics.EvictionStatsAge.WithLabelValues(string(t.Signal)).Observe(metrics.SinceInMicroseconds(timeObserved.Time)) } } </ins> // we kill at most a single pod during each eviction interval for i := range activePods { pod := activePods[i]

Discussion:
We should keep track of how stale stats used for evictions are. This will help track improvements in eviction latency, and help uncover regressions. cc If someone could assign this to me, I would appreciate that.
closing via
Change:
t.Fatalf("failure to update version of object (%d) %#v", bookmark.ResourceVersion, bookmark.Object) } <ins> wg := sync.WaitGroup{} wg.Add(2) </ins> go func() { cacher.dispatchEvent(bookmark) <ins> wg.Done() </ins> }() go func() { w.Stop() <ins> wg.Done() </ins> }() done := make(chan struct{})

Discussion:
cc ref
There are no sig labels on this issue. Please add a sig label by either: 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. See the . The in method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals. <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
- can you please take a look, you introduced this test and it may mean real problem with your code
I took a quick look and this is a test issue. The problem is that the implementation explicitly assumes there is at most one call to dispatchEvent at a given time. And this particular test breaks this assumption: The problem is that, a given iteration is finished when is closed, which may actually happen as a result of even before is called (since it's a different goroutine). And then may be called concurrently with the next iteration, which triggers a race. The fix is simple, we should ensure that all goroutines are finished before starting the next iteration.
/cc
Change:
expectedErr string }{ { <ins> name: "empty", obj: &corev1.PodList{ Items: []corev1.Pod{}, }, sort: &corev1.PodList{ Items: []corev1.Pod{}, }, field: "{.metadata.name}", }, { </ins> name: "in-order-already", obj: &corev1.PodList{ Items: []corev1.Pod{

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!--What happened: seems to have regressed in v1.13.0 and no longer sorts by creation timestamp. What you expected to happen: should sort by creation timestamp. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: N/A Environment: Kubernetes version (use ): <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/sig cli
/assign
bisected to () /assign
opened to fix
/assign
Change:
} } <del> if proxier.network.networkType == "Overlay" { </del> <ins> // For Overlay networks 'SourceVIP' on an Load balancer Policy can either be chosen as // a) Source VIP configured on kube-proxy (or) // b) Node IP of the current node // // For L2Bridge network the Source VIP is always the NodeIP of the current node and the same // would be configured on kube-proxy as SourceVIP // // The logic for choosing the SourceVIP in Overlay networks is based on the backend endpoints: // a) Endpoints are any IP's outside the cluster ==> Choose NodeIP as the SourceVIP // b) Endpoints are IP addresses of a remote node => Choose NodeIP as the SourceVIP // c) Everything else (Local POD's, Remote POD's, Node IP of current node) ==> Choose the configured SourceVIP if proxier.network.networkType == "Overlay" && !ep.GetIsLocal() { </ins> providerAddress := proxier.network.findRemoteSubnetProviderAddress(ep.IP()) isNodeIP := (ep.IP() == providerAddress)

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: Trying to connect to Service VIP from a POD is failing intermittently in Overlay network mode What you expected to happen: Frontend should be able to connect to Service VIP always. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: With a configuration like this: Node 1 has these POD's POD1 POD2 POD3 Node 2 has these POD's POD4 POD5 POD6 Service1 has these pod's as backend - POD1,POD2,POD5,POD6 Curl to Service1 from POD3 would fail if POD5 or POD6 is chosen for the connection Curl to Service1 from POD3 would pass if POD1 or POD2 is chosen for the connection 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:
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 network /sig windows