jiebi/CodeConvo huggingface dataset:
Change:
# Try to match the "git describe" output to a regex to try to extract # the "major" and "minor" versions and whether this is the exact tagged # version or whether the tree is between two tagged versions. <del> if [[ "${KUBE_GIT_VERSION}" =~ ^v([0-9]+).([0-9]+)([.-].*)?$ ]]; then </del> <ins> if [[ "${KUBE_GIT_VERSION}" =~ ^v([0-9]+).([0-9]+)(.[0-9]+)?([-].*)?$ ]]; then </ins> KUBE_GIT_MAJOR=${BASH_REMATCH[1]} KUBE_GIT_MINOR=${BASH_REMATCH[2]} <del> if [[ -n "${BASH_REMATCH[3]}" ]]; then </del> <ins> if [[ -n "${BASH_REMATCH[4]}" ]]; then </ins> KUBE_GIT_MINOR+="+" fi fi

Discussion:
This says 0.6+, which isn't really right, since 0.6+ indicates commits on top of the latest tag. But that isn't the case here. We are exactly on the latest tag...
Change:
const ( KubeletSubsystem             = "kubelet" <ins> NodeNameKey                  = "node_name" NodeLabelKey                 = "node" </ins> PodWorkerLatencyKey          = "pod_worker_latency_microseconds" PodStartLatencyKey           = "pod_start_latency_microseconds" CgroupManagerOperationsKey   = "cgroup_manager_latency_microseconds"

Discussion:
What would you like to be : It would be useful if the kubelet exported a metric that contained its own name as a label, for instance: . This name should be consistent with the output of . Why is this needed: This would allow us to join the kubelet metrics against metrics exported by kube-state-metrics. An example of this can be seen in We've arranged in our cluster for the labels to be set to the node's name, but this is controlled by Prometheus and depends on your scrape & relabelling config. As such, in general we can't rely on this to be the case - for instance, with the prometheus-operator the label is a IP:Port combo. /cc
/sig instrumentation
This metric as it is right now doesn’t conform to the instrumentation guidelines, so yes we should changes this as part of the metrics overhaul targeted for 1.14.
you mean to add a label in kubelet metrics ?
precisely.
/assign
Change:
jig := e2eservice.NewTestJig(cs, ns, serviceName) ginkgo.By("getting the state of the sctp module on nodes") <del> nodes, err := e2enode.GetReadySchedulableNodes(cs) </del> <ins> nodes, err := e2enode.GetBoundedReadySchedulableNodes(cs, 2) </ins> framework.ExpectNoError(err) sctpLoadedAtStart := CheckSCTPModuleLoadedOnNodes(f, nodes)

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI -- - At least 08/08 sequentially performs operations that take ~20s on average. Example: For a 5000 nodes test this causes a major timeout. excludes tests with tag which SCTP had until was merged. This is why there is a shift in red cells in the testgrid after 08/15. We will add a pattern excluding until this issue is resolved. /assign /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
/sig network
/assign
Change:
BlockVolume:                                 {Default: false, PreRelease: utilfeature.Alpha}, PVCProtection:                               {Default: false, PreRelease: utilfeature.Alpha}, ResourceLimitsPriorityFunction:              {Default: false, PreRelease: utilfeature.Alpha}, <ins> SupportIPVSProxyMode:                        {Default: false, PreRelease: utilfeature.Beta}, </ins> // inherited features from generic apiserver, relisted here to get a conflict if it is changed // unintentionally on either side:

Discussion:
There are some work to be done in the follow-up of , that is, help IPVS existing alpha. [x] GCE CI failures()[x] cross-node visit NodePort ()[x] hairpin issue ()[x] Using ipset doing snat and packet filtering and reduce iptables call().[x] automatically load kernel modules. (, )[x] creating e2e test suite for IPVS in upstream CI ().[x] ip cmd -netlink bind/unbind IP address to/from dummy device()[x] rsync to HEAD of iptables(, )[x] enable flush batch API()[x] Fix TODOs in codes ()[x] Bug report (, )[x] Default sync period()[x] IPV6 support(, and more...) /cc
/cc
ref ! It will generate annoy error info If unbind multi-ports on one service .
You're right. I think it's a nice finding. Can you fire a PR to fix it?
Sure, I'll make it soon.
I found it is treated as already bound if returned 2 in , but ref to the and of ip , it just means an error was reported by the kernel, such as "Operation not permitted". I prefer to use instead of command to manage ip address.
Actually, I have considered to use netlink before. I think what you said make sense, but can we discuss it in other thread? I mean, create a new issue and link it here? Thanks!
I opened a issue
on the subject :)
OOPS... I will fix that typo. Thanks
Wish to use ipset to replace KUBE-MARK-MASQ chain.
I find it's a reasonable suggestion and am trying to make it workable...
There are to ways to add IPVS CI job: , but doesn't support any kube-proxy config right now, so I had this pr , and also, need support it too, see this pr: kubernetes/kubernetes-anywhere build cluster. See this pr: kubernetes/test-infra The second way is much easier and faster, but I was told they gonna deprecated the , so in the long term, we still need and 's support. If anybody have better way or have some suggestion about this, please let me know, I'll be really appreciate, Thanks.
This one is done as both PRs are merged:
ACK!

