jiebi/CodeConvo huggingface dataset:
Change:
if err != nil { return false, false, err } <del> for _, existingPod := range allPods { </del> <ins> // Special case: When the topological domain is node, we can limit our // search to pods on that node without searching the entire cluster. if term.TopologyKey == kubeletapis.LabelHostname { pods = nodeInfo.Pods() } for _, existingPod := range pods { </ins> match := priorityutil.PodMatchesTermsNamespaceAndSelector(existingPod, namespaces, selector) if match { matchingPodExists = true

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --It is not a secret that . In my opinion the main reason for the slowness is the flexibility of the inter-pod affinity/anti-affinity rules. However, in most practical scenarios users do not need all the flexibility. For example, people often do not use arbitrary labels in topology key of the affinity rules. They often use node, zone, or region as the topology. Node in particular is used often. That's why I am proposing a fast path for the case that topology key is Node. Today, the affinity/anti-affinity predicate does not have any distinction for topology keys and in the cluster regardless. The logic should recognize "" and scan only pods on the same node for this topology key. Is this a BUG REPORT or FEATURE REQUEST?: FEATURE REQUEST /kind feature /sig scheduling cc/
ref/
/assign
GitHub didn't allow me to assign the following users: misterikkit. 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
/cc
We found some other simple optimizations that had a significant impact on the affinity predicate. I will upload PRs for those as well.
Reopening this as the performance of anti-affinity still doesn't seem to be satisfactory enough on large clusters (i.e 5k nodes) - and it's causing them to fail to startup. Ref: issue I can help with evaluating any performance improvements if needed.
The change sent improved performance of the predicate, but apparently it is not enough to make our large scale scalability tests happy.
This issue is not about general performance improvment of affinity/anti-affinity. It was to implement a particular improvment which is already implemented. There are other performance improvement issues. I am going to close this one.
Sounds good. Thanks.
How come with kops 1.10.0 I still see all kube-dns pods on the same node because the kube-dns deployment doesn't specify any anti-affinity rule?
I think you are correct. you can double-check with the option to . I have a v1.9 cluster in front of me, and kube-dns has no affinity rules. (I didn't use kops though)
Change:
$(META_DIR)/$(DEFAULTER_GEN).todo: $(DEFAULTER_FILES) $(DEFAULTER_FILES): $(DEFAULTER_GEN) <del> if [[ "$(DBG_CODEGEN)" == 1 ]]; then          </del> <ins> if [[ "$(DBG_CODEGEN)" == 1 ]]; then       </ins> echo "DBG: defaulter needed $(@D):";   <del> ls -lf --full-time $@ $? || true;         </del> <ins> ls -lf --full-time $@ $? || true;      </ins> fi echo $(PRJ_SRC_PATH)/$(@D) >> $(META_DIR)/$(DEFAULTER_GEN).todo

Discussion:
In the codegenerator we have: So basically we process only packages that are explicitly requested by the user and ignore ones that are imported. So in order to have the conversion func imported by the generator, the package where it lives has to be explicitly imported. So we should basically always pass all input packages to conversion generator. This is problematic, when regenerating conversions, we simply pass to input directories only those that were changed in the meantime: We should fix that - probably by passing all CONVERSIONDIRS as inputs to conversion-gen /kind-bug
I think this caused Not sure if was related yet.
It's the other way around - this is the main bug and root cause and the other that you linked is a consequence.
Also - FYI
I actually already started looking into it - so let me assign this.
is out for review
/triage accepted
Change:
which represents all IPs on the host. release: v1.16 file: test/e2e/scheduling/predicates.go <del> - testname: Scheduling, HostPort matching and HostIP and Protocol not-matching codename: '[sig-scheduling] SchedulerPredicates [Serial] validates that there is no conflict between pods with same hostPort but different hostIP and protocol [LinuxOnly] [Conformance]' description: Pods with the same HostPort value MUST be able to be scheduled to the same node if the HostIP or Protocol is different. This test is marked LinuxOnly since hostNetwork is not supported on Windows. release: v1.16 file: test/e2e/scheduling/predicates.go </del> - testname: Pod preemption verification codename: '[sig-scheduling] SchedulerPreemption [Serial] PreemptionExecutionPath runs ReplicaSets to verify preemption running path [Conformance]'

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: We want to change ownership of a test from scheduler to network Which test(s) are failing: [sig-scheduling] SchedulerPredicates [Serial] validates that there is no conflict between pods with same hostPort but different hostIP and protocol [Conformance] Since when has it been failing: Testgrid link: https://k8s- Reason for failure: Once merges, we will exclude hostPort test on Windows. This is because of how the hostPort test is structured where we are relying on hostNetwork pod to test the communication between hostPort pods. This will not work on Windows as hostNetwork is not supported. I think it is better to have this test in sig-network and test the communication as scheduler should be responsible only for assigning a pod to node. This also ensures that hostPort on Windows is exercised properly. Anything else we need to know: More context
/sig scheduling /sig network cc
/area conformance /area test /sig windows since windows
/triage accepted
Change:
} pod.Spec.Host = machine pod.Status.Host = machine <ins> if pod.Annotations == nil { pod.Annotations = make(map[string]string) } for k, v := range annotations { pod.Annotations[k] = v } </ins> finalPod = pod return pod, nil })

