jiebi/CodeConvo huggingface dataset:
Change:
import ( "sync" <del> "k8s.io/component-base/metrics" </del> "k8s.io/component-base/metrics/legacyregistry" <del> ) const kubeProxySubsystem = "kubeproxy" var ( SyncProxyRulesLatency = metrics.NewHistogram( &metrics.HistogramOpts{ Subsystem:      kubeProxySubsystem, Name:           "sync_proxy_rules_duration_seconds", Help:           "SyncProxyRules latency in seconds", Buckets:        metrics.ExponentialBuckets(0.001, 2, 15), StabilityLevel: metrics.ALPHA, }, ) // SyncProxyRulesLastTimestamp is the timestamp proxy rules were last // successfully synced. SyncProxyRulesLastTimestamp = metrics.NewGauge( &metrics.GaugeOpts{ Subsystem:      kubeProxySubsystem, Name:           "sync_proxy_rules_last_timestamp_seconds", Help:           "The last time proxy rules were successfully synced", StabilityLevel: metrics.ALPHA, }, ) </del> <ins> "k8s.io/kubernetes/pkg/proxy/metrics" </ins> ) var registerMetricsOnce sync.Once <ins> // RegisterMetrics registers kube-proxy metrics for Windows modes. </ins> func RegisterMetrics() { registerMetricsOnce.Do(func() { <del> legacyregistry.MustRegister(SyncProxyRulesLatency) legacyregistry.MustRegister(SyncProxyRulesLastTimestamp) </del> <ins> legacyregistry.MustRegister(metrics.SyncProxyRulesLatency) legacyregistry.MustRegister(metrics.SyncProxyRulesLastTimestamp) legacyregistry.MustRegister(metrics.EndpointChangesPending) legacyregistry.MustRegister(metrics.EndpointChangesTotal) legacyregistry.MustRegister(metrics.ServiceChangesPending) legacyregistry.MustRegister(metrics.ServiceChangesTotal) legacyregistry.MustRegister(metrics.SyncProxyRulesLastQueuedTimestamp) </ins> }) }

Discussion:
function on is not being used, and kproxy metrics are not showing on endpoint. See kube-proxy related metrics. Access kube-proxy on and search for kube-proxy specific metrics. No response <detailsKube-proxy build from master </details<details</details<details</details<details</details<details</details<details</details
/sig windows
/triage accepted /priority important-soon
/milestone v1.24
Change:
fi # Install docker <del> if ! hash docker 2>/dev/null; then # RHEL platforms should always install from RHEL repository # This will install the latest supported stable docker platform on RHEL if [ $OS_RHEL -eq 0 ]; then sudo yum install -y docker-latest sudo groupadd docker sudo systemctl enable docker-latest.service sudo systemctl start docker-latest.service else curl -fsSL https://get.docker.com/ | sh sudo service docker start sudo systemctl enable docker.service fi </del> <ins> if ! hash containerd 2>/dev/null; then echo "Please install containerd, see the getting started guide here: https://github.com/containerd/containerd/blob/main/docs/getting-started.md" echo "For a docker CLI replacement, we suggest nerdctl: https://github.com/containerd/nerdctl#install" </ins> fi # Allow jenkins access to docker

Discussion:
in e2enode test curls and directly pipes to shell: The issue is that this may present a supply chain security risk, as we are directly executing the script from I would instead expect one of the following: host includes docker already via it's OS image script is checked into this repo and version controlled script is at least verified to be unchanged via hash Running anything from - , such as: No response All GCP (kind of) N/A N/A N/A N/A
/sig node
that's some pretty old bash, I don't think we're actually using this in CI, probably that codepath can just be dropped, but up to the SIG node folks.
/triage accepted /priority backlog /assign
the script is being referred from the docs: I think the safest bet is to simply remove the docker installation part.
Change:
fs.StringVar(&s.ServiceAccountSigningKeyFile, "service-account-signing-key-file", s.ServiceAccountSigningKeyFile, ""+ "Path to the file that contains the current private key of the service account token issuer. The issuer will sign issued ID tokens with this private key. (Requires the 'TokenRequest' feature gate.)") }

