jiebi/CodeConvo huggingface dataset:
Change:
if serviceNameVal != endpoints.Name { t.Errorf("Expected EndpointSlice to have %s label set to %s, got %s", discovery.LabelServiceName, endpoints.Name, serviceNameVal) } <ins> _, ok = epSlice.Annotations[corev1.LastAppliedConfigAnnotation] if ok { t.Errorf("Expected LastAppliedConfigAnnotation to be unset, got %s", epSlice.Annotations[corev1.LastAppliedConfigAnnotation]) } _, ok = epSlice.Annotations[corev1.EndpointsLastChangeTriggerTime] if ok { t.Errorf("Expected EndpointsLastChangeTriggerTime to be unset, got %s", epSlice.Annotations[corev1.EndpointsLastChangeTriggerTime]) } for annotation, val := range endpoints.Annotations { if annotation == corev1.EndpointsLastChangeTriggerTime || annotation == corev1.LastAppliedConfigAnnotation { continue } if epSlice.Annotations[annotation] != val { t.Errorf("Expected endpoint annotation %s to be mirrored correctly, got %s", annotation, epSlice.Annotations[annotation]) } } </ins> } for _, epSubset := range endpoints.Subsets {

Discussion:
If I modify a custom endpoint, the kubectl annotation is mirrored to the generated endpoint slice Since the kubect last-applied-configuration tracks the status of the object, it shouldn't be mirrored since it doesn't apply to the generated object a custom endpoint an update on any of the fields the generated endpoint slice annotations /sig network
ping
if we agree this is a bug, the fix is just and adding some tests of course :)
Thanks for catching this! Agree this is a bug that we should fix.
/triage accepted
/good-first-issue
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /good-first-issue 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
Hey, I'm on it!
Hi While I have made the update mentioned in the above comment, I feel a bit lost on where to add/update tests. I understand that I probably shouldn't raise a PR without trying to add a few tests for this issue. So could you possibly guide me to the correct files(s) I should be looking into where the annotations for updated EndpointSlices are being tested?
Hey I think the easiest place to add tests might be here: You could add another test case where the Endpoints object had this label and then ensure that label was not copied over to an EndpointSlice.
Alright I'll check out these tests. Thank you!
/assign
Change:
<ins> { "swaggerVersion": "1.2", "apiVersion": "", "basePath": "https://10.10.10.10:6443", "resourcePath": "/apis", "apis": [ { "path": "/apis", "description": "get available API versions", "operations": [ { "type": "void", "method": "GET", "summary": "get available API versions", "nickname": "getAPIVersions", "parameters": [], "produces": [ "application/json" ], "consumes": [ "application/json" ] } ] } ], "models": {} } </ins>  No newline at end of file