Discussion:
Recap of related tangent in follows. Use case: I need to implement mesos task reconciliation in the kubernetes-mesos scheduler. If it crashes and then restarts, I want to be able to recover things like taskID, slaveID, offerID, etc. so as to rebuild the internal state of the scheduler. Once state is recovered, I can reconcile the against the tasks that the mesos master knows about. If I can't use binding annotations for this, then I need to store state some other (super inconvenient) way. Currently the etcd registry assignPod() implementation drops binding annotations on the floor. It should not, and instead they should be preserved for later access. Proposal: Store binding-related annotations in a new field: Pod.Status.Annotations When setting Pod.Status.Host="{some-host-name}" via assignPod(), binding annotations are copied in from Binding When cloning Pod.Status.Host in UpdatePod() (for an already-scheduled pod), the Pod.Status.Annotations are also cloned. I don't think /bindings has to be a readable apiserver endpoint, as long as the binding metadata is exposed some other way, as proposed above. I'd also like to propose that once binding annotations are "bound" to Pod.Status they become read-only. So they're essentially write-once, just like Pod.Status.Host is meant to be. cc xref
There is one situation where we probably want to clear Host, actually: in the case that the pod can't actually be materialized on the selected node for some reason, such as .
Any objection to a PR implementing my proposal? I'm happy to do the work.
You'll probably want to do it on top of (or after it lands) since that code path is changing significantly.
Though it is also represented in PodStatus, Host is properly a field in the PodSpec. Status must be completely reconstructable based on observations. The proposed Pod.Status.Annotations would not be. Furthermore, I don't think we should introduce another annotations field to Pod. I'd prefer to add a podAnnotations field to Binding, and then merge them into the pod. As for clearing the annotations, I'd prefer to simply fail a pod that was rejected by a node so as not to have to deal with that. Also note the discussion here re. moving binding to a pod subresource:
See also .
Change:
}, { api.Pod{ <del> ObjectMeta: api.ObjectMeta{Name: "foo", DeletionTimestamp: &now}, </del> <ins> ObjectMeta: api.ObjectMeta{Name: "foo"}, </ins> Spec:       api.PodSpec{Containers: []api.Container{{Image: "foo:V1"}}}, }, api.Pod{ <del> ObjectMeta: api.ObjectMeta{Name: "foo"}, </del> <ins> ObjectMeta: api.ObjectMeta{Name: "foo", DeletionTimestamp: &now}, </ins> Spec:       api.PodSpec{Containers: []api.Container{{Image: "foo:V1"}}}, }, true,

Discussion:
Honestly I'm not sure if this is a bug or a feature, but didn't expect it. Filing this to track.
I think it's a bug. Nothing in the code base depends on it that I can see (edit: namespace deletion does, but only via an in-server call which I'd like to see fixed), and we don't let other delete-related fields mutate during update (deleteGracePeriodSeconds)
Change:
limits: memory: 200Mi requests: <del> cpu: 100m </del> <ins> cpu: 90m </ins> memory: 200Mi volumeMounts: - name: varlog

