jiebi/CodeConvo huggingface dataset:
Change:
What happened: While implementing the new VolumePVCDataSource feature I discovered that even though the we don't use APIGroup (the appropriate setting is ) if the APIGroup is omitted it results in a nil pointer exception on the API server. What you expected to happen: APIGroup should be able to be omitted from the spec How to reproduce it (as minimally and precisely as possible): Create a spec to create a clone of a PVC with out the APIGroup parameter in the DataSource spec: The result will be an nil pointer exception during the verification of the datasource field. Adding the APIGroup entry will address this as a work-around: Anything else we need to know?: Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.3", GitCommit:"", GitTreeState:"clean", BuildDate:"2019-06-06T01:44:30Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"7+", GitVersion:"v1.7.0-alpha.1.+-dirty", GitCommit:"", GitTreeState:"dirty", BuildDate:"2019-06-12T22:12:02Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"} Install tools: local-up-
I have a simple fix, will post PR in a moment
/sig storage
/priority critical-urgent /milestone v1.15

Discussion:
func dataSourceIsEnabled(pvcSpec *core.PersistentVolumeClaimSpec) bool { if pvcSpec.DataSource != nil { <del> if pvcSpec.DataSource.Kind == pvc && *pvcSpec.DataSource.APIGroup == "" && utilfeature.DefaultFeatureGate.Enabled(features.VolumePVCDataSource) { </del> <ins> apiGroup := "" if pvcSpec.DataSource.APIGroup != nil { apiGroup = *pvcSpec.DataSource.APIGroup } if utilfeature.DefaultFeatureGate.Enabled(features.VolumePVCDataSource) && pvcSpec.DataSource.Kind == pvc && apiGroup == "" { </ins> return true } <del> if pvcSpec.DataSource.Kind == volumeSnapshot && *pvcSpec.DataSource.APIGroup == "snapshot.storage.k8s.io" && utilfeature.DefaultFeatureGate.Enabled(features.VolumeSnapshotDataSource) { </del> <ins> if utilfeature.DefaultFeatureGate.Enabled(features.VolumeSnapshotDataSource) && pvcSpec.DataSource.Kind == volumeSnapshot && apiGroup == "snapshot.storage.k8s.io" { </ins> return true } }

Name:     "test_clone", }, } <ins> validSpecNilAPIGroup := core.PersistentVolumeClaimSpec{ DataSource: &core.TypedLocalObjectReference{ Kind: "PersistentVolumeClaim", Name: "test_clone", }, } </ins> invalidAPIGroup := "invalid.pvc.api.group" invalidSpec := core.PersistentVolumeClaimSpec{

gateEnabled: false, want:        nil, }, <ins> "enabled with valid spec but nil APIGroup": { spec:        validSpecNilAPIGroup, gateEnabled: true, want:        validSpecNilAPIGroup.DataSource, }, "disabled with valid spec but nil APIGroup": { spec:        validSpecNilAPIGroup, gateEnabled: false, want:        nil, }, </ins> } for testName, test := range tests {
Change:
<!-- 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 resource id should be case insensitve, while some places are case sensitve: What you expected to happen: 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: /sig azure /assign

Discussion:
// according to https://docs.microsoft.com/en-us/rest/api/compute/disks/get func getResourceGroupFromDiskURI(diskURI string) (string, error) { fields := strings.Split(diskURI, "/") <del> if len(fields) != 9 || fields[3] != "resourceGroups" { </del> <ins> if len(fields) != 9 || strings.ToLower(fields[3]) != "resourcegroups" { </ins> return "", fmt.Errorf("invalid disk URI: %s", diskURI) } return fields[4], nil

expectError:    false, }, { <ins> // case insentive check diskURL:        "/subscriptions/4be8920b-2978-43d7-axyz-04d8549c1d05/resourcegroups/azure-k8s1102/providers/Microsoft.Compute/disks/andy-mghyb1102-dynamic-pvc-f7f014c9-49f4-11e8-ab5c-000d3af7b38e", expectedResult: "azure-k8s1102", expectError:    false, }, { </ins> diskURL:        "/4be8920b-2978-43d7-axyz-04d8549c1d05/resourceGroups/azure-k8s1102/providers/Microsoft.Compute/disks/andy-mghyb1102-dynamic-pvc-f7f014c9-49f4-11e8-ab5c-000d3af7b38e", expectedResult: "", expectError:    true,
Change:
What happened: We're updating the cluster from 1.12.1 to 1.14.3. When kubelet goes up for the first time, the following warnings related to cgroups pids controller appear: If we restart, kubelet returns fatal error with a similar motive: It makes sense since our kernel version doesn't support cgroups pids controller, then we disabled cgroups pids related feature gates: and expecting that kubelet would not require pids subsystems, but the behavior persisted. Looking at , it looks like pids subsystem will always be required even with feature gates disabled. This change was introduced with in . What you expected to happen: We expected that the cgroup pids subsystem to don't be required if feature gates related to pids are disabled. How to reproduce it (as minimally and precisely as possible): Try to start any kubelet in 1.14.x using a kernel older than 4.3. Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.3", GitCommit:"", GitTreeState:"clean", BuildDate:"2019-06-06T01:44:30Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"} OS (e.g: ): Oracle Linux Server release 7.6 Kernel (e.g. ): Linux 4.1.12-124.26.12.el7uek.x8664 SMP Wed May 8 22:25:03 PDT 2019 x8664 x8664 x86_64 GNU/Linux Install tools: puppet
/sig node
Thanks for looking into this! Do you want to create a pr? We can then merge this into master and also cherry-pick it back into 1.14. Alternatively, if you don't have capacity for a pr I'm happy to take a stab.
Just created:
/assign
cc
Hi, We are facing this issue, with kubernetes v1.15.0, is this fixed?
- see the version information of when the commit landed in the commit itself:

Discussion:
supportedSubsystems := map[subsystem]bool{ &cgroupfs.MemoryGroup{}: true, &cgroupfs.CpuGroup{}:    true, <del> &cgroupfs.PidsGroup{}:   true, </del> <ins> &cgroupfs.PidsGroup{}:   false, </ins> } // not all hosts support hugetlb cgroup, and in the absent of hugetlb, we will fail silently by reporting no capacity. supportedSubsystems[&cgroupfs.HugetlbGroup{}] = false
Change:
What would you like to be : GitHub has a that uses a file from the repository to show the project's security policy. Why is this needed: Adding this file makes it easier for security researchers to learn about the correct place to report a vulnerability in the Kubernetes project.
/sig docs
/remove-sig docs /sig contributor-experience

Discussion:
<ins> # Security Policy ## Supported Versions Information about supported Kubernetes versions can be found on the [Kubernetes version and version skew support policy] page on the Kubernetes website. ## Reporting a Vulnerability Instructions for reporting a vulnerability can be found on the [Kubernetes Security and Disclosure Information] page. [Kubernetes version and version skew support policy]: https://kubernetes.io/docs/setup/release/version-skew-policy/#supported-versions [Kubernetes Security and Disclosure Information]: https://kubernetes.io/docs/reference/issues-security/security/#report-a-vulnerability </ins>
Change:
What happened: In our kubernetes cluster, there are some slave nodes whose root partition has a very little disk space, so we add another larger-size disk device and symbolically link to a directory located at this larger device. however, kubelet failed to delete orphaned pod directory, there are lots of spam logging as below: After diving into this problem, I found the root cause: the failed to distinguishing the mountpoint when is a symbolic link. just compare the device number of the pod directory and its parent directory. however, using to obtain parent directory's device number which doesn't follow the link can lead an incorrect result I have done some tests: What you expected to happen: kubelet can successfully delete orphaned pod directory when the kubelet's pods directory symbolically links to another device's directory How to reproduce it (as minimally and precisely as possible): link to another disk device's directory pods and delete them Anything else we need to know?: Environment: Kubernetes version (use ): v1.10.11 Cloud provider or hardware configuration: bare-metal cluster OS (e.g: ):Kernel (e.g. ): Linux sh2-com-ocean120- 4.9.2-3.0.0.std7b.el7.5.x8664 SMP Thu Apr 26 17:33:02 CST 2018 x8664 x8664 x86_64 GNU/Linux Install tools: Network plugin and version (if this is a network-related bug): Others: /assign /sig storage
me too

Discussion:
if err != nil { return true, err } <del> rootStat, err := os.Lstat(filepath.Dir(strings.TrimSuffix(file, "/"))) </del> <ins> rootStat, err := os.Stat(filepath.Dir(strings.TrimSuffix(file, "/"))) </ins> if err != nil { return true, err }
Change:
Add readyz to GCE manifest for readiness checking on the apiserver. /assign
/sig api-machinery
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
/remove-lifecycle stale

Discussion:
"scheme": "HTTPS", "host": "127.0.0.1", "port": {{secure_port}}, <del> "path": "/healthz?exclude=etcd&exclude=kms-provider-0&exclude=kms-provider-1" </del> <ins> "path": "/livez?exclude=etcd&exclude=kms-provider-0&exclude=kms-provider-1" </ins> }, "initialDelaySeconds": {{liveness_probe_initial_delay}}, "timeoutSeconds": 15