Discussion:
Loading returns Looking at the code is registered in the same way as which works fine. So not sure why is this broken.
Change:
import ( "context" <ins> "encoding/json" </ins> "fmt" "strings" "sync"

Discussion:
[ ] two weeks soak start date : testgrid-link [ ] two weeks soak end date : [ ] test promotion pr : kubernetes/kubernetes#? According to this APIsnoop query, there are still some remaining StatefulsetScale endpoints that are untested. with this query, you can filter untested endpoints by their category and eligibility for conformance. e.g below shows a query to find all conformance eligible untested, stable, apps endpoints sql-mode select distinct endpoint, right(useragent,73) AS useragent from testing.auditevent -- where useragent ilike '%subresource%' where endpoint ilike '%AppsV1NamespacedStatefulSetScale%' and releasedate::BIGINT round(((EXTRACT(EPOCH FROM NOW()))::numeric)1000,0) - and useragent like 'e2e%' order by endpoint limit 30; example endpoint | useragent -----------------------------------------|--------------------------------------------------------------------------- patchAppsV1NamespacedStatefulSetScale | [StatefulSetBasic] should have a working scale subresource [Conformance] readAppsV1NamespacedStatefulSetScale | [StatefulSetBasic] should have a working scale subresource [Conformance] replaceAppsV1NamespacedStatefulSetScale | [StatefulSetBasic] should have a working scale subresource [Conformance] (3 rows) If a test with these calls gets merged, test coverage will go up by 1 point* This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
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
Change:
} if oldRunning != config.Replicas { <del> if pods, err := config.Client.Pods(api.NamespaceAll).List(labels.Everything(), fields.Everything()); err == nil { </del> <ins> // List only pods from a given replication controller. if pods, err := config.Client.Pods(api.NamespaceAll).List(label, fields.Everything()); err == nil { </ins> for _, pod := range pods.Items { <del> Logf("Pod %st%st%st%s", pod.Namespace, pod.Name, pod.Spec.NodeName, pod.DeletionTimestamp) </del> <ins> Logf("Pod %st%st%st%s", pod.Name, pod.Spec.NodeName, pod.Status.Phase, pod.DeletionTimestamp) </ins> } } else { Logf("Can't list pod debug info: %v", err)

Discussion:
From time to time, different tests are failing with the error like this: Expected error: <*errors.errorString | 0xc20bcd3a30: { s: "Only 29 pods started out of 30", } Only 29 pods started out of 30 not to have occurred Few examples:
I didn't see this happening for ~month now. Closing this - feel free to reopen if you observe it again.
Change:
StorageClassName: &classGold, }) <ins> validClaimWithNonIntegerStorage := validClaim.DeepCopy() validClaimWithNonIntegerStorage.Spec.Resources.Requests[api.ResourceName(api.ResourceStorage)] = resource.MustParse("1001m") validClaimByStorageClassWithNonIntegerStorage := validClaimByStorageClass.DeepCopy() validClaimByStorageClassWithNonIntegerStorage.Spec.Resources.Requests[api.ResourceName(api.ResourceStorage)] = resource.MustParse("1001m") </ins> evaluator := NewPersistentVolumeClaimEvaluator(nil) testCases := map[string]struct { pvc   *api.PersistentVolumeClaim

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: When a pvc was specified with a quantity including the suffix : attempts to include that quantity in the resourcequota's storage resulted in the following error, which blocked all other updates to the resourcequota: What you expected to happen: Updates to all other quantities in the resourcequota should not have been blocked by the error above In general, as a suffix (milli) doesn't really make sense when used in the context of memory, and causes issues like the above. Would it be possible to deny the usage of this suffix at admission time for things like pvcs? (Our mitigation right now is to add a rule that does this in Open Policy Agent). How to reproduce it (as minimally and precisely as possible): Create a resourcequota object with limits on pvcs and the a storage type, e.g. Then create a PVC with the following spec: The resource quota controller should start producing the error log above. Anything else we need to know?: Environment: Kubernetes version (use ): v1.17.3 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 api-machinery
/remove-sig api-machinery /sig storage
i guess we should leave api-machinery! /sig api-machinery
/assign I think we should validate the value of field.
I've filed to address this issue.
looks like it is not easy to tighten the validation and that requires careful consideration xref:
/assign
"Updates to all other quantities in the resourcequota should not have been blocked by the error above" should be fixed separately
Opened to round storage requests up to the nearest byte in the quota evaluator.
Change:
# OS options for minions KUBE_OS_DISTRIBUTION="${KUBE_OS_DISTRIBUTION:-jessie}" <del> KUBE_MASTER_OS_DISTRIBUTION="${KUBE_OS_DISTRIBUTION}" KUBE_NODE_OS_DISTRIBUTION="${KUBE_OS_DISTRIBUTION}" </del> <ins> MASTER_OS_DISTRIBUTION="${KUBE_OS_DISTRIBUTION}" NODE_OS_DISTRIBUTION="${KUBE_OS_DISTRIBUTION}" </ins> KUBE_NODE_IMAGE="${KUBE_NODE_IMAGE:-}" COREOS_CHANNEL="${COREOS_CHANNEL:-alpha}" CONTAINER_RUNTIME="${KUBE_CONTAINER_RUNTIME:-docker}"

Discussion:
I think got confused between e.g. KUBEMASTEROSDISTRIBUTION and MASTEROS_DISTRIBUTION; it definitely doesn't match GCE. PR coming in once I've tested.
cc
Change:
} } <ins> func (cnc *CloudNodeController) UpdateCloudNode(_, newObj interface{}) { if _, ok := newObj.(*v1.Node); !ok { utilruntime.HandleError(fmt.Errorf("unexpected object type: %v", newObj)) return } cnc.AddCloudNode(newObj) } </ins> // This processes nodes that were added into the cluster, and cloud initialize them if appropriate func (cnc *CloudNodeController) AddCloudNode(obj interface{}) { node := obj.(*v1.Node)