Discussion:
This causes one component on master to fail in our standard test clusters. Usually it's NPD: cc
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
/sig cluster-lifecycle
Change:
"k8s.io/kubernetes/test/integration/framework" ) <del> // TestCustomResourceValidatorsWithDisabledFeatureGate test that x-kubernetes-validations work as expected when the // feature gate is disabled. func TestCustomResourceValidatorsWithDisabledFeatureGate(t *testing.T) { defer featuregatetesting.SetFeatureGateDuringTest(t, utilfeature.DefaultFeatureGate, genericfeatures.CustomResourceValidationExpressions, false)() server, err := apiservertesting.StartTestServer(t, apiservertesting.NewDefaultTestServerOptions(), nil, framework.SharedEtcd()) if err != nil { t.Fatal(err) } defer server.TearDownFn() config := server.ClientConfig apiExtensionClient, err := clientset.NewForConfig(config) if err != nil { t.Fatal(err) } dynamicClient, err := dynamic.NewForConfig(config) if err != nil { t.Fatal(err) } t.Run("x-kubernetes-validations fields MUST be dropped from CRDs that are created when feature gate is disabled", func(t *testing.T) { schemaWithFeatureGateOff := crdWithSchema(t, "WithFeatureGateOff", structuralSchemaWithValidators) crdWithFeatureGateOff, err := fixtures.CreateNewV1CustomResourceDefinition(schemaWithFeatureGateOff, apiExtensionClient, dynamicClient) if err != nil { t.Fatal(err) } s := crdWithFeatureGateOff.Spec.Versions[0].Schema.OpenAPIV3Schema if len(s.XValidations) != 0 { t.Errorf("Expected CRD to have no x-kubernetes-validatons rules but got: %v", s.XValidations) } }) } </del> // TestCustomResourceValidators tests x-kubernetes-validations compile and validate as expected when the feature gate // is enabled. func TestCustomResourceValidators(t *testing.T) {

Discussion:
This is the tracking issue of promoting CRD validation rules to GA: Listed the blocking issues/features below: [x] [x] [x] [x] Issues be aware of but should not be a GA blocker [ ] [ ] [ ] [ ] [ ] /sig api-machinery /triage accepted
/assign
/cc
Change:
### Setup <del> Download a prebuilt Debian VMDK to be used as base image: </del> <ins> Download a prebuilt Debian 7.7 VMDK that we'll use as a base image: </ins> ```sh <del> wget https://storage.googleapis.com/govmomi/vmdk/kube.vmdk.gz{,.md5} </del> <ins> curl --remote-name-all https://storage.googleapis.com/govmomi/vmdk/2014-11-11/kube.vmdk.gz{,.md5} </ins> md5sum -c kube.vmdk.gz.md5 gzip -d kube.vmdk.gz ``` <del> Upload this VMDK to your vSphere instance: </del> <ins> Import this VMDK into your vSphere datastore: </ins> ```sh export GOVC_URL='user:pass@hostname'

Discussion:
When wgetting to this address during the installation process, this just fails silently. Turns out the issue is that if you take a raw and curl that address you get a TLS error. I've fixed it by changing to , but obviously that's more risky.
Related (filed after an email exchange around wget) I don't have easy access to the vSphere so I can't verify how it relates to my debian install.
Yes, that is exactly the error I was experiencing.
Does curl work? Or is it busted too?
Curl is not installed on the image by default. I'm building a new image based on Debian 7.7 where I pull in curl by default, so we can switch to using that everywhere (instead of an awkward mix of wget and curl).
Thanks for reporting this I hadn't seen this yet. I uploaded a new VMDK that includes curl and updated the deployment scripts to use curl. I verified that deployment works again for me.
I can confirm that this works now with latest build from master on ESX. Probably still won't work with v0.4.3 (even w new image) since the scripts still used wget back then.
We are probably going to fork for v0.5 soon. But I can backport if this trips folks up. sent from tiny keyboard On Nov 12, 2014 9:09 AM, "Ben Smith" wrote:
Change:
if err != nil { return err } <del> if !data.State.Running && (kl.minimumGCAge == 0 || time.Now().Sub(data.State.FinishedAt) > kl.minimumGCAge) { </del> <ins> if !data.State.Running && (time.Now().Sub(data.State.FinishedAt) > kl.minimumGCAge) { </ins> dockerData = append(dockerData, data) } }