"scheme": "HTTPS", "host": "127.0.0.1", "port": {{secure_port}}, <del> "path": "/healthz" </del> <ins> "path": "/readyz" </ins> }, "periodSeconds": 1, "timeoutSeconds": 15
Change:
The metrics framework requires the ability to optionally display hidden (deprecated) metrics. A boolean needs to be piped through the registry (possibly at initialization or possibly set later) which then needs to be passed to the Create function so that we can determine whether we need to actually create the metric. /sig instrumentation

Discussion:
if selfVersion.LTE(version) { r.isDeprecated = true } <ins> if ShouldShowHidden() { klog.Warningf("Hidden metrics have been manually overridden, showing this very deprecated metric.") return } </ins> if selfVersion.LT(version) { klog.Warningf("This metric has been deprecated for more than one release, hiding.") r.isHidden = true

package metrics import ( <ins> "sync" "sync/atomic" </ins> "github.com/blang/semver" "github.com/prometheus/client_golang/prometheus" dto "github.com/prometheus/client_model/go" apimachineryversion "k8s.io/apimachinery/pkg/version" ) <ins> var ( showHiddenOnce sync.Once showHidden     atomic.Value ) // SetShowHidden will enable showing hidden metrics. This will no-opt // after the initial call func SetShowHidden() { showHiddenOnce.Do(func() { showHidden.Store(true) }) } // ShouldShowHidden returns whether showing hidden deprecated metrics // is enabled. While the primary usecase for this is internal (to determine // registration behavior) this can also be used to introspect func ShouldShowHidden() bool { return showHidden.Load() != nil && showHidden.Load().(bool) } </ins> // Registerable is an interface for a collector metric which we // will register with KubeRegistry. type Registerable interface {

package metrics import ( <ins> "testing" </ins> "github.com/blang/semver" "github.com/prometheus/client_golang/prometheus" "github.com/stretchr/testify/assert" apimachineryversion "k8s.io/apimachinery/pkg/version" <del> "testing" </del> ) var (

} }) } <ins> } func TestShowHiddenMetric(t *testing.T) { registry := NewKubeRegistry(apimachineryversion.Info{ Major:      "1", Minor:      "15", GitVersion: "v1.15.0-alpha-1.12345", }) expectedMetricCount := 0 registry.MustRegister(alphaHiddenCounter) ms, err := registry.Gather() if len(ms) != expectedMetricCount { t.Errorf("Got %v metrics, Want: %v metrics", len(ms), expectedMetricCount) } showHidden.Store(true) defer showHidden.Store(false) registry.MustRegister(NewCounter( &CounterOpts{ Namespace:         "some_namespace", Name:              "test_alpha_show_hidden_counter", Subsystem:         "subsystem", StabilityLevel:    ALPHA, Help:              "counter help", DeprecatedVersion: &v114, }, )) expectedMetricCount = 1 ms, err = registry.Gather() if len(ms) != expectedMetricCount { t.Errorf("Got %v metrics, Want: %v metrics", len(ms), expectedMetricCount) } if err != nil { t.Fatalf("Gather failed %v", err) } </ins> }
Change:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: pull-kubernetes-integration Which test(s) are failing: TestUnreservePlugin Since when has it been failing: It happens frequently this week Testgrid link: Reason for failure: I0619 11:55:31. ] PUT /api/v1/namespaces/default/endpoints/kubernetes: (2.062872ms) 200 [ (linux/amd64) kubernetes/$Format 127.0.0.1:] test : Expected the unreserve plugin to be called 2 times, was called 1 times. Anything else we need to know:
This seems to be a issue in scheduler integration tests /sig scheduling
I was analyzing that failure based on the logs from given link. Based on my analysis the problem lies in here We wait for the pod to being unschedulable, and then we compare the counts of pre-bind and unreserve called. But this is done asynchronously so it can happen that between and us reading the counts the pod has already been scheduled and pre-bind was called while unreserve was not yet called. A simple solution would be to assert instead of I'll try to submit PR with that fix to see what people think about that :)
FYI: /assign /kind flake
cc/
/close

