jiebi/CodeConvo huggingface dataset:
Change:
"k8s.io/apimachinery/pkg/api/resource" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/types" <ins> "k8s.io/apimachinery/pkg/util/errors" </ins> "k8s.io/apimachinery/pkg/util/sets" "k8s.io/apimachinery/pkg/util/wait" "k8s.io/kubernetes/pkg/scheduler/algorithm"

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: What happened: A failed Prioritize Map Function caused Scheduler break down. What you expected to happen: Pod remains Pending and describe pod will show errors of failed functions. How to reproduce it (as minimally and precisely as possible): It happens when some prioritize's map functions return with error. Anything else we need to know?: Environment: Kubernetes version (use ): v1.9.6 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
As shown above, if priorityConfigs[i].Map(pod, meta, nodeInfo) returns with error, there will be no chance for results[i + 1] to initialize its value, thus causing panic when calling config.Reduce(pod, meta, nodeNameToInfo, results[i+1])
/sig scheduling
I opened a PR to initialize results with real host name instead of empty string.
Change:
// Mount mounts the volume on the host. func (u *storageosUtil) MountVolume(b *storageosMounter, mntDevice, deviceMountPath string) error { <ins> klog.V(4).Infof("mounting StorageOS volume %q with namespace %q", b.volName, b.volNamespace) </ins> notMnt, err := b.mounter.IsLikelyNotMountPoint(deviceMountPath) if err != nil { if os.IsNotExist(err) {

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 is created and the PV mounted into a Pod using the StorageOS in-tree volume driver, the StorageOS CLI & UI do not report that the volume is mounted. The PV is created and mounted into the Pod successfully, and all k8s functionality works as expected. However, since the correct mount status is not visible to administrators using the StorageOS UI or CLI, they may make changes to or delete a mounted volume without realising, and the safeguards (must use to delete a mounted volume) do not trigger. This is a regression caused by , released in 1.14.0. What you expected to happen: The StorageOS CLI should report volume mount information (node name, mount timestamp). How to reproduce it (as minimally and precisely as possible): StorageOS node containers with CSI disabled: application Pod with a PVC using the StorageOS StorageClass: StorageOS to list volumes: Anything else we need to know?: Environment: Kubernetes version (use ): 1.14.0 and later Cloud provider or hardware configuration: any OS (e.g: ): any linux (incl. Ubuntu 18.04) Kernel (e.g. ): any linux (incl. 4.15.0-33-generic) Install tools: any (incl. minikube) Network plugin and version (if this is a network-related bug): N/A Others: Requires StorageOS deployment /sig storage /assign
Change:
The top command allows you to see the resource consumption for nodes or pods. <del> This command requires Heapster to be correctly configured and working on the server. `)) </del> <ins> This command requires Metrics Server to be correctly configured and working on the server. `)) </ins> ) func NewCmdTop(f cmdutil.Factory, streams genericclioptions.IOStreams) *cobra.Command {

Discussion:
I am running k8s 1.15 and I see kubectl top --help is returning the following info: ...This command requires Heapster to be correctly configured and working on the server. As far as I know Heaspter is deprecated since 1.11. 1) Should the command help be updated i.e. replace Heapster with Metrics Server? 2) Will the command work if Metrics Server is deployed in the cluster? 3) Is kubectl top utility the easiest way to display (actual) resource usage info for pods and nodes? Any suggestions?
/sig cli
submitted a pr for this yes yes, or kubernetes dashboard
Change:
"time" "github.com/google/go-cmp/cmp" <ins> "github.com/onsi/gomega" </ins> v1 "k8s.io/api/core/v1" eventsv1 "k8s.io/api/events/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"