/area ipvs
We are almost reaching the beta, except GCE CI failures, see The failure is the case that, visiting Cluster IP from Pod A, and the backend Pod B is in the same host with the Pod A. Pod A failed to get response from Pod B until timeout. I can reproduce the failures in my GCE cluster with kubent as network plugin, but it works fine in my local-up cluster and people has never reported the issue yet. and I are digging...
IPVS CI is green now.
Change:
} func (rh *realHistory) DeleteControllerRevision(revision *apps.ControllerRevision) error { <del> return rh.client.Apps().ControllerRevisions(revision.Namespace).Delete(revision.Name, nil) </del> <ins> return rh.client.AppsV1beta1().ControllerRevisions(revision.Namespace).Delete(revision.Name, nil) </ins> } func (rh *realHistory) AdoptControllerRevision(parent metav1.Object, parentKind schema.GroupVersionKind, revision *apps.ControllerRevision) (*apps.ControllerRevision, error) {

Discussion:
The statefulset controller and controller history implementations should be migrated off of the Apps client (deprecated) and onto the AppsV1BetaClient. Currently there is no user facing issue caused by the use of the deprecated resource, but we should maintain good code hygiene.
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 .
/assign kow3ns
/assign kow3ns
/cc
/assign
Change:
- get - list - watch <ins> - apiGroups: ["apps"] resources: - deployments resourceNames: - metrics-server-v0.6.3 verbs: - get - patch - nonResourceURLs: - /metrics verbs: - get </ins> --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding

Discussion:
broke rbac permissions for pod nanny and it's now not able to scale up with number of nodes. We see in kube-apiserver logs: I tried to fix naively the problem by but it's incomplete as we still see: which means that we are missing more permissions (e.g. get deployments). Sample test run where we see it: At this stage I gave up. /sig instrumentation /cc podnany has access to required data to scale up metrics-server Create empty cluster, watch kube-apiserver logs for podnanny user agent Also you can test e2e by calling '/test pull-kubernetes-e2e-gce-100-performance' and seeing if metrics-server ever resizes. No response <detailsmaster </details<detailsgce </details<details</details<details</details<details</details<details</details
We incorrectly removed RBAC required by metrics-server-nanny. Fixing this should require adding it back. List of permission that should work I would also recommend 2 followups for metrics server project: Make k/k metrics server configuration based on metrics-server project autoscaling configuration. This would require making the autoscaling part of release, releasing the config for v0.6.3, updating k/k repo with it and documenting it as instructions for updating metrics server config in k/k repo. Add tests no errors in nanny used in metrics server autoscaling configuration.
/assign
cc
ok, let me take a look
yeah, I think We dropped some resources which are needed. Let me try to add them back
/triage accepted /assign
Change:
} else if last == current { same++ } else if current < last { <del> Failf("Controller %s: Number of submitted pods dropped from %d to %d", last, current) </del> <ins> Failf("Controller %s: Number of submitted pods dropped from %d to %d", name, last, current) </ins> } if same >= failCount {

Discussion:
Currently the density tests are ok if all the pods come up eventually. We should verify there are no failure/error events while the pods are coming up. This could indicate issues dealing with the number of pods and should be investigated.
has been merged, and there's already an issue filed for followup actions, so I think we can close this.
Change:
legacyregistry.MustRegister(watchCacheCapacityDecreaseTotal) legacyregistry.MustRegister(WatchCacheCapacity) legacyregistry.MustRegister(WatchCacheInitializations) <ins> legacyregistry.MustRegister(WatchCacheReadWait) </ins> }) }

Discussion:
Part of From For now posted as a "help wanted" issue, however if we cannot hit the timeline for 1.30 code freeze () I would take it over so we don't miss. Still issue is simple enough that it can be quickly implemented. Implementation tips: Add a metric around waitUnitlFreshAndBlock method Metric should be a histogram with latency buckets similar to api latency Metric should have label for resource version. A way to monitor watch cache impact on request latency.
/sig api-machinery /triage accepted /help
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /sig api-machinery /triage accepted /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
Change:
} // remove old KMS provider <ins> // verifyIfKMSTransformersSwapped sometimes passes even before the changes in the encryption config file are observed. // this causes the metrics tests to fail, which validate two config changes. // this may happen when an existing KMS provider is already running (e.g., new-kms-provider-for-secrets in this case). // to ensure that the changes are observed, we added one more provider (kms-provider-to-encrypt-all) and are validating it in verifyIfKMSTransformersSwapped. </ins> encryptionConfigWithoutOldProvider := ` kind: EncryptionConfiguration apiVersion: apiserver.config.k8s.io/v1