Discussion:
if err = waitForPodUnschedulable(cs, pod); err != nil { t.Errorf("test #%v: Didn't expected the pod to be scheduled. error: %v", i, err) } <del> if unresPlugin.numUnreserveCalled == 0 || unresPlugin.numUnreserveCalled != pbdPlugin.numPrebindCalled { </del> <ins> if unresPlugin.numUnreserveCalled == 0 { </ins> t.Errorf("test #%v: Expected the unreserve plugin to be called %d times, was called %d times.", i, pbdPlugin.numPrebindCalled, unresPlugin.numUnreserveCalled) } } else {
Change:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: All sig-windows jobs (master): Which test(s) are failing: [] Container Runtime blackbox test when running a container with a new image should be able to pull from private registry with secret [NodeConformance] [] Container Runtime blackbox test when running a container with a new image should be able to pull image from [NodeConformance] Since when has it been failing: Since this PR merged: Testgrid link: Reason for failure: The mentioned PR removed hardcoded image names from tests, centralizing them into , but there were a few omissions: entry was written for. registry set for ` is because that registry contains the Windows images needed for all the Kubernetes E2E tests. Anything else we need to know: /sig testing /sig windows /area conformance /priority important-soon

Discussion:
registry                = initReg() dockerLibraryRegistry   = registry.DockerLibraryRegistry e2eRegistry             = registry.E2eRegistry <ins> e2eGcRegistry           = "gcr.io/kubernetes-e2e-test-images" </ins> gcAuthenticatedRegistry = registry.GcAuthenticatedRegistry gcRegistry              = registry.GcRegistry googleContainerRegistry = registry.GoogleContainerRegistry

configs[Agnhost] = Config{e2eRegistry, "agnhost", "2.0"} configs[Alpine] = Config{dockerLibraryRegistry, "alpine", "3.7"} configs[AuthenticatedAlpine] = Config{gcAuthenticatedRegistry, "alpine", "3.7"} <ins> configs[AuthenticatedWindowsNanoServer] = Config{gcAuthenticatedRegistry, "windows-nanoserver", "v1"} </ins> configs[APIServer] = Config{e2eRegistry, "sample-apiserver", "1.10"} configs[AppArmorLoader] = Config{e2eRegistry, "apparmor-loader", "1.0"} configs[AuditProxy] = Config{e2eRegistry, "audit-proxy", "1.0"}

configs[VolumeISCSIServer] = Config{e2eRegistry, "volume/iscsi", "2.0"} configs[VolumeGlusterServer] = Config{e2eRegistry, "volume/gluster", "1.0"} configs[VolumeRBDServer] = Config{e2eRegistry, "volume/rbd", "1.0.1"} <del> configs[WindowsNanoServer] = Config{e2eRegistry, "windows-nanoserver", "v1"} </del> <ins> configs[WindowsNanoServer] = Config{e2eGcRegistry, "windows-nanoserver", "v1"} </ins> return configs }
Change:
<!-- 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: Running fails to remove etcd member. What you expected to happen: I expect to remove the node from the etcd cluster. How to reproduce it (as minimally and precisely as possible): From a working 1.15.0 cluster, run on a control plane node. Anything else we need to know?: I think the issues is due to the wrong function being used here: Environment: Kubernetes version (use ): 1.15.0 Cloud provider or hardware configuration: OS (e.g: ): Talos Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /cc
/area kubeadm
/sig cluster-lifecycle

Discussion:
Name:  "remove-etcd-member", Short: "Remove a local etcd member.", Long:  "Remove a local etcd member for a control plane node.", <del> Run:   runPreflight, </del> <ins> Run:   runRemoveETCDMemberPhase, </ins> InheritFlags: []string{ options.KubeconfigPath, },
Change:
<!-- 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: references and a broken link to this (because it doesn't exist!) I'm guessing this was a bad find and replace when copying kubeadm's own v1beta1 to v1beta2 What you expected to happen: accurate documentation How to reproduce it (as minimally and precisely as possible): read the docs Anything else we need to know?: this template has a lot of fields :^) Environment: anything Kubernetes version (use ): n/a Cloud provider or hardware configuration: n/a OS (e.g: ): n/a Kernel (e.g. ): n/a Install tools: kubeadm Network plugin and version (if this is a network-related bug): n/a Others: n/a /assign /sig cluster-lifecycle

Discussion:
//     apiVersion: kubeadm.k8s.io/v1beta2 //     kind: ClusterConfiguration // <del> //     apiVersion: kubelet.config.k8s.io/v1beta2 </del> <ins> //     apiVersion: kubelet.config.k8s.io/v1beta1 </ins> //     kind: KubeletConfiguration // //     apiVersion: kubeproxy.config.k8s.io/v1alpha1

// See https://kubernetes.io/docs/reference/command-line-tools-reference/kube-proxy/ or https://godoc.org/k8s.io/kube-proxy/config/v1alpha1#KubeProxyConfiguration // for kube proxy official documentation. // <del> //    apiVersion: kubelet.config.k8s.io/v1beta2 </del> <ins> //    apiVersion: kubelet.config.k8s.io/v1beta1 </ins> //    kind: KubeletConfiguration //       ... // // The KubeletConfiguration type should be used to change the configurations that will be passed to all kubelet instances // deployed in the cluster. If this object is not provided or provided only partially, kubeadm applies defaults. // <del> // See https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/ or https://godoc.org/k8s.io/kubelet/config/v1beta2#KubeletConfiguration </del> <ins> // See https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/ or https://godoc.org/k8s.io/kubelet/config/v1beta1#KubeletConfiguration </ins> // for kubelet official documentation. // // Here is a fully populated example of a single YAML file containing multiple

// 	useHyperKubeImage: false // 	clusterName: "example-cluster" // 	--- <del> // 	apiVersion: kubelet.config.k8s.io/v1beta2 </del> <ins> // 	apiVersion: kubelet.config.k8s.io/v1beta1 </ins> // 	kind: KubeletConfiguration // 	# kubelet specific options here // 	---
Change:
<!-- 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: kubectl version --client=yes command is giving the following error message. Error message is repeated at the start and the end and also containing programming jargon Error: invalid argument "yes" for "--client" flag: strconv.ParseBool: parsing "yes": invalid syntax Examples: Print the client and server versions for the current context kubectl version Options: --client=false: Client version only (no server required). -o, --output='': One of 'yaml' or 'json'. --short=false: Print just the version number. Usage: kubectl version [flags] [options] Use "kubectl options" for a list of global command-line options (applies to all commands). invalid argument "yes" for "--client" flag: strconv.ParseBool: parsing "yes": invalid syntax What you expected to happen: The error message can be improved with one of the two variants invalid argument "yes" for "--client" flag Examples: Print the client and server versions for the current context kubectl version Options: --client=false: Client version only (no server required). -o, --output='': One of 'yaml' or 'json'. --short=false: Print just the version number. Usage: kubectl version [flags] [options] Use "kubectl options" for a list of global command-line options (applies to all commands). (or) Invalid argument "yes" for "--client" flag How to reproduce it (as minimally and precisely as possible): Run the command kubectl version --client=yes Anything else we need to know?: Environment: Kubernetes version (use ): 1.15 Cloud provider or hardware configuration: AWS OS (e.g: ): Amazon Linux Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig cli
Hi Thanks for posting this issue! It turns out that this duplicate output has been in kubectl, and all the other cli cmds, since . This should be fixed by , and hopefully we can cherry pick it back to at least .

Discussion:
basename := filepath.Base(os.Args[0]) if err := commandFor(basename, hyperkubeCommand, allCommandFns).Execute(); err != nil { <del> fmt.Fprintf(os.Stderr, "%vn", err) </del> os.Exit(1) } }

defer logs.FlushLogs() if err := command.Execute(); err != nil { <del> fmt.Fprintf(os.Stderr, "error: %vn", err) </del> os.Exit(1) } }

package main import ( <del> "fmt" </del> "os" "k8s.io/klog"

func main() { klog.InitFlags(nil) if err := app.Run(); err != nil { <del> fmt.Fprintf(os.Stderr, "error: %vn", err) </del> os.Exit(1) } <del> os.Exit(0) </del> }

import ( goflag "flag" <del> "fmt" </del> "math/rand" "os" "time"

package main import ( <del> "fmt" </del> "math/rand" "os" "time"

defer logs.FlushLogs() if err := command.Execute(); err != nil { <del> fmt.Fprintf(os.Stderr, "%vn", err) </del> os.Exit(1) } }