Discussion:
Things like SyncFrequency should have a lower-bound of acceptable, and that really should be 0ns.
The main point of this is now fixed, though we could be better about input checking all over
Change:
// ClientForVersion initializes or reuses a client for the specified version, or returns an // error if that is not possible func (c *clientCache) ClientForVersion(version string) (*client.Client, error) { <ins> if client, ok := c.clients[version]; ok { return client, nil } </ins> config, err := c.ClientConfigForVersion(version) if err != nil { return nil, err } <del> if client, ok := c.clients[config.Version]; ok { return client, nil } </del> client, err := client.New(config) if err != nil { return nil, err

Discussion:
This seems like a bug to me No output, and command exits success... wat. Have to explicitly pass to see expected output. If the client version is greater the server version, it should be making requests based on the server's newest accepted apiversion.
cc
Change:
export SECONDARY_RANGE_NAME="pods-default" export STORAGE_BACKEND="etcd3" export STORAGE_MEDIA_TYPE="application/vnd.kubernetes.protobuf" <del> export ETCD_IMAGE=3.5.3-0 export ETCD_VERSION=3.5.3 </del> <ins> export ETCD_IMAGE=3.5.4-0 export ETCD_VERSION=3.5.4 </ins> # Upgrade master with updated kube envs "${KUBE_ROOT}/cluster/gce/upgrade.sh" -M -l

