jiebi/CodeConvo huggingface dataset:
Change:
Expect(execOutput).To(ContainSubstring("Using in-cluster namespace")) Expect(execOutput).To(ContainSubstring("Using in-cluster configuration")) <ins> By("creating an object containing a namespace with in-cluster config") _, err = framework.RunHostCmd(ns, simplePodName, "/tmp/kubectl create -f /tmp/invalid-configmap-with-namespace.yaml --v=7 2>&1") Expect(err).To(ContainSubstring("Using in-cluster namespace")) Expect(err).To(ContainSubstring("Using in-cluster configuration")) Expect(err).To(ContainSubstring(fmt.Sprintf("POST https://%s:%s/api/v1/namespaces/configmap-namespace/configmaps", inClusterHost, inClusterPort))) By("creating an object not containing a namespace with in-cluster config") _, err = framework.RunHostCmd(ns, simplePodName, "/tmp/kubectl create -f /tmp/invalid-configmap-without-namespace.yaml --v=7 2>&1") Expect(err).To(ContainSubstring("Using in-cluster namespace")) Expect(err).To(ContainSubstring("Using in-cluster configuration")) Expect(err).To(ContainSubstring(fmt.Sprintf("POST https://%s:%s/api/v1/namespaces/%s/configmaps", inClusterHost, inClusterPort, f.Namespace.Name))) </ins> By("trying to use kubectl with invalid token") _, err = framework.RunHostCmd(ns, simplePodName, "/tmp/kubectl get pods --token=invalid --v=7 2>&1") framework.Logf("got err %v", err)

Discussion:
This is similar to , but that report (and fix) focussed on the in-cluster namespace vs configured .kube/config context namespace. I have a similar issue with the in-cluster namespace vs an explicit in the JSON/YAML file I'm passing to When run in-cluster, 1.5+ (including 1.6.0) refuses to allow me to create a resource in another namespace via an explicit property on a resource. 1.4.x honours when run in-cluster as expected. All versions honour when run out-of-cluster. I don't want to / can't provide an explicit arg or context declaration as suggested by the error text, because this is an automated deployment pipeline that creates resources in multiple namespaces. I just want the client to do-what-I-say without imposing additional client-side restrictions :stuckouttongue:
Fixed in
Change:
) } # Instantiate a kubernetes cluster function kube-up { get-password

Discussion:
Self-assigning as I work out a reliable fix.
cc
Running into a few issues. On GCE, did you guys block somewhere to wait for etcd to be running before reporting success on kube-up?
No, except there is a race between addson services, dns and etcd container. We introduced a retry logic on those services.
I assume pulling the image is just so fast that you don't run into e2e errors, it looks like you guys block on wait-for-minions that uses glcloud, so I guess when minions are reported in etcd, then you know you are good...
Change:
local attempt=1 local result="" while true; do <del> if result=$(gcloud compute ${resource} list --project=${PROJECT} ${@:2} | grep "${GREP_REGEX}"); then </del> <ins> if result=$(gcloud compute ${resource} list --project=${PROJECT} ${@:2}); then if [[ ! -z "${GREP_REGEX}" ]]; then result=$(echo "${result}" | grep "${GREP_REGEX}") fi </ins> echo "${result}" return fi

Discussion:
gcloud at HEAD changed output of some compute list commands to print nothing to stdout, which causes to fail spuriously. Currently trying to patch a fix. cc
Change:
"github.com/GoogleCloudPlatform/kubernetes/pkg/api" "github.com/GoogleCloudPlatform/kubernetes/pkg/client" "github.com/GoogleCloudPlatform/kubernetes/pkg/labels" <ins> "github.com/GoogleCloudPlatform/kubernetes/pkg/util" </ins> "github.com/GoogleCloudPlatform/kubernetes/pkg/util/wait" "github.com/GoogleCloudPlatform/kubernetes/pkg/version" "github.com/golang/glog"

