jiebi/CodeConvo huggingface dataset:
Change:
"//vendor/k8s.io/apimachinery/pkg/util/json:go_default_library", "//vendor/k8s.io/apimachinery/pkg/util/jsonmergepatch:go_default_library", "//vendor/k8s.io/apimachinery/pkg/util/mergepatch:go_default_library", <ins> "//vendor/k8s.io/apimachinery/pkg/util/net:go_default_library", </ins> "//vendor/k8s.io/apimachinery/pkg/util/sets:go_default_library", "//vendor/k8s.io/apimachinery/pkg/util/strategicpatch:go_default_library", "//vendor/k8s.io/apimachinery/pkg/util/validation:go_default_library",

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: kubectl cluster-info displays proxy urls for cluster services If those services are using https, the referenced urls do not work (they try to proxy using http) What you expected to happen: Services with a port name of https or 443 should use the ‘https:<name:<port‘ form 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: /assign /sig cli
Change:
Containers: []v1.Container{ { Name:  podName, <del> Image: imageutils.GetPauseImageName(), </del> <ins> Image: imageutils.GetE2EImage(imageutils.BusyBox), Command: []string{ "powershell.exe", "-Command", "sleep -Seconds 600", }, </ins> }, }, SecurityContext: &v1.PodSecurityContext{

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI -- [sig-windows] [Feature:Windows] GMSA Kubelet [Slow] kubelet GMSA support when creating a pod with correct GMSA credential specs passes the credential specs down to the Pod's containers [sig-windows] [Feature:Windows] GMSA Full [Serial] [Slow] GMSA support works end to end ** pause image using in image was transitioned to the official pause image which no longer has in the image related to /sig windows /triage accepted
Change:
// Optional: If unspecified, the first port on the container will be used. ContainerPort util.IntOrString `json:"containerPort,omitempty"` <del> // Optional: Supports "ClientIP" and "None".  Used to maintain session affinity. </del> <ins> // Required: Supports "ClientIP" and "None".  Used to maintain session affinity. </ins> SessionAffinity AffinityType `json:"sessionAffinity,omitempty"` }

Discussion:
Many comments in there say "if not specified, default is ..." - but we previously asserted that there are no defaults for the internal API. We should strip those comments out, and leave them in versioned structs only.
cc
Change:
// // If the webhook is running within the cluster, then you should use `service`. // <del> // If there is only one port open for the service, that port will be // used. If there are multiple ports open, port 443 will be used if it // is open, otherwise it is an error. </del> <ins> // Port 443 will be used if it is open, otherwise it is an error. </ins> // // +optional optional ServiceReference service = 1;

Discussion:
What happened: Deployed a webhook backend and service as follows: Please note that there is only 8443 port on the service. Register the webhook as follows: Got the following error when creating pods: What you expected to happen: Based on , should be called. Not the 443 port shown in the error message. How to reproduce it (as minimally and precisely as possible): Just deploy the same setup and register webhook. Anything else we need to know?: Environment: Kubernetes version (use ): HEAD Client Version: version.Info{Major:"1", Minor:"10+", GitVersion:"v1.10.0-alpha.1.97+-dirty", GitCommit:"", GitTreeState:"dirty", BuildDate:"2018-01-22T20:00:24Z", GoVersion:"go1.9.1", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"11+", GitVersion:"v1.11.0-alpha.0.470+", GitCommit:"", GitTreeState:"clean", BuildDate:"2018-03-12T19:36:42Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: GCE OS (e.g. from /etc/os-release): COS Kernel (e.g. ): COS
thanks for the detailed bug report!
I actually think that the API specification (or documentation) must change. Not all API servers will have access to look up the Service object and see what ports it defines. If we want to support ports other than 443, the port information must be specified in the webhook object, not discovered by direct Service object lookup
/assign
Looks like it will always use 443 no matter what ports are available, right? Should our documentation reflect this or should it behave differently? (also just sets 443 in the custom dial wrapper thing )
As a first step, I would adjust the documentation. As noted in , if we want to support ports other than 443, that information needs to be to the webhook config object
Change:
import ( "context" <ins> "encoding/json" </ins> "fmt" "reflect" "strconv" "time" v1 "k8s.io/api/core/v1" <ins> apiequality "k8s.io/apimachinery/pkg/api/equality" </ins> "k8s.io/apimachinery/pkg/api/resource" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/labels" "k8s.io/apimachinery/pkg/runtime" <ins> "k8s.io/apimachinery/pkg/types" utilrand "k8s.io/apimachinery/pkg/util/rand" </ins> "k8s.io/apimachinery/pkg/util/uuid" "k8s.io/apimachinery/pkg/util/wait" "k8s.io/apimachinery/pkg/watch"

Discussion:
4 Oct 2022 [x] Two weeks soak end date: 18 Oct 2022 [x] Test promotion PR: According to this APIsnoop query, there are still three remaining LimitRange endpoints which are untested. listCoreV1LimitRangeForAllNamespacespatchCoreV1NamespacedLimitRangedeleteCoreV1CollectionNamespacedLimitRange Using a number of existing e2e test practices a new has been created for three LimitRange endpoints. The e2e logs for this test are listed below. This query shows which LimitRange endpoints are hit within a short period of running this e2e test example endpoint | useragent --------------------------------------------+
createCoreV1NamespacedLimitRange | should ensure that a limitRange can be listed, patched and deleted by collection deleteCoreV1CollectionNamespacedLimitRange | should ensure that a limitRange can be listed, patched and deleted by collection listCoreV1LimitRangeForAllNamespaces | should ensure that a limitRange can be listed, patched and deleted by collection listCoreV1NamespacedLimitRange | should ensure that a limitRange can be listed, patched and deleted by collection patchCoreV1NamespacedLimitRange | should ensure that a limitRange can be listed, patched and deleted by collection (5 rows) If a test with these calls gets merged, test coverage will go up by 3 point This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/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
Change:
# comment this out to save yourself from needlessly building here. make -C "${KUBE_ROOT}" WHAT=cmd/kubeadm <ins> #TODO(runyontr): Remove the the KUBE_TIMEOUT override when # kubernetes/kubeadm/issues/1430 is fixed </ins> make -C "${KUBE_ROOT}" test  WHAT=k8s.io/kubernetes/cmd/kubeadm/test/cmd  <del> KUBE_TEST_ARGS="--kubeadm-path '${KUBEADM_PATH}'" </del> <ins> KUBE_TEST_ARGS="--kubeadm-path '${KUBEADM_PATH}'"  KUBE_TIMEOUT="--timeout 600s" </ins> set +o nounset set +o errexit }  No newline at end of file

Discussion:
this PR removed the script which can be used to run the integration tests. the following command is claimed to be a replacement: but instead it runs unrelated tests too. expecting the above command to only show the following output (run only kubeadm tests): /assign
GitHub didn't allow me to assign the following users: runyontr. Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : this PR removed the script which can be used to run the integration tests. but instead it runs unrelated tests too. /assign </details
/sig cluster-lifecycle
/milestone v1.14 We're entering and this looks relevant to the 1.14 release. Please if I am incorrect
Hey! Gentle reminder that code freeze is this Friday. Since this is part of the 1.14 milestone, is it going to be resolved soon?
hopefully in the next couple of days. PR is here:
Change:
actual_output=$(kubectl get pod --server-print=false "${kube_flags[@]}" | awk 'NF{NF--};1') kube::test::if_has_string "${actual_output}" "${expected_output}" <ins> # Test printing objects with --use-openapi-print-columns actual_output=$(kubectl get namespaces --use-openapi-print-columns --v=7 "${kube_flags[@]}" 2>&1) # it should request full objects (not server-side printing) kube::test::if_has_not_string "${actual_output}" 'application/json;as=Table' kube::test::if_has_string "${actual_output}"     'application/json' </ins> ### Test retrieval of daemonsets against server-side printing kubectl apply -f hack/testdata/rollingupdate-daemonset.yaml "${kube_flags[@]}" # Post-condition: daemonset is created

Discussion:
/kind bug /sig cli What happened: kubectl 1.11.0 defaults to (see ), hence, you need to explicitly specify it for each and every single request for a resource managed by an aggregated API server. However, it is even not able to print those resources properly (which was possible before with versions <= 1.10.5): and What you expected to happen: Properly printed and well-formatted output of . (Actually, I do not want to specify but this is what is for). Environment: Kubernetes version (use ):Kernel (e.g. ): MacOS Install tools: Brew
/cc
fixed in
/assign
Change:
CLEANUP=true GINKGO_FLAGS='--focus="[Serial]" --skip="[Flaky]"' SETUP_NODE=false <del> TEST_ARGS=--cgroups-per-qos=true </del> <ins> TEST_ARGS=--cgroups-per-qos=false </ins> PARALLELISM=1

Discussion:
In node-e2e-test on Containervm image, the containers of the pods created by Kubernetes are subcontainers of docker-daemon/docker/. It means that the runtime resource usage (docker-daemon) is not correct, because all pods are included. This problem maybe due to container misconfiguration in node-e2e-test.
The kubelet on debian-based containervm image is misconfigured. Will fix it shortly.
Change:
apierrs "k8s.io/apimachinery/pkg/api/errors" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/labels" <ins> utilerrors "k8s.io/apimachinery/pkg/util/errors" </ins> clientset "k8s.io/client-go/kubernetes" "k8s.io/kubernetes/test/e2e/framework" )

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --We should have an e2e to test issue . The test needs to delete a PVC while a pod is still using it, and then restart the controller manager. /kind bug /sig storage
CC
/assign unofficially so I can find this later.
Change:
fi # find test files calling SetFeatureGateDuringTest and not calling the result <del> missing_defers=$(find -L . -name '*_test.go' -exec grep -Hn 'SetFeatureGateDuringTest' {} ; 2>/dev/null | grep -E -v "defer .*)()$") || true </del> <ins> missing_defers=$(git grep ".SetFeatureGateDuringTest" -- '*_test.go' | grep -E -v "defer .*)()$") || true </ins> if [[ -n "${missing_defers}" ]]; then echo "Invalid invocations of featuregatetesting.SetFeatureGateDuringTest():" >&2 echo "${missing_defers}" >&2

Discussion:
PR was reverted by because it (erroneously) relied on OpenAPIV3 feature to be enabled, but would non-deterministically leave the feature disabled after running. I tracked it down to the fact that this test disables all or features in a loop which iterates over a , which are known to have unstable iteration order: When key is processed before key , then would disable before s default value is to be saved. Normally, ignores features that have been explicitly set, so it only affects those which fall back on the value. But this issue does not just affect but any non-GA feature. I suggest the loop in be made to skip the special feature keys such as . /cc /cc The value before every feature gate should be restored after running . This test always fails on my machine (just pasted it into ): No response <details</details<details</details<details</details<details</details<details</details<details</details
/assign
Wow, good catch, sorry to make you track down what turned out to be a bug in our test
/sig auth
/area test
/triage accepted
Change:
//  'nominalConcurrencyShares' field of 'limited' for CREATE operation. //  1:30: lift this restriction, allow zero value via v1 or v1beta3 opts := validation.PriorityLevelValidationOptions{ <del> AllowZeroLimitedNominalConcurrencyShares: utilfeature.DefaultFeatureGate.Enabled(features.ZeroLimitedNominalConcurrencyShares), </del> <ins> AllowZeroLimitedNominalConcurrencyShares: true, </ins> } return validation.ValidatePriorityLevelConfiguration(obj.(*flowcontrol.PriorityLevelConfiguration), getRequestGroupVersion(ctx), opts) }

Discussion:
In 1.30, Priority and Fairness should allow a zero value, either via v1 or v1beta3 (with the roundtrip annotation) in create and update requests See:
/sig api-machinery /cc /assign
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /triage accpted 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
/triage accepted
Change:
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/runtime" "k8s.io/apimachinery/pkg/runtime/schema" <ins> "k8s.io/apimachinery/pkg/util/sets" </ins> "k8s.io/apimachinery/pkg/util/wait" "k8s.io/apiserver/pkg/authentication/user" "k8s.io/apiserver/pkg/endpoints"

Discussion:
The in apiserver grows infinitely without ever purging serviceKeys which are not referenced by any APIServices. /sig api-machinery /cc /assign a limited size cache APIService your services Spec.Service field to a new address step 2 and watch the list grow No response_ <details26-1.27 </details<detailsN/A </details<details</details<detailsN/A </details<detailsN/A </details<detailsN/A </details
/triage accepted
/assign
what do we want to the limit the cache size by?
the cache currently doesn't purge s which are not being used by an
is this still an issue? should it be resolved before enabling by default?
Can you elaborate? I am not sure what you mean by enabling by default?
Yes That's the cache for the downloaded discovery for each apiservice. The list probably doesn't grow very large. Fix is in . Considering the pain of non-aggregated discovery on some users, and the time they have had to wait to get the feature, I'd say the trade-off is that this isn't nearly as bad.
It's also worth noting that the cache should only grow for Aggregated APIServices that themselves expose aggregated discovery endpoint. We don't store a cache entry here otherwise. The list doesn't grow unless the aggregated discovery document was successfully fetched. This is a very rare case and especially at release a minuscule number of people on the bleeding edge might run into it. And even then it is not likely to be changing the so often once it is working enough to store a cache entry.
Change:
spec: containers: - name: agnhost <del> image: e2eteam/agnhost:2.8 </del> <ins> image: e2eteam/agnhost:2.26 </ins> args: - serve-hostname nodeSelector:

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Add Support for Windows Server version 2004 and 20H2. Why is this needed: Windows Server version 1909 is going end of life.
/sig windows /triage accepted
Change:
pollingFunction := checkForAcceleratorMetrics(projectId, gcmService, time.Now(), metricsMap) err = wait.Poll(pollFrequency, pollTimeout, pollingFunction) if err != nil { <del> framework.Logf("Missing metrics: %+vn", metricsMap) </del> <ins> framework.Logf("Missing metrics: %+v", metricsMap) </ins> } framework.ExpectNoError(err) }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: is always appending a new line to its message: In some places of code, the message is already has a newline character and it leads to doubled new lines in the logs. What you expected to happen: I'm not sure what is the correct behavior here. One of the options could be to append a new line conditionally.
/sig testing
I'm new to Kubernetes and would like to start contributing. Is it ok if I assign myself this issue?
/assign MorrisLaw
GitHub didn't allow me to assign the following users: MorrisLaw. Note that only can be assigned. <detailsIn response to : /assign MorrisLaw 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
I can't assign this to myself, as I am not a member yet. But I am still going to take this issue.
I'll help him on reviews so assigning.
Change:
} } <del> containerByName := containerNameToRef(copied) name := o.Container if len(name) == 0 { name = o.computeDebugContainerName(copied) } </del> <ins> name, containerByName := o.Container, containerNameToRef(copied) </ins> c, ok := containerByName[name] if !ok { // Adding a new debug container if len(o.Image) == 0 { <ins> if len(o.SetImages) > 0 { // This was a --set-image only invocation return copied, "", nil } </ins> return nil, "", fmt.Errorf("you must specify image when creating new container") } <ins> if len(name) == 0 { name = o.computeDebugContainerName(copied) } </ins> c = &corev1.Container{ Name:                     name, TerminationMessagePolicy: corev1.TerminationMessageReadFile,

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 without specifying should modify existing container images without trying to create a new one. Instead it tries to create a new container and returns an error that isn't set: What you expected to happen: This command should change all container images to instead of returning an error. /sig cli /kind bug /priority important-soon
/assign /triage accepted
My kubernetes cluster version is 1.19.0,and i use kubectl-debug version 0.1.1 try to debug my pod,bug i got error: <img width="1470" alt="image" src="https://user-"Who one know about that
Change:
return *s } <del> // TODO(random-liu): Move this to some better place. // TODO(random-liu): Add test for convertStatusToAPIStatus() </del> func (kl *Kubelet) convertStatusToAPIStatus(pod *api.Pod, podStatus *kubecontainer.PodStatus) *api.PodStatus { var apiPodStatus api.PodStatus uid := pod.UID <ins> apiPodStatus.PodIP = podStatus.IP </ins> convertContainerStatus := func(cs *kubecontainer.ContainerStatus) *api.ContainerStatus { cid := cs.ID.String()