Discussion:
Once cloud-controller-manager is started we should remove the taint. right?
/sig cluster-lifecycle
/area cloudprovider do you have anymore information on this? I can't reproduce this on existing nodes before the CCM was created or new nodes to a cluster.
i can recreate this using by setting along with a CLOUDCONFIG + CLOUDPROVIDER env vars
If you're running a local cluster then how are you running the CCM? The only way the taint gets removed is if the instance was found in the cloud provider and setup (labels, addresses, etc) OK. The code can be found
the local cluster is started within a openstack vm. so it's a one vm cluster. thanks for the pointer, will check it out
/assign
- So ... when i use local-up-cluster, the kubelet starts up before the cloud-controller-manager. So the shared informer that calls is never triggered. This patch seems to fix the issue. Note that RBAC stuff needed to be setup for as well for the to succeed.
Change:
if err != nil { return nil, err } <del> serviceTags, err := getServiceTags(service) if err != nil { return nil, err } </del> <ins> serviceTags := getServiceTags(service) </ins> var sourceAddressPrefixes []string if (sourceRanges == nil || servicehelpers.IsAllowAll(sourceRanges)) && len(serviceTags) == 0 { if !requiresInternalLoadBalancer(service) {

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: Azure cloud provider has a limited support for service tags by annotations: But according to , there are actually much more service tags than this list. Hence, errors would happen if the service tag is not included in the above list. What you expected to happen: Azure cloud provider should support all service tags from Azure. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /kind bug /sig azure /priority important-soon
/assign
Change:
}) podWorkers.UpdatePod(UpdatePodOptions{ UpdateType: kubetypes.SyncPodKill, <del> RunningPod: runningPod, </del> <ins> RunningPod: orphanedPod, </ins> }) <ins> drainAllWorkers(podWorkers) </ins> if podWorkers.IsPodKnownTerminated(pod.UID) == true { t.Errorf("podWorker state should not be terminated") } if podWorkers.IsPodKnownTerminated(terminatedPod.UID) == false { t.Errorf("podWorker state should be terminated") } <del> if podWorkers.IsPodKnownTerminated(runningPod.ID) == true { t.Errorf("podWorker state should not be marked terminated for a running pod") </del> <ins> if podWorkers.IsPodKnownTerminated(orphanedPod.ID) == false { t.Errorf("podWorker state should be terminated for orphaned pod") </ins> } }

Discussion:
pull-kubernetes-unit TestUpdatePodWithTerminatedPod 10/8 (when it was introduced in ) No response No response Running with shows immediate failures: /sig node
/cc
/assign I will try to fix this. At present, I found that adding before the status check will definitely trigger the error
Looks like it stopped flaking? Was this fixed? /triage accepted
If the test runs fast enough, it won't failed but it's not guaranteed. fixed in
It's still flaking
/assign
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
this started flaking more on 3/21 - adding to the milestone for investigation to make sure something didn't regress here
cc
/unassign /assign
Change:
// PreFilter invoked at the prefilter extension point. func (f *Fit) PreFilter(ctx context.Context, cycleState *framework.CycleState, pod *v1.Pod) (*framework.PreFilterResult, *framework.Status) { <ins> if !f.enableSidecarContainers && hasRestartableInitContainer(pod) { // Scheduler will calculate resources usage for a Pod containing // restartable init containers that will be equal or more than kubelet will // require to run the Pod. So there will be no overbooking. However, to // avoid the inconsistency in resource calculation between the scheduler // and the older (before v1.28) kubelet, make the Pod unschedulable. return nil, framework.NewStatus(framework.UnschedulableAndUnresolvable, "Pod has a restartable init container and the SidecarContainers feature is disabled") } </ins> cycleState.Write(preFilterStateKey, computePodResourceRequest(pod)) return nil, nil }