Discussion:
/kind failing-test /kind flake First seen in an unrelated PR, but also occurs in periodic jobs. /sig scheduling
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign This feature is reverted once, and I fixed the flake, I'm cherry-pick that back again.
Change:
t.Errorf("Expected original,added groups, got %#v", user.GetGroups()) } } <ins> func TestAuthenticatedGroupAdder(t *testing.T) { tests := []struct { name         string inputUser    user.Info expectedUser user.Info }{ { name: "add", inputUser: &user.DefaultInfo{ Name:   "user", Groups: []string{"some-group"}, }, expectedUser: &user.DefaultInfo{ Name:   "user", Groups: []string{"some-group", user.AllAuthenticated}, }, }, { name: "don't double add", inputUser: &user.DefaultInfo{ Name:   "user", Groups: []string{user.AllAuthenticated, "some-group"}, }, expectedUser: &user.DefaultInfo{ Name:   "user", Groups: []string{user.AllAuthenticated, "some-group"}, }, }, { name: "don't add for anon", inputUser: &user.DefaultInfo{ Name:   user.Anonymous, Groups: []string{"some-group"}, }, expectedUser: &user.DefaultInfo{ Name:   user.Anonymous, Groups: []string{"some-group"}, }, }, { name: "don't add for unauthenticated group", inputUser: &user.DefaultInfo{ Name:   "user", Groups: []string{user.AllUnauthenticated, "some-group"}, }, expectedUser: &user.DefaultInfo{ Name:   "user", Groups: []string{user.AllUnauthenticated, "some-group"}, }, }, } for _, test := range tests { adder := authenticator.Request( NewAuthenticatedGroupAdder( authenticator.RequestFunc(func(req *http.Request) (user.Info, bool, error) { return test.inputUser, true, nil }), ), ) user, _, _ := adder.AuthenticateRequest(nil) if !reflect.DeepEqual(user, test.expectedUser) { t.Errorf("got %#v", user) } } } </ins>

Discussion:
When an auth proxy tries to proxy an anonymous request, the user.Info ends up with the group system:authenticated, which is wrong.
Change:
configs[CheckMetadataConcealment] = Config{e2eRegistry, "metadata-concealment", "1.2"} configs[CudaVectorAdd] = Config{e2eRegistry, "cuda-vector-add", "1.0"} configs[CudaVectorAdd2] = Config{e2eRegistry, "cuda-vector-add", "2.0"} <del> configs[DebianIptables] = Config{buildImageRegistry, "debian-iptables", "buster-v1.3.0"} </del> <ins> configs[DebianIptables] = Config{buildImageRegistry, "debian-iptables", "buster-v1.4.0"} </ins> configs[EchoServer] = Config{e2eRegistry, "echoserver", "2.2"} configs[Etcd] = Config{gcRegistry, "etcd", "3.4.13-0"} configs[GlusterDynamicProvisioner] = Config{dockerGluster, "glusterdynamic-provisioner", "v1.0"}