Discussion:
-s=118 -p 9376:9376 run thockin/hostname 3 hostnameController results in a validation error: Service.ID: invalid value 'hostnameController' "hostnameController" is accepted for the replication controller, but not for the service ID.
Change:
if !sufficientStorage { reasons = append(reasons, ErrReasonNotEnoughSpace) } <ins> if !boundPVsFound { reasons = append(reasons, ErrReasonPVNotExist) } </ins> }() start := time.Now()

Discussion:
What would you like to be : Scheduler VolumeBinding plugin reports error when a PVC doesn't exist for example: We need to take a second look at the VolumeBinding plugin and make sure that errors are returned only when there is a system error, not a user error. Why is this needed: To fix the scheduler's error reporting metrics. /sig scheduling /sig storage /cc
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign I'll take a look.
If the PVC object does not exist, the plugin will return status. I guess you mean the plugin will return an error when a referenced PV does not exist? I've created a PR for this:
Thanks! The errors I am seeing are on 1.18 clusters, can we look at 1.18 and try to patch? This is still throwing the scheduler's error metrics off.
sure
I've submitted a patch for the 1.18 release branch:
I guess on the master branch should be reviewed and merged too? cc
hello! the fix you made only apply for 1.18? how about 1.19 and 1.17? thanks!
after the fix on the master branch () is merged, I'll cherry-pick it into the 1.19 branch (the code are almost the same). I'm not sure if it's necessary to fix the 1.17 branch. It's 3 versions behind 1.20.
hi, This is because of this patch: Do you think this fix needs to be cherry-picked into 1.19 and 1.18 branch too?
can you send a patch for 1.19?
ah, here it is
to sum up: master: 1.19: 1.18: and I think this change should be backported to 1.19/1.18 too: I'll send PRs soon.