Discussion:
/kind feature /sig scheduling Filter will return for all nodes when is and is . This can be done is PreFilter. Executing this code in the filter will cause it to be repeated tens of times, with the worst-case scenario being repeated thousands of times. Maybe we should move this to PreFilter like:
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
Sounds reasonable to me :) I think you can go ahead and file a pr for this.
/assign
Sure.
Hi, If you don't mind, I can try to do this.
/assign
Change:
"fmt" "sync" <ins> "k8s.io/apimachinery/pkg/fields" "k8s.io/apimachinery/pkg/labels" "k8s.io/apiserver/pkg/registry/generic" "k8s.io/apiserver/pkg/storage" </ins> metainternalversion "k8s.io/apimachinery/pkg/apis/meta/internalversion" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/runtime"

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: tried to get listing of all componentstatuses using a labelSelector query selector. I am hitting the apiServer directly. GET /api/v1/componentstatuses What you expected to happen: GET /api/v1/componentstatuses with labelSelector should limit responses to only componentstatuses with the specified label How to reproduce it (as minimally and precisely as possible): run GET /api/v1/componentstatuses with and without a labelSelector against the apiServer. Anything else we need to know?: specifically my label selector is in the form . and i can confirm everything works as expected when i hit GET /api/v1/pods Environment: Kubernetes version (use ): Server Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.6+IKS", GitCommit:"", GitTreeState:"clean", BuildDate:"2019-05-09T13:26:51Z", GoVersion:"go1.11.5", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: IBM OS (e.g: ): Mac Kernel (e.g. ): Darwin Kernel Version 18.5.0 Install tools: Using javascript npm request to talk to api server Network plugin and version (if this is a network-related bug): Others:
/sig api-machinery
i assume its because you cant add a label to componentstatus, but they still shouldnt return if i specify a labelSelector
that's indeed a bug i presume. but what use-case makes you label-querying componentstatus?
we have a bot to periodically run a query that finds all known endpoints on the ApiServer. Then for each of the found endpoints, find all resources with our label defined. sort of an inventory tracking system.
in a similar vein, the endpoint doesnt seem to respect
/priority backlog /help
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /priority backlog /help 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 will take a look at this unless no objections
thank you, yours!
a PR for the ComponentStatus API, could you pls kindly take a look? I will look into the metrics API probably over the weekend. Thanks
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
/remove-lifecycle stale
Change:
<del> /* Copyright 2016 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package kubeadm import ( "bytes" "fmt" "io" "os" "os/exec" ) // Forked from test/e2e/framework because the e2e framework is quite bloated // for our purposes here, and modified to remove undesired logging. func RunCmd(command string, args ...string) (string, string, error) { var bout, berr bytes.Buffer cmd := exec.Command(command, args...) cmd.Stdout = io.MultiWriter(os.Stdout, &bout) cmd.Stderr = io.MultiWriter(os.Stderr, &berr) err := cmd.Run() stdout, stderr := bout.String(), berr.String() if err != nil { return "", "", fmt.Errorf("error running %s %v; got error %v, stdout %q, stderr %q", command, args, err, stdout, stderr) } return stdout, stderr, nil } </del>

Discussion:
go test ./cmd/kubeadm/... fails with: it appears to be following a "RunCmd" pattern used by e2e tests, but unit tests should not require built binaries
can work on this
has a long discussion as to why this is. These tests only get run when gets run, which will produce the needed binary and pass it in as arg. For more information, authored this and should be able to provide more details.
Yup, the target explicitly ignores these tests: and like said, runs this script as part of its target:
then the test should have build tags to exclude it from a regular run of the package
or up for fixing that?
I thought build tags only works on the OS level or if you it would ignore it completely? Wouldnt break the command as well?
I'd also tolerate skipping the test if the built binary doesn't exist
I think that is a great solution. I think in I had initially suggested something like that. If everyone is ok with that, I will go ahead and make that change.
Sounds good, make that change and we'll see how it turns out. I'd really want these tests start working, so +1
Change:
"github.com/ghodss/yaml" "github.com/spf13/cobra" <del> "k8s.io/apimachinery/pkg/api/errors" </del> "k8s.io/apimachinery/pkg/api/meta" <ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/apis/meta/v1/unstructured" </ins> "k8s.io/apimachinery/pkg/runtime" <ins> "k8s.io/client-go/dynamic" </ins> api "k8s.io/kubernetes/pkg/apis/core" "k8s.io/kubernetes/pkg/kubectl/apply/parse" "k8s.io/kubernetes/pkg/kubectl/apply/strategy"

Discussion:
/kind bug /sig cli /area kubectl Hello. This is my first interaction with the Kubernetes community, so please forgive me if i have left out any crucial details, or if, perhaps, this is PEBKAC after all! I am keen to have a working feature, as described in and I am running K8s v1.9.3 and realise that this feature is in alpha, but i thought i would ask anyway. We're not on v1.9.4 yet, but the changelog doesn't mention the feature. What you expected to happen: I have some services deployed to Kubernetes with YAML files, that has been working reliably. We always use to deploy things. When a service is already deployed, and i make a minor change in the config file, for example the service port, i expect to see that in the diff. Instead, gives no output and exits with a . How to reproduce it (as minimally and precisely as possible): Consider the file : I make sure that it is correctly running on the cluster: Great, looking good. Now, i change the value to use Docker image tag and save. Now, i run: The stderr/stdout output is empty, and the exit code is . Anything else we need to know?: Environment: Kubernetes version: Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.3", GitCommit:"", GitTreeState:"clean", BuildDate:"2018-02-09T21:50:44Z", GoVersion:"go1.9.4", Compiler:"gc", Platform:"darwin/amd64"} Server Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.3+coreos.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2018-02-10T01:42:55Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"}
I have this same issue - if I change, say, to in my , running returns empty. If I try tweaking the version I'm diffing (which I don't understand) - e.g. - then I see a bunch of differences, but not actually the change I was expecting in the number of replicas.
I'll take this. Sorry for the inconvenience.
Change:
GCE_IMAGES=${GCI_IMAGE} GCE_IMAGE_PROJECT=${GCI_IMAGE_PROJECT} GCE_ZONE=us-central1-f <del> GCE_PROJECT=kubernetes-jenkins </del> <ins> GCE_PROJECT=k8s-jkns-ci-node-e2e </ins> # user-data is the GCI cloud init config file. # gci-docker-version specifies docker version in GCI image. GCE_INSTANCE_METADATA="user-data<${GCI_CLOUD_INIT},gci-docker-version=${DOCKER_VERSION}"

Discussion:
I want to isolate these in their own project:
Right now just the CI jobs, but after we also need to do this for the PR jobs.