Discussion:
What happened: The latest release of the debian-base image, v2.1.3, contains a vulnerable version of the apt package. CVE-2020- impacts apt version 1.8.2.1. What you expected to happen: Image should be updated to use at least apt 1.8.2.2 to clear the vulnerability. How to reproduce it (as minimally and precisely as possible):
/sig release
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
kube-proxy is using debain as base image. /assign Let me check other components
checked the base image in and I seems that no new debian or ubuntu official image is built for this CVE ?
That is correct, the purpose of this issue is to get a new image built and released, one which contains a resolution for the CVE.
per comments of @ tianon in Will update it once debain releases it.
Change:
} if metricFamily == nil { <del> return Histogram{}, fmt.Errorf("metric %q not found", metricName) </del> <ins> return nil, fmt.Errorf("metric %q not found", metricName) </ins> } if metricFamily.GetMetric() == nil { <del> return Histogram{}, fmt.Errorf("metric %q is empty", metricName) </del> <ins> return nil, fmt.Errorf("metric %q is empty", metricName) </ins> } if len(metricFamily.GetMetric()) == 0 { <del> return Histogram{}, fmt.Errorf("metric %q is empty", metricName) </del> <ins> return nil, fmt.Errorf("metric %q is empty", metricName) </ins> } <del> return Histogram{ // Histograms are stored under the first index (based on observation). // Given there's only one histogram registered per each metric name, accessing // the first index is sufficient. metricFamily.GetMetric()[0].GetHistogram(), }, nil </del> <ins> vec := make(HistogramVec, 0) for _, metric := range metricFamily.GetMetric() { if LabelsMatch(metric, lvMap) { if hist := metric.GetHistogram(); hist != nil { vec = append(vec, &Histogram{hist}) } } } return vec, nil </ins> } func uint64Ptr(u uint64) *uint64 {

Discussion:
The new scheduler performance test was introduced back in 1.18, back then, the metric it supported are all . However, along with , some metrics are updated to be , and hence it's no longer appropriate to return the first Histogram: However, it's very common (for instance Preemption) that the metrics may hold multiple histograms: Additionally, metrics and have been removed, we should update them to : /sig scheduling
/triage accepted /assign
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-contributor-experience at . /lifecycle stale
/remove-lifecycle stale
Change:
# These are the default versions (image tags) for their respective base images. readonly __default_distroless_iptables_version=v0.5.1 <del> readonly __default_go_runner_version=v2.3.1-go1.22-bookworm.0 </del> <ins> readonly __default_go_runner_version=v2.3.1-go1.22.0-bookworm.0 </ins> readonly __default_setcap_version=bookworm-v1.0.1 # These are the base images for the Docker-wrapped binaries.

Discussion:
https://prow.ppc64le- Tests are not getting executed due to improper go version. It has been failing since past 4 days. No response No response No response /sig node
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
This seems to be failing due to improper version addition in dependency files where is instead of at some places. I will raise a PR for it.
/assign
fixing that
Change:
"//pkg/controller:go_default_library", "//pkg/controller/util/endpoint:go_default_library", "//pkg/features:go_default_library", <ins> "//pkg/util/labels:go_default_library", </ins> "//staging/src/k8s.io/api/core/v1:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/api/equality:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/api/errors:go_default_library",

Discussion:
bug (): Originally posted by in cc /sig network /priority critical-urgent
fix in
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
Change:
} } <del> if !probeGracePeriodInUse(oldPodSpec) { // Set pod-level terminationGracePeriodSeconds to nil if the feature is disabled and it is not used VisitContainers(podSpec, AllContainers, func(c *api.Container, containerType ContainerType) bool { if c.LivenessProbe != nil { c.LivenessProbe.TerminationGracePeriodSeconds = nil } if c.StartupProbe != nil { c.StartupProbe.TerminationGracePeriodSeconds = nil } // cannot be set for readiness probes return true }) } </del> // If the feature is disabled and not in use, drop the hostUsers field. if !utilfeature.DefaultFeatureGate.Enabled(features.UserNamespacesSupport) && !hostUsersInUse(oldPodSpec) { // Drop the field in podSpec only if SecurityContext is not nil.

Discussion:
Kubernetes does not respect the of a probe. I found this while fixing the e2e tests. Test result: /kind regression /kind bug /sig node /priority important-soon The of a container's probe should override the pod's . a pod with long pod-level terminationGracePeriodSeconds and short probe-level terminationGracePeriodSeconds. for the container not respecting the probe-level terminationGracePeriodSeconds No response <details</details<details</details<details</details<details</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 guess the probe's terminationGracePeriodSeconds field is dropped for some reason.
/assign
Change:
# When a 'git archive' is exported, the '$Format:%D$' below will look # something like 'HEAD -> release-1.8, tag: v1.8.3' where then 'tag: ' # can be extracted from it. <del> if [[ '$Format:%D$' =~ tag: (v[^ ]+) ]]; then </del> <ins> if [[ '$Format:%D$' =~ tag: (v[^ ,]+) ]]; then </ins> KUBE_GIT_VERSION="${BASH_REMATCH[1]}" fi fi

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Download the kube release source artifact from and do a build. All the kube binaries have a extraneous comma in the version: $ /usr/bin/kube-proxy --version Kubernetes v1.9.3, What you expected to happen: kube binaries built from git archive source tgz to show the correct version without extra comma. this was introduced in git attribute export-subst on creates a string format like ''HEAD -release-1.9, tag: v1.9.3, origin/release-1.9' . so, the regex capture should ignore ','
/sig release
The issue is that our regex didn't handle the case where the tag isn't the last part of the string filled in by : One the 1.9.3 source tarball linked, this looks like This should be a pretty easy fix - I don't think commas are allowed in semantic version strings. /assign
/kind bug /priority important-soon
This PR likely affects v1.10 as well. I have a fix out:
Confirmed: this affects v1.10.0-beta.0 (trying ): Though applying my fix from reveals a different bug: The issue then is that there are multiple tags matching that commit when it was built: who could guess that hacks would break?
disregard the second part of my comment above (at least for now); v1.10.0-beta.1 has a more reasonable string: (but it still demonstrates the original bug this issue mentions)
we need a sig lead to status/approved-for-milestone here
/status approved-for-milestone sure, good to be fixed :-)
aaaaaand priority increased and re- to milestone....
/priority critical-urgent
Master branch is fixed. Creating cherry-pick PRs now: 1.9: 1.8: 1.7:
[MILESTONENOTIFIER] Milestone Issue Labels Incomplete Action required: This issue requires label changes. priority: Must specify exactly one of , or .