summary of the issue that an error will be reported instead of UnschedulableAndUnresolvable when PVC not found: master: already implemented, see 1.19: 1.18: can't backport as it does not implement the PreFilter extension point
Change:
klog.V(2).Infof("node %s references an owner %s with coordinates that do not match the observed identity", n.identity, ownerNode.identity) } hasPotentiallyInvalidOwnerReference = true <ins> } else if !ownerIsNamespaced && ownerNode.identity.Namespace != n.identity.Namespace && !ownerNode.isObserved() { // the ownerNode is cluster-scoped and virtual, and does not match the child node's namespace. // the owner could be a missing instance of a namespaced type incorrectly referenced by a cluster-scoped child (issue #98040). // enqueue this child to attemptToDelete to verify parent references. hasPotentiallyInvalidOwnerReference = true </ins> } } }

Discussion:
What happened: create a namespaced parent object (for example a ) delete the parent object create a cluster-scoped object (for example. an ) with the parent as an , which is unresolvable since the parent is namespaced. create a namespaced object (for example another ) in the same namespace, with the parent as an , which should be valid. The namespaced child and the cluster-scoped child are not garbage collected. What you expected to happen: The namespaced child should be garbage collected immediately after being created, the cluster-scoped child should not be. Reproduction: Setup: parent- cluster-scoped- namespaced- Scenario 1: one terminal, run another, a third, run See that the cluster scoped child and namespaced child are both created but not deleted. Scenario 2: one terminal, run another, run See that the namespaced child is created and immediately deleted. My expectation is that the garbage collection of should not depend on , however scenarios 1 and 2 do not seem consistent. Environment: Kubernetes version (use ): 1.20.0 Cloud provider or hardware configuration: Kind 1.20.0 OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/assign
Thanks for the detailed report, reproduced the issue with a unit test in
/priority important-soon /triage accepted /sig api-machinery
Change:
# # $1 - server architecture kube::build::get_docker_wrapped_binaries() { <del> local debian_iptables_version=buster-v1.3.0 </del> <ins> local debian_iptables_version=buster-v1.4.0 </ins> local go_runner_version=buster-v2.2.2 ### If you change any of these lists, please also update DOCKERIZED_BINARIES ### in build/BUILD. And kube::golang::server_image_targets

Discussion:
What happened: The latest release of the debian-base image, v2.1.3, contains a vulnerable version of the apt package. CVE-2020- impacts apt version 1.8.2.1. What you expected to happen: Image should be updated to use at least apt 1.8.2.2 to clear the vulnerability. How to reproduce it (as minimally and precisely as possible):
/sig release
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
kube-proxy is using debain as base image. /assign Let me check other components
checked the base image in and I seems that no new debian or ubuntu official image is built for this CVE ?
That is correct, the purpose of this issue is to get a new image built and released, one which contains a resolution for the CVE.
per comments of @ tianon in Will update it once debain releases it.
Change:
"net/http" "runtime" "strings" <ins> "sync" </ins> "time" "k8s.io/apiserver/pkg/endpoints/metrics"

Discussion:
Apiserver crashed with stacktrace: Not to crash I was able to reproduce it by "slowing down" deleting headers in Authentication filter (): And making requests (around 5-10 requests to trigger this race condition): Crash was caused by race condition - one goroutine was modifying headers of requests (for example authentication filter). The other goroutine was trying to get UserAgent from request, which is also taken from request's headers map. This causes unrecoverable panic. <detailsAll versions, tested on 1.21 </details<detailsN/A </details<details</details<details</details<details</details<details</details
/sig api-machinery /priority important-soon
/triage accepted
Reopening - since we need to cherrypick it to previous releasses.
- friendly ping on opening cherrypicks
I've opened two cherry-picks:
One more for 1.20:
All merged - thanks!
Change:
} if !needsConversion { <ins> // We might be an external type, but have empty kind/apiVersion fields. Ensure they are populated before printing. if obj.GetObjectKind().GroupVersionKind().Empty() { obj = obj.DeepCopyObject() obj.GetObjectKind().SetGroupVersionKind(gvks[0]) } </ins> return p.printer.PrintObj(obj, w) }

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: Upgraded Kubectl to version 1.10.0 and now the flag on the creation of a docker-registry secret doesn't print out resulting in the following error: What you expected to happen: I expect the output to have a attribute in the YAML output. How to reproduce it (as minimally and precisely as possible): Here is an example you can run in bash of this not working: The output is: My exact shell code I'm running on the CI server is this Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: 3 on AWS managed with KOPS OS (e.g. from /etc/os-release): Alpine Linux on my CI server, MacOS on my main machine Kernel (e.g. ): Darwin Kernel Version 17.4.0
/sig CLI
cc
/status approved-for-milestone
/assign
[MILESTONENOTIFIER] Milestone Issue: Up-to-date for process <details open<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
fyi
The issue appears to be with the command, not with : Will look into this
fix is in
No, the output of is missing kind/apiVersion.
thanks, just saw the PR
Change:
"github.com/golang/glog" "k8s.io/kubernetes/pkg/api" apiservice "k8s.io/kubernetes/pkg/api/service" <ins> "k8s.io/kubernetes/pkg/api/v1" "k8s.io/kubernetes/pkg/client/record" </ins> "k8s.io/kubernetes/pkg/proxy" "k8s.io/kubernetes/pkg/proxy/healthcheck" "k8s.io/kubernetes/pkg/types"

Discussion:
When kube-proxy fails to open a nodeport, it gives up setting up the rest of the iptables rules for the service. Leaving the service not usable. Cannot even use it with clusterIP. Kube-proxy only logs this error in . No useful information can be retrieved with kubectl. Need to record a event at least.
Ideally would the changes be removed and then reported back? Is there a preferred log or place to return the error?
the event maybe a better solution; as other port maybe success.
Need to surface the problem somewhere. An event seems okay
, there's and in ; should we reuse it or create new recorders for ?
Just reuse it. After all, it is within the same component. Are you going to submit a PR?
sure, my pleasure.
Great! Thanks! Let me know when the PR is ready.
Change:
return nil }), }) <del> nc.taintManager = scheduler.NewNoExecuteTaintManager(kubeClient) </del> } nc.nodeLister = nodeInformer.Lister()