Discussion:
We moved reason cache and status convert function from to by , , and . After this, we should also migrate related old unit test to kubelet level. For we should add test for: [x] Different image pull policy. [x] Pod creation failure. [x] Pod image failure. For we should add test for: [x] ContainerStatuses order. [x] Last termination state. [x] How reason cache will affect the PodPhase: [x] Pull image failure reason [x] Pod creation failure reason
Time to close this issue? :)
Not yet, The last 3 tests are in . :)
Change:
package validation import ( <del> "reflect" </del> unversionedvalidation "k8s.io/apimachinery/pkg/apis/meta/v1/validation" "k8s.io/apimachinery/pkg/util/intstr" "k8s.io/apimachinery/pkg/util/validation"

Discussion:
I tried to update the NetworkPolicy Spec field with more ingress rules but got It seems NetworkPolicy does not allow update on Spec This means if I want to have more ingress rules, I will have to add those in a new networkpolicy in the same namespace. Any reason why I should not add those in the existing one(update the existing networkpolicy)? Thanks!
This is as designed for now. The expectation is that updates to the spec will be allowed when the NetworkPolicy API moves from v1beta1 to GA.
(And that is planned for Kubernetes 1.6 release.)
good to know, thanks!
Note that the PR to move NetworkPolicy to v1 did not make it into v1.6, but is now planned for 1.7:
Oh, I didn't know about this bug and that didn't get changed in but we can do it as another PR after. (I'm trying to not make any more changes there so we can get it merged.)
Change:
"spec.nodeName", "spec.restartPolicy", "spec.serviceAccountName", <ins> "spec.schedulerName", </ins> "status.phase", "status.hostIP", "status.podIP":

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?: What happened: When trying to list object using field spec.SchedulerName, we are getting the below error message. Failed to list : field label not supported: spec.schedulerName What you expected to happen: To be able to fetch pods using the list and watch based on the field 'spec.schedulerName' How to reproduce it (as minimally and precisely as possible): Create a simple controller to with a list and watch method. Set the FieldSelector ( in the ListOptions structure ) in the ListFunc and the WatchFunc to 'spec.SchedulerName=custome-SchedulerName' Running this controller yields the above error. Anything else we need to know?: Description: Unable to fetch pods based on the field 'spec.schedulerName'. This was in 1.6 version, for multi scheduler support in kubernetes. We need to be able to fetch pods 1) Assigned to a particular custom scheduler. 2) Should be able to fetch the state transition of the pods scheduled by a custom scheduler using the fields selector. Whats the correct way to use 'schedulerName' fields for fetching objects? Or is there any other way for the custom scheduler to determine the above information from the kubernetes? This is an urgent issue, any quick help/suggestion will be of great help. Environment: Kubernetes version : Client Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-06-29T23:15:59Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.1", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-07-14T01:48:01Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Install tools: kubeadm
There are no sig labels on this issue.

Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig api-machinery
/cc
cc
SIG API Machinery doesn't own the contents of the API--we only need to be involved if the mechanism needs to be general.
Given the error message mentioned in the bug report at the top of this thread, do you have a suggestion of what we forgot to do when we the SchedulerName field to the PodSpec? i.e. to enable field selection on the schedulerName field?
/cc me