jiebi/CodeConvo huggingface dataset:
Change:
framework.ExpectError(err, "created secret %q with empty key in namespace %q", secret.Name, f.Namespace.Name) }) <del> ginkgo.It("should patch a secret", func() { </del> <ins> /* Release : v1.18 Testname: Secret patching Description: A Secret is created. Listing all Secrets MUST return an empty list. Given the patching and fetching of the Secret, the fields MUST equal the new values. The Secret is deleted by it's static Label. Secrets are listed finally, the list MUST NOT include the originally created Secret. */ framework.ConformanceIt("should patch a secret", func() { </ins> ginkgo.By("creating a secret") secretTestName := "test-secret-" + string(uuid.NewUUID())

Discussion:
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 these query results from APIsnoop, we are lacking in tests for the follow endpoints related to Secrets. We chose the follow endpoints for this mock test. Test outline: a Secret in the default namespace with custom values Secrets in all namespaces search for Secret created in  the data in Secret  Secret  Secrets in all namespaces ensure that Secret  doesn't exist Discover useragents Display endpoints hit by the test Review the change in coverage If a test with these calls gets merged in, conformance will go up by 3 endpoints. /sig architecture /area conformance
/reopen
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
Yeah! We got a test written and a promotion (and we linked them to the mock-ticket that started it all). /close
Closing this issue. <detailsIn response to : Yeah! We got a test written and a promotion (and we linked them to the mock-ticket that started it all). /close 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:
// How long pods have to become scheduled onto nodes podScheduledBeforeTimeout = PodListTimeout + (20 * time.Second) <del> podRespondingTimeout     = 2 * time.Minute </del> <ins> podRespondingTimeout     = 15 * time.Minute </ins> ServiceRespondingTimeout = 2 * time.Minute EndpointRegisterTimeout  = time.Minute

Discussion:
https://k8s- Failed: [] Network Partition [Disruptive] [Slow] [] [ReplicationController] should recreate pods scheduled on the unreachable node AND allow scheduling of pods on a node after it rejoins the cluster {Kubernetes e2e suite}
Builds: ci-kubernetes-e2e-gci-gke-serial ci-kubernetes-e2e-gke-serial-release-1.5 ci-kubernetes-e2e-gke-serial Failed: [] Network Partition [Disruptive] [Slow] [] [ReplicationController] should recreate pods scheduled on the unreachable node AND allow scheduling of pods on a node after it rejoins the cluster {Kubernetes e2e suite}
Builds: ci-kubernetes-e2e-gci-gke-serial-release-1.5 ci-kubernetes-e2e-gke-containervm-1.4-gci-1.5-upgrade-cluster-new ci-kubernetes-e2e-gke-serial-release-1.5 Failed: [] Network Partition [Disruptive] [Slow] [] [ReplicationController] should recreate pods scheduled on the unreachable node AND allow scheduling of pods on a node after it rejoins the cluster {Kubernetes e2e suite}
this is currently assigned to you -- can you take a look? I guess it has not failed individually recently, only as part of large "broken test runs" so maybe we should close it? Please advise.
This has only failed once in the last couple of weeks in https://k8s- and zero times in https://k8s- so I think we should close it. WDYT?
Yes, fixed a regression in this recently. Closing this.
It seems like this test is still flaking a lot on GKE
should this block 1.6?
Re-opening until we've verified it's fixed. It seems to have just failed again
I think the serial tests haven't picked up the fix yet.
Tests are looking good, closing if I see another success.
We need to cherrypick the fix in into 1.6. I've filed a separate issue to track the hanging network calls on the GKE apiserver. /cc
I believe this was fast forwarded onto the branch by
-- can we take this off of the 1.6 release now? It seems to be a test setup issue
Yes, this is not a blocker anymore.

this can be removed from the 1.6 milestone
This Issue hasn't been active in 49 days. It will be closed in 40 days (Jun 14, 2017). cc You can add 'keep-open' label to prevent this from happening, or add a comment to keep it open another 90 days
Change:
] + select({ "@io_bazel_rules_go//go/platform:linux": [ "//vendor/github.com/vishvananda/netlink:go_default_library", <ins> "//vendor/golang.org/x/sys/unix:go_default_library", </ins> ], "//conditions:default": [], }),

Discussion:
https://k8s- https://k8s- cc: /priority failing-test
Sorry, but I will fix it ASAP.
/assign
PR is already sent. Wating for CI report...
Change:
var _ pflag.Value = &StringSlice{} func (s *StringSlice) String() string { <ins> if s == nil || s.value == nil { return "" } </ins> return strings.Join(*s.value, " ") } func (s *StringSlice) Set(val string) error { if s.value == nil || !s.changed { <del> *s.value = make([]string, 0) </del> <ins> v := make([]string, 0) s.value = &v </ins> } *s.value = append(*s.value, val) s.changed = true

Discussion:
I ran and it panicked: no panic The panic was introduced by . I submitted as an attempt to fix this, but review led to the realization that there were further bugs and I don't know what the right fix is cc
/assign
/sig testing /sig cloud-provider
/triage accepted
Change:
// get the init containers in reverse order ic := pod.Spec.InitContainers[len(pod.Spec.InitContainers)-i-1] <del> to.terminated[ic.Name] = make(chan struct{}) </del> <ins> channel := make(chan struct{}) to.terminated[ic.Name] = channel // if it's not a running container, pre-close the channel so nothing // waits on it if _, isRunning := runningContainers[ic.Name]; !isRunning { close(channel) } </ins> if types.IsRestartableInitContainer(&ic) { // sidecars need to wait for all main containers to exit

Discussion:
In a situation where during the init phase of a , a native sidecar never becomes ready (because its is failing), then the is terminated, if there are multiple startup containers, a termination signal is never received by the init container and the Pod is stuck (until is hit). All running initContainer to receive the termination signal correctly. Create a with this bash script as an entrypoint: Create a deployment with two init containers (one normal one sidecar). Add an probe which means the startupProbe never passes Create the deployment, and it'll be stuck in Init, as you'd expect: the pod and you'll see the exit signal has been sent to : Delete the deployment / clean everything up. Now, add a third : As before, the process will be stuck on because of the bad probe: However when you delete the pod this time, no exit signal is sent to , the pod is now stuck until is reached. No response GKE v1.29.4-gke. Core OS on GCP <details</details<details</details<details</details
/sig node
/assign
/triage accepted confirmed that the scenario is reproduced. The problem is caused by the fact that the native sidecars should terminate in reverse order. I'll fix the code to ignore not-running init containers. /cc
Awesome, thank you :)
sig-node meeting notes: /triage accepted /priority important-soon
FYI: confirmed that the SITERM is sent to the containers after terminationGracePeriodSeconds (and wait for the application for 2 seconds before sending SIGKILL) will fix it anyway with
Change:
return } <del> baseNamespaceObj, exist, err := nc.namespaceInformerStore.GetByKey(namespace) </del> <ins> namespaceObjFromStore, exist, err := nc.namespaceInformerStore.GetByKey(namespace) </ins> if err != nil { glog.Errorf("Failed to query main namespace store for %v: %v", namespace, err) nc.deliverNamespace(namespace, 0, true)

Discussion:
Unit tests on PR are failing due to data race in federation-controller/namespace unittest. More logs: https://k8s-
CC
Sent to fix this
Change:
} else { for _, addr := range localAddrs { if ipnet, ok := addr.(*net.IPNet); ok { <del> if ipnet.IP.To4() != nil { </del> <ins> if !ipnet.IP.IsLinkLocalUnicast() { </ins> // Filter external IP by MAC address OUIs from vCenter and from ESX vmMACAddr := strings.ToLower(i.HardwareAddr.String()) // Making sure that the MAC address is long enough

Discussion:
What happened: IP addresses losing in k8s node status in a pure ipv6 vsphere environment. all interfaces of nodes in this cluster are ipv6 only The error logs in kubelet as the following: What you expected to happen: It will be very appreciated if we can get ipv6 addresses from vsphere cloud provider as ipv4 env How to reproduce it (as minimally and precisely as possible): deploy k8s cluster in vsphere pure ipv6 envirenment Anything else we need to know?: From the code we can know that while the provider retrieves VM’s IP, It uses To4() function for all ip addresses from vsphere platform, this function can’t handle ipv6 addresses as mentioned in guild: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: vsphere OS (e.g: ):Kernel (e.g. ):Install tools: ansible Network plugin and version (if this is a network-related bug): calico v3.5.6 Others:
If you agree with this I can fix it.
Reiterating the mentions to trigger a notification: <detailsIn response to : 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
/sig cloud-provider
cc /remove-sig contributor-experience
/cc
please help to review, I think I can fix the issue by PR /sig cloud-provider Thanks a lot
/assign
Change:
"k8s.io/apimachinery/pkg/labels" "k8s.io/apimachinery/pkg/runtime" "k8s.io/apimachinery/pkg/util/sets" <ins> "k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm" </ins> "k8s.io/kubernetes/federation/apis/federation" "k8s.io/kubernetes/pkg/api" "k8s.io/kubernetes/pkg/api/events"

Discussion:
used to show masters, but as of it no longer does. This is not in accordance with our deprecation policy I believe. cc
That commit/PR is not relevant as there are no supported users/deployment methods that are using label. kubeadm v1.4 or v1.5 was the last. What you're really looking for is who/what removed printing things based on the label...
No blame on you The regression is that we have stopped printing masters in . There may be more to it that a simple revert of , but we should probably start there.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
This has been fixed in recent versions
Change:
Containers: []v1.Container{ { Image:   busyboxImage, <del> Name:    logContName, Command: []string{"sh", "-c", "echo " + logString}, </del> <ins> Name:    logContainerName, Command: []string{"sh", "-c", "echo " + log}, </ins> }, }, }, } <ins> } </ins> <del> podClient.Create(logPod) err := framework.WaitForPodSuccessInNamespace(f.ClientSet, logPodName, ns) framework.ExpectNoError(err, "Failed waiting for pod: %s to enter success state", logPodName) // get containerID from created Pod createdLogPod, err := podClient.Get(logPodName, metav1.GetOptions{}) logConID := kubecontainer.ParseContainerID(createdLogPod.Status.ContainerStatuses[0].ContainerID) framework.ExpectNoError(err, "Failed to get pod: %s", logPodName) expectedlogFile := logDir + "/" + logPodName + "_" + ns + "_" + logContName + "-" + logConID.ID + ".log" </del> <ins> makeLogCheckPod := func(podName, log, expectedLogPath string) *v1.Pod { </ins> hostPathType := new(v1.HostPathType) *hostPathType = v1.HostPathType(string(v1.HostPathFileOrCreate)) <del> checkPod := &v1.Pod{ </del> <ins> return &v1.Pod{ </ins> ObjectMeta: metav1.ObjectMeta{ <del> Name: checkPodName, </del> <ins> Name: podName, </ins> }, Spec: v1.PodSpec{ // this pod is expected to exit successfully

Discussion:
The should be updated to check CRI log paths.
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
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
May I try to help with this?
GitHub didn't allow me to assign the following users: fatsheep9146. Note that only and repo collaborators can be assigned. For more information please see <detailsIn response to : /assign Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Change:
<ins> apiVersion: apps/v1 kind: Deployment metadata: name: test spec: replicas: 3 selector: matchLabels: name: test template: metadata: labels: name: test spec: containers: - name: nginx image: nginx </ins>

Discussion:
What happened: I get a diff, when I specify a file directly, but on recursive mode, no diff is shown anymore: What you expected to happen: Recursive mode should work How to reproduce it (as minimally and precisely as possible): Have a bunch of YAML manifest, but with name collisions, e.g. Service , Deployment , etc Anything else we need to know?: I think the problem is that all objects have the same name, which should not be a problem per se. Only heapster-binding has a different name, and looking at the generated temp files, only and are present: Environment: Kubernetes version (use ): $ kubectl version --short Client Version: v1.13.0 Server Version: v1.13.0 <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/sig cli
I think the files are overwriting each other?
Yeah, good catch, I'll try to fix that asap
Thanks! By the way, very nice work with dry-run and diff. I was waiting for this.
Feel free to look at the PR and give your opinion!
Change:
"//pkg/kubelet/container:go_default_library", "//pkg/kubelet/events:go_default_library", "//pkg/kubelet/images:go_default_library", <ins> "//pkg/kubelet/kuberuntime/logs:go_default_library", </ins> "//pkg/kubelet/lifecycle:go_default_library", "//pkg/kubelet/metrics:go_default_library", "//pkg/kubelet/prober/results:go_default_library",

Discussion:
We should make the CRI log parsing code in kubelet to be a library. So that container runtimes and external tools don't need to copy the whole code ( vendor it instead ). Referring
/assign
/sig node
I can help on it.
/assign
GitHub didn't allow me to assign the following users: yanxuean. Note that only can be assigned. <detailsIn response to : /assign Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Thanks. I have a branch ready for this. Will open a PR later and ping you when it is out.
ok
Change:
DialTimeout:          dialTimeout, DialKeepAliveTime:    keepaliveTime, DialKeepAliveTimeout: keepaliveTimeout, <del> Endpoints:            c.ServerList, TLS:                  tlsConfig, </del> <ins> DialOptions: []grpc.DialOption{ grpc.WithUnaryInterceptor(grpcprom.UnaryClientInterceptor), grpc.WithStreamInterceptor(grpcprom.StreamClientInterceptor), }, Endpoints: c.ServerList, TLS:       tlsConfig, </ins> } client, err := clientv3.New(cfg) return client, err

Discussion:
/kind feature Can we provide a way to enable etcd clientv3 prometheus metrics at the apiserver side ? The etcd.clientv3 interface is instantiated and it does not enable metrics. In file in coreos/etcd, one can see the to pass to enable metrics. It would be great if the apiserver has a command line parameter, config/environment variable to enable etcd.clientv3 metrics.
Reiterating the mentions to trigger a notification: <detailsIn response to : 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 quite similar to
Yes, this is a good idea, in fact we just released a new version of the package required for this.
/assign
I can do it.
oh, maybe I should use the new features to implement, I will continue to modify it.
are you referring to injecting the registry to use? Yes I would very much appreciate that, even if we (for now) inject the , that will allow us to modify that more easily in the future.
Change:
visibility = ["//visibility:public"], deps = [ "//pkg/scheduler/algorithm/predicates:go_default_library", <del> "//pkg/scheduler/algorithm/priorities:go_default_library", </del> "//pkg/scheduler/framework/plugins/migration:go_default_library", "//pkg/scheduler/framework/v1alpha1:go_default_library", "//pkg/scheduler/listers:go_default_library",

Discussion:
/sig scheduling /priority important-soon See as an example. /assign
/unassign /help
/assign
/remove-help
Change:
resourceinformers "k8s.io/client-go/informers/resource/v1alpha2" "k8s.io/client-go/kubernetes" "k8s.io/client-go/tools/cache" <ins> "k8s.io/client-go/util/flowcontrol" </ins> "k8s.io/client-go/util/workqueue" "k8s.io/klog/v2" drapb "k8s.io/kubelet/pkg/apis/dra/v1alpha3"

Discussion:
has to retry after failures. This currently uses a fixed 5 second delay to avoid busy-looping. Exponential backoff might be better. /sig node /triage-accepted /priority important-longterm /lifecycle frozen /assign
/triage accepted
/assign
Change:
PROXY_PORT=$(kube::util::get_random_port) kube::log::status "On try ${retry}, use proxy port ${PROXY_PORT} if it's free" if kube::util::test_host_port_free "127.0.0.1" "${PROXY_PORT}"; then <del> # the --www and --www-prefix are just to make something definitely show up for # wait_for_url to see. kubectl proxy -p ${PROXY_PORT} --www=. --www-prefix=/healthz "$@" 1>&2 & break </del> <ins> if [ $# -eq 0 ]; then kubectl proxy -p ${PROXY_PORT} --www=. 1>&2 & break else kubectl proxy -p ${PROXY_PORT} --www=. --api-prefix="$1" 1>&2 & break fi </ins> fi sleep 1; done PROXY_PID=$! <del> kube::util::wait_for_url "http://127.0.0.1:${PROXY_PORT}/healthz" "kubectl proxy $@" </del> <ins> if [ $# -eq 0 ]; then kube::util::wait_for_url "http://127.0.0.1:${PROXY_PORT}/healthz" "kubectl proxy" else kube::util::wait_for_url "http://127.0.0.1:${PROXY_PORT}/$1/healthz" "kubectl proxy --api-prefix=$1" fi </ins> } function cleanup()

Discussion:
Now that we've moved the experimental api to /apis/experimental... it's inaccessible from by default. We should fix that. who stepped on this earlier
security questions for you: this prefix was apparently in response to a security review quite some time ago. I don't understand how this adds much security. Can we just remove it? If not, is it acceptable to change the default from "/api/" to "/api", which would match both api locations? Otherwise we'll have to take a comma-separated list or something...
Ref
Oh, so this is not related to the security requests! And the original use case was just to re-root the URL path so it didn't interfere with static content. Sorry, I got confused because the last time I monkeyed with that, it was in conjunction with the allow/deny list that actually was the security request. In that case, let's see if we can change the default to "/", if that will break anything.
That change got introduced as part of to protect against XSRF in kubectl proxy. But I think the more important part of that change was that it disallows POST/PUT/PATCH by default. So as long as there is no state changing action outside of /api/ that can be triggered with a GET it should be safe to remove.
Change:
fmt.Fprintf(out, "      %s:t%sn", name, quantity.String()) } <del> switch { case state.Running != nil: fmt.Fprintf(out, "    State:tRunningn") fmt.Fprintf(out, "      Started:t%vn", state.Running.StartedAt.Time.Format(time.RFC1123Z)) case state.Waiting != nil: fmt.Fprintf(out, "    State:tWaitingn") if state.Waiting.Reason != "" { fmt.Fprintf(out, "      Reason:t%sn", state.Waiting.Reason) } case state.Terminated != nil: fmt.Fprintf(out, "    State:tTerminatedn") if state.Terminated.Reason != "" { fmt.Fprintf(out, "      Reason:t%sn", state.Terminated.Reason) } if state.Terminated.Message != "" { fmt.Fprintf(out, "      Message:t%sn", state.Terminated.Message) } fmt.Fprintf(out, "      Exit Code:t%dn", state.Terminated.ExitCode) if state.Terminated.Signal > 0 { fmt.Fprintf(out, "      Signal:t%dn", state.Terminated.Signal) } fmt.Fprintf(out, "      Started:t%sn", state.Terminated.StartedAt.Time.Format(time.RFC1123Z)) fmt.Fprintf(out, "      Finished:t%sn", state.Terminated.FinishedAt.Time.Format(time.RFC1123Z)) default: fmt.Fprintf(out, "    State:tWaitingn") </del> <ins> describeStatus("State", state, out) if status.LastTerminationState.Terminated != nil { describeStatus("Last Termination State", status.LastTerminationState, out) </ins> } fmt.Fprintf(out, "    Ready:t%vn", printBool(status.Ready)) fmt.Fprintf(out, "    Restart Count:t%dn", status.RestartCount) fmt.Fprintf(out, "    Variables:n")

Discussion:
Problem When a container is killed and restarted because, for example, it hit memory limits, the output only shows an increasing but no reason for why the container was killed: We can find the reason by inspecting the pod object ( shows as with ): Suggested Solution Modify to print termination reason, if available.
When this merges, need to update Search for in that doc.
Solved with .
Change:
"github.com/emicklei/go-restful/swagger" "k8s.io/kubernetes/pkg/api/meta" <ins> apiutil "k8s.io/kubernetes/pkg/api/util" </ins> client "k8s.io/kubernetes/pkg/client/unversioned" )

Discussion:
It would be nice if let me explain experimental resources to aid users ability to experiment.
It's possible this works today, but it was non-obvious how to use. Attempts:
cc
cc
No, this isn't supported, since current implementation only use v1 Client but not experimental Client.
do we need to fix this for 1.1?
How difficult do you think it would be to fix?
It has dependency on ServerAPIVersions(), for which we plan to make a clean-up PR. I guess it needs 3-4 days to get two PRs merged.
With , this can be fixed now. What's the expected behavior of ? I assume in case of , it should search hpa in both v1 and extensions/v1bata1, and determines hpa as a resource in the extensions group? BTW, the use of "api-version" flag is problematic It adds extra meaning to the generic "api-version" flag.