Discussion:
After merged, we should also show deprecated kube-apiserver flags.
/sig api-machinery
Change:
} fmt.Fprintln(out, string(marshalled)) case "json": <del> marshalled, err := json.Marshal(&versionInfo) </del> <ins> marshalled, err := json.MarshalIndent(&versionInfo, "", "  ") </ins> if err != nil { return err }

Discussion:
I was confused by the that looks like more as machine readable rather than as human readable. I feel that UX could be better if it will be written in multiple lines and without curly braces/quotes:
Agreed on this one, we should pretty-print this output.
I would like to change that tomorrow if you are not working on it.
I'm not working on it, so feel free to provide a PR. But I wouldn't do anything until we get approval from
cc don't some of the tests rely on this output?
They probably do. There should be a option or something that we can use in test infra.
please have a look at: and related issue: The above is approved and had an lgtm labeled, but removed by the bot because of testing flake.
I think we can close this ?
I don't see that it was fixed. Does the output of was improved?
kubectl now has a option which lets you select between YAML or JSON. However, I believe this is reversed. The more human-friendly output is hidden behind an option and the machine-friendly output is the default. I believe it should be the opposite.
Change:
} // errorBadPodsStates create error message of basic info of bad pods for debugging. <del> func errorBadPodsStates(badPods []api.Pod, desiredPods int, ns string, timeout time.Duration) string { errStr := fmt.Sprintf("%d / %d pods in namespace %q are NOT in the desired state in %vn", len(badPods), desiredPods, ns, timeout) </del> <ins> func errorBadPodsStates(badPods []api.Pod, desiredPods int, ns, desiredState string, timeout time.Duration) string { errStr := fmt.Sprintf("%d / %d pods in namespace %q are NOT in %s state in %vn", len(badPods), desiredPods, ns, desiredState, timeout) </ins> // Pirnt bad pods info only if there are fewer than 10 bad pods if len(badPods) > 10 { return errStr + "There are too many bad pods. Please check log for details."