Discussion:
transformation expandless | 14m1s Failed; === RUN TestEncryptionConfigHotReload TestEncryptionConfigHotReload When I see this flake, 10-09 is the first one.(But the job history in the testgrid only started from 10-03) some PR that may be related: /sig auth /cc
/cc
/triage accepted
/cc failed two times in recent 3 runs:
/reopen as of this is still .
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:
t.Errorf("got am %v, expected access mode of ReadOnlyMany", ams[0]) } } <ins> func TestTranslateInTreePVToCSIVolIDFmt(t *testing.T) { g := NewGCEPersistentDiskCSITranslator() pdName := "pd-name" tests := []struct { desc               string topologyLabelKey   string topologyLabelValue string wantVolId          string }{ { desc:               "beta topology key zonal", topologyLabelKey:   v1.LabelFailureDomainBetaZone, topologyLabelValue: "us-east1-a", wantVolId:          "projects/UNSPECIFIED/zones/us-east1-a/disks/pd-name", }, { desc:               "v1 topology key zonal", topologyLabelKey:   v1.LabelTopologyZone, topologyLabelValue: "us-east1-a", wantVolId:          "projects/UNSPECIFIED/zones/us-east1-a/disks/pd-name", }, { desc:               "beta topology key regional", topologyLabelKey:   v1.LabelFailureDomainBetaZone, topologyLabelValue: "us-central1-a__us-central1-c", wantVolId:          "projects/UNSPECIFIED/regions/us-central1/disks/pd-name", }, { desc:               "v1 topology key regional", topologyLabelKey:   v1.LabelTopologyZone, topologyLabelValue: "us-central1-a__us-central1-c", wantVolId:          "projects/UNSPECIFIED/regions/us-central1/disks/pd-name", }, } for _, tc := range tests { t.Run(tc.desc, func(t *testing.T) { translatedPV, err := g.TranslateInTreePVToCSI(&v1.PersistentVolume{ ObjectMeta: metav1.ObjectMeta{ Labels: map[string]string{tc.topologyLabelKey: tc.topologyLabelValue}, }, Spec: v1.PersistentVolumeSpec{ PersistentVolumeSource: v1.PersistentVolumeSource{ GCEPersistentDisk: &v1.GCEPersistentDiskVolumeSource{ PDName: pdName, }, }, }, }) if err != nil { t.Errorf("got error translating in-tree PV to CSI: %v", err) } if got := translatedPV.Spec.PersistentVolumeSource.CSI.VolumeHandle; got != tc.wantVolId { t.Errorf("got translated volume handle: %q, want %q", got, tc.wantVolId) } }) } } </ins>