Discussion:
Just saw this while running kube master locally: Yet to investigate more closely and check which PR could have introduced this. cc
/sig node
any way to repro?
I think I can fix this error.
what is the bug?
I think when call nc.taintManager has not been inited
duplicate of , fixed by
I found does not have related fix.
It fixes the issue systemically by not starting the informers until all controllers have finished setting up
Ok by more carefully read, I see.
fixed by
Change:
KUBE_ROOT=$(dirname "${BASH_SOURCE}")/../.. <del> ETCD_VERSION=${ETCD_VERSION:-v0.4.6} </del> <ins> ETCD_VERSION=${ETCD_VERSION:-v2.0.0} </ins> cd "${KUBE_ROOT}/third_party" curl -sL https://github.com/coreos/etcd/releases/download/${ETCD_VERSION}/etcd-${ETCD_VERSION}-linux-amd64.tar.gz 

Discussion:
writes: As we start looking into etcd and event memory pressure [], we should look into switching over to etcd 2.0 which was released today.
cc/
+1 On Jan 28, 2015 5:29 PM, "Dawn Chen" wrote:
My long-running cluster tests resulted in a hard-crash on etcd: We should move to 2.0 ASAP in the hopes of (a) fixing the issue and if not (b) prioritizing the fix since we'll be complaining about head. Abhi, is this something you can pick up and drive to land in O(days) please?
Calling this P0 as it blocks further long-running cluster stability testing.
I will do this today. , Alex Mohr wrote:
Change:
}, }, { <del> name: "invalid ordinals.start " + enableStatefulSetStartOrdinal, </del> <ins> name: "invalid ordinals.start ", </ins> set: apps.StatefulSet{ ObjectMeta: metav1.ObjectMeta{Name: "abc-123", Namespace: metav1.NamespaceDefault}, Spec: apps.StatefulSetSpec{

Discussion:
This applies to StatefulSetStartOrdinal feature gate. Field validation should be done regardless of the feature gate state. From
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
/sig apps
Change:
wErr:  fmt.Errorf("error while running score plugin for pod "2": %+v", errPrioritize), }, { <del> name: "test even pods spread predicate - 2 nodes with maxskew=1", </del> <ins> name: "test podtopologyspread plugin - 2 nodes with maxskew=1", </ins> registerPlugins: []st.RegisterPluginFunc{ st.RegisterQueueSortPlugin(queuesort.Name, queuesort.New), st.RegisterPluginAsExtensions(

Discussion:
How to reproduce it (as minimally and precisely as possible): pre-requisites: a multi-az cluster, a deployment with 1 pod in each az. a with and . the node(s) in 1 az. the deployment's pod(s) from the cordoned az. What happened: A new pod was created and scheduled in a form that What you expected to happen: I expected that a new pod will be created and be "stuck" in status as it shouldn't have nowhere be scheduled. Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: AWS OS (e.g: ):Kernel (e.g. ): 4.19.84-coreos Others: I created a with how I reproduce the bug
/sig scheduling
cc/
Thanks for raising this issue. I feel like it's a general timing issue - when you delete a Pod, that Pod may still exist for a very short time (in graceful deletion period), and at the same time, the controller backfills a Pod for it. So when scheduling tries to schedule the backfill Pod, it may read the cluster as: [1, 1, 1(deleting)]. To confirm this, can you try deleting the Pod using , and see if the problem goes away?
Yes sure I will try that. It sounds reasonable, thats why in the first demonstration I deleted all the pods and waited for all of them to completely disappear. Nevertheless, this is still something that I believe needs to be fixed. The pod's evaluation should take in consideration pods that are in status and don't count them as pods.
I do believe we exclude the Pods. (if not, it should be a serious regression). What concerns me is that at that moment, scheduler may treats that (deleting) Pod as running in its cache. I will try to debug into this.
Yep, this time the new pod was in status until I uncordoned the relevant nodes.
Change:
cfg := make(map[string]string) cfg[cfgAccessToken] = token.token.AccessToken cfg[cfgRefreshToken] = token.token.RefreshToken <ins> cfg[cfgEnvironment] = token.environment </ins> cfg[cfgClientID] = token.clientID cfg[cfgTenantID] = token.tenantID cfg[cfgApiserverID] = token.apiserverID

Discussion:
What happened: AAD support in kubectl does not work for sovereign cloud The 'environment' parameter was introduced to support sovereign cloud, but it works in first round. The 'environment' value is not persisted, so follow-up requests will fail. What you expected to happen: 'environment' parameter persisted in kubectl config file. How to reproduce it (as minimally and precisely as possible): Use kubectl to connect to Azure sovereign cloud, make the token expire, and do auth. Anything else we need to know?: Environment: Kubernetes version (use ): 1.11 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
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
Change:
RenewTime:      &metav1.MicroTime{Time: time.Now()}, }, }, <ins> &corev1.Pod{ ObjectMeta: metav1.ObjectMeta{ Name:      "pod-with-resources", Namespace: "foo", }, TypeMeta: metav1.TypeMeta{ Kind: "Pod", }, Spec: corev1.PodSpec{ Containers: []corev1.Container{ { Name:  "cpu-mem", Image: "image:latest", Resources: corev1.ResourceRequirements{ Requests: getResourceList("1", "1Gi"), Limits:   getResourceList("2", "2Gi"), }, }, { Name:  "hugepages", Image: "image:latest", Resources: corev1.ResourceRequirements{ Requests: getHugePageResourceList("2Mi", "512Mi"), Limits:   getHugePageResourceList("2Mi", "512Mi"), }, }, }, }, Status: corev1.PodStatus{ Phase: corev1.PodRunning, }, }, </ins> ) c := &describeClient{T: t, Namespace: "foo", Interface: fake} d := NodeDescriber{c}

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: scheduler doesn't assign pod because 'not enough resource: hugepages-1Gi',but the node info show it has enough resource. describe node What you expected to happen: the pod was in normal status like pending and running How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: It was change default hugepage size to 1Gi and hugepages=36 numastat was show there has enough hugepage also proc/meminfo was show there has enough resource other info 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 node
cc do you have thoughts here? I see huge pages and think of you :)
Hmm. Are you sure that there are no other pods using huge page memory ? To me, it looks like the node has (huge page @ 1GiB) memory, you are requsting , but is already used. Can you verify that by listing the pods on the node, and check if some of them are using huge page memory already?
Also, the OS will report that no huge pages are in use as long as no processes have started using the hugepages. Eg. when a pod requesting with is assigned to a node, k8s will then mark the s with huge page memory it as "used". The cgroup controller (if hugetlb cgroup is mounted) will then set the usage limit to . Before the pod actually starts using the huge page memory, the OS will report that no huge page memory is used. When a process inside the pod maps with huge page memory via eg. , the OS will see that the memory is in used. If the process tries to map more than the requested amount, the map will fail (given that the hugetlb cgroup is mounted). To verify if the hugetlb cgroup is mounted, run .

If mounted, it will retrun something like this:
I’m so sorry that there actually has a other pod using hugepagei only see node info available hugepage. so i close the issuethanks a lot
No problem I think this issue is a symptom that something should be done to make it easier to understand. I will look into it.
Change:
Once you have that service description, you can create the service with the cloudcfg cli: ```shell <del> ./src/scripts/cloudcfg.sh -c redis-master-service create /services </del> <ins> ./src/scripts/cloudcfg.sh -c redis-master-service.json create /services </ins> ``` Once created, the service proxy on each minion is configured to set up a proxy on the specified port (in this case port 10000).

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: The image () used to run the per-pod infra/pause container logs to stdout about once per second. What you expected to happen: Pause container not logging anything. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Kubelet does not expose, nor manage these logs. Writing the logs wastes resources and takes up disk space, which may not be properly accounted by kubelet. The pause image used for the e2e tests seems much better: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/assign Will also rebuild with