<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
Cherry pick PRs are in. Next patch release of each branch should be fixed. /close
Change:
which won't work properly on Windows. See https://github.com/moby/buildkit/issues/1560 - The base image for all the Windows images is nanoserver, which is ~10 times smaller than Windows Servercore. Most binaries added to the image will work out of the box, but some will not due to missing dependencies <del> (**atention**: the image will still build successfully, even if the added binaries will not work). </del> <ins> (**attention**: the image will still build successfully, even if the added binaries will not work). </ins> For example, `coredns.exe` requires `netapi32.dll`, which cannot be found on a nanoserver image, but we can copy it from a servercore image (see the agnhost image's `Dockerfile_windows` file as an example). A good rule of thumb is to use 64-bit applications instead of 32-bit as they have fewer dependencies.

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI -- [sig-windows] [Feature:Windows] GMSA Kubelet [Slow] kubelet GMSA support when creating a pod with correct GMSA credential specs passes the credential specs down to the Pod's containers [sig-windows] [Feature:Windows] GMSA Full [Serial] [Slow] GMSA support works end to end ** pause image using in image was transitioned to the official pause image which no longer has in the image related to /sig windows /triage accepted
Change:
} func (s *sourceEtcd) run() { <del> watching := s.helper.Watch(s.key, 0) </del> <ins> boundPods := api.BoundPods{} err := s.helper.ExtractToList(s.key, &boundPods) if err != nil { glog.Errorf("etcd failed to retrieve the value for the key %q. Error: %v", s.key, err) return } // Push update. Maybe an empty PodList to allow EtcdSource to be marked as seen s.updates <- kubelet.PodUpdate{boundPods.Items, kubelet.SET, kubelet.EtcdSource} index, _ := s.helper.ResourceVersioner.ResourceVersion(&boundPods) watching := s.helper.Watch(s.key, index) </ins> for { select { case event, ok := <-watching.ResultChan():

Discussion:
To reproduce: Start a cluster via hack/local-up- Start some pods Kill the cluster "docker ps -a" should show the pod containers running still Start the cluster again "etcdctl ls /registry" should show that there is no boundpods directory -- only minions and services "docker ps -a" should show the old pod containers still running Start a new pod After, say, 10s, "docker ps -a" should show the old containers dead /cc
I suspect the cause of this might be : which guarantees that the pod sync logic is never called if is nil. Need to get a repro to confirm.
Change:
h.driverInfo.Config.ClientNodeName = node.Name } <del> func (h *hostpathDriver) DeleteVolume(volType testpatterns.TestVolType) { </del> <ins> func (h *hostPathDriver) DeleteVolume(volType testpatterns.TestVolType) { </ins> } <del> // HostpathSymlink type hostpathSymlinkDriver struct { </del> <ins> // HostPathSymlink type hostPathSymlinkDriver struct { </ins> node       v1.Node sourcePath string targetPath string

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: https://k8s- What happened: The skip check for hostpath doesn't seem to be working for these test cases
can you take a look?
Oh, disruptive tests are the tests that can't be tested locally in my environment due to I will take a look.
I found that above issue is not related, I should have been checked more carefully. Sorry for that.
I found out that this was just a driver name issue, so below will fix it: hostpath -hostPath hostpathSymlink -hostPathSymlink We might be better changing the skip logic later, to make it skip not by name in order to avoid this kind of bug, though. I will make a PR for above change, soon.
I made a PR above. Also, it might be a bit out of scope of this fix, but are drivers tested with containerized volume server, like nfs, ceph, etc..., safe to be tested with subpath disruptive tests? I'm worrying about the case that test pod and containerized volume server are deployed on the same node. In such a case, the same behaviour expected or do we need to avoid this kind of situation?
Change:
// ErrorNotVmssInstance indicates an instance is not belongint to any vmss. ErrorNotVmssInstance = errors.New("not a vmss instance") <del> scaleSetNameRE = regexp.MustCompile(`.*/subscriptions/(?:.*)/Microsoft.Compute/virtualMachineScaleSets/(.+)/virtualMachines(?:.*)`) </del> <ins> scaleSetNameRE        = regexp.MustCompile(`.*/subscriptions/(?:.*)/Microsoft.Compute/virtualMachineScaleSets/(.+)/virtualMachines(?:.*)`) vmssMachineIDTemplate = "/subscriptions/%s/resourceGroups/%s/providers/Microsoft.Compute/virtualMachineScaleSets/%s/virtualMachines/%s" </ins> ) // scaleSet implements VMSet interface for Azure scale set.

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: What happened: When useInstanceMetadata is set to true for vmss nodes, their providerID is wrong. What you expected to happen: Their providerID should be in format azure:///subscriptions/&lt;subscription-id/resourceGroups/&lt;rg-name/providers/Microsoft.Compute/virtualMachineScaleSets/&lt;scaleset-name/virtualMachines/&lt;instance-id 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. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/sig azure
adding priority important-soon so that this issue can stay in 1.10. Please update if incorrect. /priority important-soon
Change:
func SetObjectDefaults_Service(in *v1.Service) { SetDefaults_Service(in) <ins> for i := range in.Spec.Ports { a := &in.Spec.Ports[i] if a.Protocol == "" { a.Protocol = "TCP" } } </ins> } func SetObjectDefaults_ServiceList(in *v1.ServiceList) {

Discussion:
It looks like the openapi is not routed properly to set-up the apiservice so apply requests will fail because the fieldmanager is not set-up properly. /cc /sig api-machinery /priority important-soon /kind bug
/wg apply /cc
OpenAPIModels is set to nil for the kube-aggregator server config (which serves the APIServices API): This is done because the kube-aggregator has a special openapi handler that aggregates all the other server's openapi docs. The field controls (at least) two things: /openapi endpoint serving (which we want kube-aggregator to continue to customize) creation of the field manager (which we want kube-aggregator to behave consistently on) We need to decouple presence of OpenAPIConfig and construction of StaticOpenAPISpec (which is needed by the field manager) from construction/installation of OpenAPIVersionedService. That might be a little tricky to untangle, since construction of StaticOpenAPISpec includes paths/operations. The field manager only needs the gvk/schemas.
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 This is not something we want closed by accident.
/assign
For reference:
Additional lines for reference: This is roughly how SSA consumes the openapi spec. openapi spec -openapi proto model -typeconverter -SSA field manager For built in types, openapi spec -openapi model openapi model -typeconverter A similar thing happens for CRDs As liggitt mentioned, SSA only requires a subset of the information in the openapi generation, and the openapi generation in the aggregator slightly different than the process for builtins and CRDs.
/unassign
/assign