Discussion:
Please publish 3.5.4-0 image and update to to benefit from fix for , while still keeping v3.5.3 critical correctness fixes (, ). For recent PRs for update to etcd v3.5.3 see and
/sig release /sig api-machinery /kind bug
/cc /triage accepted
Hey, Can I work on this ? I'm a beginner, but all the good first issues are mostly assigned. Can you guide me on doing this ?
I am working on this. /assign
Hi I would like to work on Make sense to backport in v1.22, v1.23 & v1.24? Thanks!!
hi, it makes sense to me, but requires approval from dependency maintainers. i can only approve the kubeadm changes.
was this backported ?
Change:
Once you have that service description, you can create the service with the `cloudcfg` cli: <del> ```shell cluster/cloudcfg.sh -c redis-master-service.json create /services </del> <ins> ```js $ cluster/cloudcfg.sh -c examples/guestbook/redis-master-service.json create /services Using master: kubernetes-master (external IP: 1.2.3.4) { "id": "redismaster", "port": 10000, "labels": { "name": "redis-master" } } </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). ### Step Three: Turn up the replicated slave pods. <del> Although the redis master is a single pod, the redis read slaves are a 'replicated' pod, in Kubernetes, a replication controller is responsible for managing multiple instances of a replicated pod.  Create a file named `redis-slave-controller.json` that contains: </del> <ins> Although the redis master is a single pod, the redis read slaves are a 'replicated' pod. In Kubernetes, a replication controller is responsible for managing multiple instances of a replicated pod. </ins> <del> ```javascript </del> <ins> Create a file named `redis-slave-controller.json` that contains: ```js </ins> { "id": "redisSlaveController", "desiredState": {

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: I am running an admission webhook using If there it has been hours since the last mutating request to the webhook, then the next mutating request will take many seconds to be processed. This may even take long enough to have the request time out. What you expected to happen: A request takes approximately the same amount of time to be processed regardless of how long it has been since the last request. How to reproduce it (as minimally and precisely as possible): Create an API server for handling a new API group. Wait a couple hours. Send a CREATE request to the API server. Observe that the CREATE request takes a few seconds to complete. Anything else we need to know?: This is the offending code. It must loop through once for every second since the last request. Environment: Kubernetes version (use ): 1.19.0
/sig api-machinery
I thought we'd already merged a fix for this from before the release?
I assume that the fix was supposed to be From my understanding, those changes only are in effect if the apiserver is running with priority and fairness enabled. In my situation, I do not have that enabled.
Ack, if we have the problem in both places we need the fix in both places :)
/triage accepted
I think we have fixed this in , do you guys agree?
Change:
"labels.go", "legacy.go", "security_context.go", <ins> "security_context_others.go", "security_context_windows.go", </ins> ], importpath = "k8s.io/kubernetes/pkg/kubelet/kuberuntime", deps = [

Discussion:
Hello, What happened: When we apply PodSecurityPolicy with rule: WIndows containers are still blocked instead we put: the pod is still blocked with logs: What you expected to happen: the Container should start How to reproduce it (as minimally and precisely as possible): Create Psp disableling Root Users: Create a pod Windows with runAsUserName: Anything else we need to know?: Environment: Kubernetes version (use ): v1.18.3 Cloud provider or hardware configuration: OS (e.g: ): CentOS Linux 7 (Core) / windows server 2019 version 1809 Kernel (e.g. ): 3.10.0-514.10.2.el7.x86_64 Others: /sig windows
/sig windows
/assign I will test it and then post the test results
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
Change:
// RegisteredWatchers is a number of currently registered watchers splitted by resource. RegisteredWatchers = compbasemetrics.NewGaugeVec( &compbasemetrics.GaugeOpts{ <del> Name:           "apiserver_registered_watchers", Help:           "Number of currently registered watchers for a given resources", StabilityLevel: compbasemetrics.ALPHA, </del> <ins> Name:              "apiserver_registered_watchers", Help:              "Number of currently registered watchers for a given resources", StabilityLevel:    compbasemetrics.ALPHA, DeprecatedVersion: "1.23.0", </ins> }, []string{"group", "version", "kind"}, )

Discussion:
apiserverlongrunninggauge and apiserverregisterwatchers are kinda redundant . We discussed this in our SIG instrumentation meeting and while it's clear that apiserverlongrunninggauge, the name does not conform to instrumentation guidelines (it was created before those guidelines existed). What we want to do is deprecate both metrics and create a new one which actually does conform to our naming conventions probably something like . has volunteered to undertake this. /cc /sig instrumentation
/assign
GitHub didn't allow me to assign the following users: yan-lgtm. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. 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
/assign
/triage accepted
Hello! Have you still working on this issue? I am new to the community, and can I try it?
Hey I the deprecate in If you want to add the new metric, feel free to do so.
Can I add the new metric? If I can, can you give me some advice about the new metric? Thank you~
/assign
Change:
<ins> # Maintainers People responsible for ports of Kubernetes to different environments. CC at least one maintainer on relevant issues and PRs. ## OS Distributions * RedHat, Fedora: [Clayton Coleman](https://github.com/smarterclayton), [Derek Carr](https://github.com/derekwaynecarr), [Scott Collier](https://github.com/scollier) * CoreOS: [Kelsey Hightower](https://github.com/kelseyhightower) ## Providers / Environments * GCE: [Brendan Burns](https://github.com/brendandburns), [Joe Beda](https://github.com/jbeda), [Daniel Smith](https://github.com/lavalamp), [Tim Hockin](https://github.com/thockin) * Azure: [Jeff Mendoza](https://github.com/jeffmendoza) * Vsphere: [Pieter Noordhuis](https://github.com/pietern) * Rackspace: [Ryan Richard](https://github.com/doublerr) * Ovirt: [Federico Simoncelli](https://github.com/simon3z) * Local: [Derek Carr](https://github.com/derekwaynecarr) * Vagrant: [Derek Carr](https://github.com/derekwaynecarr) </ins>  No newline at end of file

Discussion:
We need to be very clear to users who are trying k8s out where they can turn for help. It's unfortunate when a user is having trouble with cloud provider XYZ and they ask for help on IRC and nobody answers.
Change:
WORKDIR /workspace RUN apt-get -o Acquire::Check-Valid-Until=false update && apt-get install -y rsync <ins> # file is used when uploading test artifacts to GCS. RUN apt-get install -y file </ins> # libapparmor1 is needed for docker-in-docker. <del> RUN apt-get install -y file libapparmor1 </del> <ins> RUN apt-get install -y libapparmor1 # netcat is used by integration test scripts. RUN apt-get install -y netcat-openbsd </ins> RUN mkdir -p /go/src/k8s.io/kubernetes RUN ln -s /go/src/k8s.io/kubernetes /workspace/kubernetes

Discussion:
It seems like an issue similar to the problem with API server. I'll extend the timeout in the similar fashion. cc
Extending timeout didn't help. It's probably something else.
cc
I think the logs make it pretty clear what went wrong: or does one of you have time to fix this?
The Jenkins docker test image probably needs netcat to be installed. Should be an easy fix; I can take this.
Thanks!
Ugh... neverending story.
This seems like a different problem.
Oh, I see, this actually is the same, but harder: I think the most obvious thing to do is to let kubectl select the port and report back?
reports more occurances. Netcat somehow is no longer installed?
those two are older builds, using , which didn't have netcat yet.
ah thanks!
are you still working on this? Would you like me to take it?
I'm not right now, sorry, feel free to take it.