Discussion:
https://k8s- Failed: BeforeSuite {Kubernetes e2e suite} Previous issues for this test:
Change:
}) /* <del> Release : v1.9 Testname: Host path, volume mode default Description: Create a Pod with host volume mounted. The volume mounted MUST be a directory with permissions mode -rwxrwxrwx and that is has the sticky bit (mode flag t) set. </del> <ins> Host path, volume mode default Create a Pod with host volume mounted. The volume mounted MUST be a directory with permissions mode -rwxrwxrwx and that is has the sticky bit (mode flag t) set. </ins> This test is marked LinuxOnly since Windows does not support setting the sticky bit (mode flag t). */ <del> framework.ConformanceIt("should give a volume the correct mode [LinuxOnly] [NodeConformance]", func() { </del> <ins> ginkgo.It("should give a volume the correct mode [LinuxOnly] [NodeConformance]", func() { </ins> source := &v1.HostPathVolumeSource{ Path: "/tmp", }

Discussion:
A long time ago we removed conformance for a similar HostPath test in: At that time a policy was : Current Policy : Note that the conformance tag was in . Which was basically bulk tagging a bunch of tests as conformance tests, So not really specifying a specific reason on why it is a behavior that should be tested. Also note that this is and something that does not work on Windows. And we are expecting the "sticky bit" to be set ... Is this really what we want in a conformance test? So bottom line, does it really need to be a conformance test?
/sig architecture /area conformance
LinuxOnly things should still be in conformance, as I understand it (and hope?!?). Agree with the other reasons.
Yes, you can have LinuxOnly in conformance, that's not the issue here. The issue is that it does violate the current policy, and looks like it was to conformance prior to that but probably should have been removed. So it seems reasonable to me.
Change:
var ( versionFlag = Version(versionFlagName, VersionFalse, "Print version information and quit") <ins> programName = "Kubernetes" </ins> ) // AddFlags registers this package's flags on arbitrary FlagSets, such that they point to the

Discussion:
When using the package, one can easily add a flag to a CLI tool. However, the output of invocation with is hard-coded to . As such, the package is not very usable in non-Kubernetes projects. /wg component-standard /assign
Change:
ginkgo.By("Trying to schedule Pod with nonempty NodeSelector.") podName := "restricted-pod" <del> framework.WaitForStableCluster(cs, masterNodes) </del> <ins> WaitForStableCluster(cs, masterNodes) </ins> conf := pausePodConfig{ Name: podName,

Discussion:
What would you like to be : is used at the beginning of some e2e scheduler tests to wait until the cluster is in a stable state. It currently waits until all existing pods are scheduled, but it should also wait until pods from previous tests are actually deleted. We can do this by assuming that pods should exist only in the kube-system namespace, and so WaitForStableCluster should wait until there are no pods in any other namespace. Why is this needed: /help /sig testing /sig scheduling
/milestone v1.17 /priority critical-urgent
/cc
I'll take this one, can't figure out how to get ci bot to assign to me...
/assign
/remove-help
Change:
attempt=$(($attempt+1)) sleep 1 done <ins> # Mount the master PD as early as possible echo "/dev/xvdb /mnt/master-pd ext4 noatime 0 0" >> /etc/fstab </ins> } fix-apt-sources() {

Discussion:
We currently remount the master PD every boot, as part of the GCE instance-boot script. I'm wondering if this is safe: if we have services that start concurrently, should we put the master-pd into /etc/fstab instead? I think we'll have to do this on AWS, in any case.
any thoughts on whether we should also do this for GCE?
too for I don't pretend to understand the startup dance of the various master components like etcd, kube*, etc., though it does seem reasonable to add it to /fstab to me. I'm also interested in getting us to something other than containervm like trusty and friends and getting rid of as much of the instance-boot dance as possible.
helped build the master pd dance and may have some input as well.
Actually did the initial work there. The main problem is that GCE PDs (I don't know if this is different in AWS?) are unformatted, so at least on cluster creation, we have to come up, format and mount them. I don't think we can easily move it inside until after first boot.
If I understand correctly, new EBS volumes also start unformatted, and it looks as though something like would still let us automatically format the disk on initial startup because the fstab entry wouldn't exist on the first boot.
Although if there is some sort of race among services starting up on boot, we'll still hit that problem on the initial boot, and on the initial boot of each recreated master VM if we tear it down and bring it back up with the same disk/IP for upgrades.
ping - someone who understands this issue (not me) please confirm doing this for GCE is a 1.2 blocker, or else move it to next-candidate or remove milestone tag completely and demote to P2.
I wouldn't consider it a 1.2 blocker to do this for GCE -
I don't either. I'd actually rather not touch this path right now; we've lived with it this way for a while.
OK well we can see how it goes on AWS :-)
/sig cluster-lifecycle
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. Prevent issues from auto-closing with an comment.

If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/close
Change:
) longRunningRequestGauge = compbasemetrics.NewGaugeVec( &compbasemetrics.GaugeOpts{ <del> Name:           "apiserver_longrunning_gauge", Help:           "Gauge of all active long-running apiserver requests broken out by verb, group, version, resource, scope and component. Not all requests are tracked this way.", StabilityLevel: compbasemetrics.ALPHA, </del> <ins> Name:              "apiserver_longrunning_gauge", Help:              "Gauge of all active long-running apiserver requests broken out by verb, group, version, resource, scope and component. Not all requests are tracked this way.", StabilityLevel:    compbasemetrics.ALPHA, DeprecatedVersion: "1.23.0", </ins> }, []string{"verb", "group", "version", "resource", "subresource", "scope", "component"}, )

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:
VisitPodConfigmapNames(pod, func(name string) bool { extractedNames.Insert(name) return true <del> }) </del> <ins> }, AllContainers) </ins> // expectedPaths holds struct paths to fields with "ConfigMap" in the name that are references to ConfigMap API objects. // every path here should be represented as an example in the Pod stub above, with the ConfigMap name set to the path.

Discussion:
Fully described in , and will visit these fields for all containers, regardless of whether they're hidden behind a feature gate (e.g. ). This is usually correct, these methods are often used to drop fields and in this case should visit all containers that are persisted regardless of whether they're disabled, but the callers of these methods should signal that explicitly rather than relying on the implicit behavior. /cc /priority important-longterm /kind bug /sig node
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : Fully described in , and will visit these fields for all containers, regardless of whether they're hidden behind a feature gate (e.g. ). /priority important/long-term /kind bug /sig node 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
are you interested in taking this one, too?
VisitPodSecretNames and VisitPodConfigmapNames already specify AllContainers for VisitContainers Can you let me know what else needs to be done?
Callers should specify whether they want to visit all containers or not. There are valid reasons for each, so we shouldn't assume the desired behavior, even if 100% of the current users want to visit all containers. Jordan's original comment in has some examples of current uses. I don't think this needs to be as configurable as , so my naive first attempt to implement this would probably just be a new to and
Change:
// record wall time endTime := time.Now() <del> if duration := endTime.Sub(startTime); duration < time.Second { </del> <ins> // tolerate a 1% clock change because these things happen if duration := endTime.Sub(startTime); duration < (time.Second * 99 / 100) { </ins> // We shouldn't be able to get 100 tokens out of the bucket in less than 1 second of wall clock time, no matter what t.Errorf("Expected it to take at least 1 second to get 100 tokens, took %v", duration) } else {

Discussion:
https://k8s- Failed: TestMultithreadedThrottling {flowcontrol}
Got 4 failures recently.
Change:
return nil, nil, nil } <ins> func updateObject(f *TestFieldManager, fieldManagerName string, object []byte) error { obj := &unstructured.Unstructured{Object: map[string]interface{}{}} if err := yaml.Unmarshal(object, &obj.Object); err != nil { return fmt.Errorf("error decoding YAML: %v", err) } if err := f.Update(obj, fieldManagerName); err != nil { return fmt.Errorf("failed to update object: %v", err) } return nil } func applyObject(f *TestFieldManager, fieldManagerName string, object []byte) error { obj := &unstructured.Unstructured{Object: map[string]interface{}{}} if err := yaml.Unmarshal(object, &obj.Object); err != nil { return fmt.Errorf("error decoding YAML: %v", err) } if err := f.Apply(obj, fieldManagerName, true); err != nil { return fmt.Errorf("failed to apply object: %v", err) } return nil } </ins> // Ensures that if ManagedFieldsUpdater gets a nil value from its nested manager // chain (meaning the operation was a no-op), then the ManagedFieldsUpdater // itself will return a copy of the input live object, with its managed fields

Discussion:
I created an object with , and later I updated the same object with another . After that I looked at the object's managedFields, and saw nothing about the update. Here is what I got after the second apply: I expected managedFields to get updated by the second . No response <details</details<detailsnone </details<details</details<detailskubeadm </details<detailsdocker </details<details</details
/cc
I also saw the timestamp not updated when I updated using client-go and typed client stubs, Apply method, patch type .
/assign /triage accepted
/cc
The is not updated because you are not changing the structure of the object (adding or removing fields). According to , the time is updated if and only if the fieldSet is changed. It does not take into account the value of fields. One option would be to not compare the fieldSets but directly compare the liveObject & newObject for differences and update the field accordingly. Is it the desired behavior to update the time of when only the value is updated?
Yes! Look at the first paragraph of .
is that documentation correct? Is this what we intended?
I don't see any mention to the timestamp in that first paragraph. We've clarified recently the exact semantic of the timestamp, as defined here: I think you've identified the wrong code if you want to go ahead and fix it, go ahead, I'll happily review!
Change:
# REVISION provides a version number for this image and all it's bundled # artifacts. It should start at zero for each LATEST_ETCD_VERSION and increment # for each revision of this image at that etcd version. <del> REVISION?=3 </del> <ins> REVISION?=4 </ins> # IMAGE_TAG Uniquely identifies k8s.gcr.io/etcd docker image with a tag of the form "<etcd-version>-<revision>". IMAGE_TAG=$(LATEST_ETCD_VERSION)-$(REVISION)

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --- post-kubernetes-push-image-etcd n/a 2020-08-11 Started failing when merged No new versions of etcd are getting pushed until this gets fixed, when means the following PRs haven't fully taken effect: /sig api-machinery /priority critical-urgent /milestone v1.23 /assign FYI
/sig release /area release-eng
I've opened to rollback the offending commit, would like to keep this open until we can figure out the correct fix-forward
/triage accepted
was triggered by the merge of , which pushed So that's now current / includes whatever PRs linked in the description may have tried to change (excluding )
does this need promotion at all or are we good with the existing image?
/remove-priority critical-urgent /priority important-soon The job is back to passing
Recent updates are related to Debian base image update and golang upgrade. Nice to get a promotion. Good enough to use .
Yeah, looks like that the env in the build job does not search for docker CLI plugins in the path, which makes it unavailable during the run.
I think we have to set the environment variable like we already do in other build jobs, proposing the fix in
Latest test run is green:
Change:
if !util.IsQualifiedName(strings.ToLower(k)) { allErrs = append(allErrs, errs.NewFieldInvalid(field, k, qualifiedNameErrorMsg)) } <del> if !util.IsValidAnnotationValue(v) { allErrs = append(allErrs, errs.NewFieldInvalid(field, k, "")) } </del> totalSize += (int64)(len(k)) + (int64)(len(v)) } if totalSize > (int64)(totalAnnotationSizeLimitB) { <del> allErrs = append(allErrs, errs.NewFieldTooLong("annotations", "")) </del> <ins> allErrs = append(allErrs, errs.NewFieldTooLong(field, "", totalAnnotationSizeLimitB)) </ins> } return allErrs }