Discussion:
Was just perusing the code and looks like we translate regional disks into the "zonal volume ID fmt", and there doesn't seem to be any tests for regional disks running so we should confirm that this works and fix it if it doesn't /assign /cc
/sig storage
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
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
/lifecycle frozen /assign
/assign
Change:
// Handles returns true if the object count evaluator needs to track this attributes. func (o *objectCountEvaluator) Handles(a admission.Attributes) bool { operation := a.GetOperation() <del> return operation == admission.Create || (o.allowCreateOnUpdate && operation == admission.Update) </del> <ins> return operation == admission.Create </ins> } // Matches returns true if the evaluator matches the specified quota with the provided input item

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug /sig api-machinery What happened: The that we use to make a create validation function is given admission.Update as its operation field. In the create validation we then use the provided operation (admission.Update) , when we call the admission controllers, even though a new object is being created. A similar thing is happening with the mutating admission. This means that when an objects is created on update, the admission controllers will see this as an update request. Meaning there could be an objects in storage which never passed create admission validation and were never modified by create admission mutation. I think this is a bug. What you expected to happen: Admission controllers would handle a create-on-update exactly the same as a normal create
I think the solution to this would be to separate the static admission attributes into one for the create validation and one for the update validation. Also, the function which performs the mutating admission needs to determine whether or not it is an actual update or if the old object doesn't exist (probably by checking uid) and then call the mutating admission correctly based on which operation is being performed.
/assign I might be interested to give it a try.
How to reproduce this bug?
Instead of a reproduceable BUG, I think it's like a mismatch of conceptual design and actual implementation. If a resource allows create-on-update in its strategy e.g.: Then admission plugins would receive operations (CREATE/UPDATE) on UPDATE requests. Some problems might happen the admission plugin is written without considering the circumstances that admitting a UPDATE operation might result a object creation into the storage. Risky and confusing, WDYT?
With the current build in admission controllers, I'm not sure if there are any bugs. Maybe something with resource quota? The real problem is that there is no way to know which webhook authors will have a dependency on seeing a "create" operation for every object put into storage. If a webhook relies on creates to implement its custom logic (which should be allowed), then objects created with an update would currently be missed by the webhook.
Change:
Resource:     fmt.Sprintf("spn:%s", apiserverID), Type:         tokenType, }, <ins> environment: environment, </ins> clientID:    clientID, tenantID:    tenantID, apiserverID: 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:
NodeName:                 node.Name, } cleanup, err := utils.CreateFromManifests(config.Framework, driverNamespace, func(item interface{}) error { <del> if err := utils.PatchCSIDeployment(config.Framework, o, item); err != nil { return err } // Remove csi-external-health-monitor-agent and // csi-external-health-monitor-controller // containers. They are not needed for any of the // tests and in practice apparently caused enough // overhead that even unrelated tests timed out. For // example, in the pull-kubernetes-e2e-kind test, 43 // out of 5771 tests failed, including tests from // sig-node, sig-cli, sig-api-machinery, sig-network. switch item := item.(type) { case *appsv1.StatefulSet: var containers []v1.Container for _, container := range item.Spec.Template.Spec.Containers { switch container.Name { case "csi-external-health-monitor-agent", "csi-external-health-monitor-controller": // Remove these containers. default: // Keep the others. containers = append(containers, container) } } item.Spec.Template.Spec.Containers = containers } return nil </del> <ins> return utils.PatchCSIDeployment(config.Framework, o, item) </ins> }, h.manifests...) if err != nil {

Discussion:
newer hostpath deployments but removed the csi-external-health-monitor-agent because it seemed to cause overhead without being needed for the tests. We should re-enable it and check whether that really causes tests to fail because of the extra load.
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
/sig storage /area test
Change:
case PodTerminated: // Older API versions did not contain enough info to map to PodSucceeded *out = newer.PodFailed <ins> case PodSucceeded: *out = newer.PodSucceeded </ins> case PodUnknown: *out = newer.PodUnknown default:

Discussion:
This happened to me several times while debugging an e2e test. My branch was based on commit and had changes only to
docker inspect says the container exited 0
kubelet HTTP says the pod exited 0:
kubectl says it failed:
Events does not show any success or failure even. Seems like it doesn't show that for any pods, succeeded or failed.
Apiserver sees the exit code 0:
The problem might be related to there being zero values for startedAt or finishedAt. The command may have exited so quickly that docker could not record these values, and we may be somehow treating unset values for these as failure.
adding sleep 5 to my command causes docker to set the startedAt and finishedAt to reasonable values, but the pod still shows up as failed. Note that I use a different pod name each time I try to avoid that sort of obvious mistake.
So, the apiserver v1beta1 message knows that it is terminated with exit code 0. But, both kubectl and my go code in my go e2e test thing this means failed. I'm starting to suspect the conversion code.
The problem is that a v1beta1 pod can never see that a pod is failed or succeded. So it defaults to PodFailed. Grrrrrrraaaaahhhhhh!
In line 184 of
This is going to be confusing for people unless we change this.
I believe the latest fix for PodStatus should resolve the issue here. I will double confirm it before closing it.

We should do this after 1.7. xref /sig testing cc
Is this the task that needs completed - Add support to Ubuntu e2e test-infra
That is different, this is about running GPU tests as part of PR pre-submit tests. Right now we skip them because they are "[Serial]".
I can work on this issue in conjunction with . Is this issue just a matter of adding GPU tests to a different suite or are there more subtasks?
Anymore progress on this?
Thanks for the reminder. I just submitted an internal request for quota to run these tests. Once that is approved, I will add a PR in test-infra to run GPU tests on all k/k PRs. It will be non-blocking initially and then become blocking later on.
Awesome, thanks!
Change:
"time" "github.com/google/go-cmp/cmp" <ins> "github.com/stretchr/testify/require" </ins> "sigs.k8s.io/yaml" appsv1 "k8s.io/api/apps/v1"

Discussion:
Sending a patch built from a typed client to SSA will force a write to etcd (and bump resourceVersion) since creationTimestamp is serialized to null. This is a follow-up of which doesn't solve the issue properly. Sending a no-op SSA request with creationTimestamp to null shouldn't do anything Kubectl apply an object with creationTimestamp null twice and see that it updates the object. Probably something like this would cause it:
/sig api-machinery /wg api-expression /triage accepted /assign /priority important-soon