Discussion:
For example, creating a service with id 'redis-master10012345678999' fails and the returned message contains the following: "message": "service "redis-master10012345678999" is invalid: name: invalid value 'redis-master10012345678999' 'invalid value' is too general, users should understand exactly what is wrong with the input. for example - is it too long? does it contain characters that are not allowed?
Agree - there is now a place to stick the explanations in the ValidationError - we need to link together validation logic and that string. , abonas wrote:
I checked and it seems there are only two errors that do not have detailed explanation. I'll send a PR to fix this.
This is one:
Thanks for the pointer Brian! I'll send second PR to fix this one.
Still second PR to be sent.
Change:
<del> # See the OWNERS docs at https://go.k8s.io/owners reviewers: - andrewsykim - dims - msau42 approvers: - andrewsykim - dims - msau42 </del>

Discussion:
In 1.30, the PersistentVolumeLabel admission plugin blocks creation of in-tree AzureDisk and vSphere PVs: The reason is that the cloud provider was removed (), but the admission plugin still calls GetCloudProvider there, which fails: The PV should be admitted + created. Enable PersistentVolumeLabel admission plugin. For example, when running local-up- Create AzureDisk PV on any 1.30 cluster, you don't need Azure cloud: /sig storage /priority important-soon <detailsToday's master </details<detailsAzure </detailsNo response <detailslocal-up- </details<details</details<details</details
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
I am fixing the worst bug in and I plan to backport it to 1.30. However, we should consider removing the whole PersistentVolumeLabel admission plugin. Most of the cloud providers were removed, only GCE remains and IMO even that one will be removed sooner or later. The admission plugin has no way to get volume zone + region and is therefore useless. The admission said (in 1.26, where we had all in-tree cloud providers): Such webhook never materialized for AWS, Azure nor vSphere and I am not aware of any plans for GCE.
It did materialize in So removing it from k/k is the best way forward.