jiebi/CodeConvo huggingface dataset:
Code change:
Which jobs are failing: All new tests introduced for api change Which test(s) are failing: New alpha subpathExpr tests [Feature:VolumeSubpathEnvExpansion][NodeAlphaFeature:VolumeSubpathEnvExpansion] Existing tests are working fine and the whole suite works correctly in the gce suite https://k8s- Since when has it been failing: 21st February 2019 (since merge of PR) Testgrid link: https://k8s- Reason for failure: Investigation shows that node e2e tests use a different framework pod creation pattern Doing some comparisons of tests that work and those that don't reveals differences in the standard client set as and the existing ones which do work go through the intermediate which uses The version has an additional function specifically for node tests
/sig storage
/sig node /sig test
/assign
/cc
/sig test

Related discussion:
text: func testPodFailSubpath(f *framework.Framework, pod *v1.Pod) { <del> pod, err := f.ClientSet.CoreV1().Pods(f.Namespace.Name).Create(pod) Expect(err).ToNot(HaveOccurred(), "while creating pod") </del> <ins> var podClient *framework.PodClient podClient = f.PodClient() pod = podClient.Create(pod) </ins> defer func() { framework.DeletePodWithWait(f, f.ClientSet, pod) }() <del> err = framework.WaitTimeoutForPodRunningInNamespace(f.ClientSet, pod.Name, pod.Namespace, framework.PodStartShortTimeout) </del> <ins> err := framework.WaitTimeoutForPodRunningInNamespace(f.ClientSet, pod.Name, pod.Namespace, framework.PodStartShortTimeout) </ins> Expect(err).To(HaveOccurred(), "while waiting for pod to be running") }
Code change:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: in Which test(s) are failing: Since when has it been failing: 2019-02-27 () -- since it was Testgrid link: Reason for failure: Timeout: Anything else we need to know: /kind failing-test /sig storage /priority important-soon /milestone v1.14 cc
cc Could you help with this please?
/assign
Neither of the failing tests mentioned in this issue are present in testgrid anymore. is all clear

Related discussion:
text: var _ = utils.SIGDescribe("CSI mock volume", func() { type testParameters struct { <del> attachable      bool </del> <ins> disableAttach   bool </ins> attachLimit     int registerDriver  bool podInfoVersion  *string
Code change:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: in Which test(s) are failing: Since when has it been failing: 2019-02-27 () -- since it was Testgrid link: Reason for failure: Timeout: Anything else we need to know: /kind failing-test /sig storage /priority important-soon /milestone v1.14 cc
cc Could you help with this please?
/assign
Neither of the failing tests mentioned in this issue are present in testgrid anymore. is all clear

Related discussion:
text: csics := f.CSIClientSet var err error <del> m.driver = drivers.InitMockCSIDriver(tp.registerDriver, tp.attachable, tp.podInfoVersion, tp.attachLimit) </del> <ins> m.driver = drivers.InitMockCSIDriver(tp.registerDriver, !tp.disableAttach, tp.podInfoVersion, tp.attachLimit) </ins> config, testCleanup := m.driver.PrepareTest(f) m.testCleanups = append(m.testCleanups, testCleanup) m.config = config
Code change:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: in Which test(s) are failing: Since when has it been failing: 2019-02-27 () -- since it was Testgrid link: Reason for failure: Timeout: Anything else we need to know: /kind failing-test /sig storage /priority important-soon /milestone v1.14 cc
cc Could you help with this please?
/assign
Neither of the failing tests mentioned in this issue are present in testgrid anymore. is all clear

Related discussion:
text: // The CSIDriverRegistry feature gate is needed for this test in Kubernetes 1.12. Context("CSI attach test using mock driver [Feature:CSIDriverRegistry]", func() { tests := []struct { <del> name             string driverAttachable bool deployDriverCRD  bool </del> <ins> name            string disableAttach   bool deployDriverCRD bool </ins> }{ { <del> name:             "should not require VolumeAttach for drivers without attachment", driverAttachable: false, deployDriverCRD:  true, </del> <ins> name:            "should not require VolumeAttach for drivers without attachment", disableAttach:   true, deployDriverCRD: true, </ins> }, { <del> name:             "should require VolumeAttach for drivers with attachment", driverAttachable: true, deployDriverCRD:  true, </del> <ins> name:            "should require VolumeAttach for drivers with attachment", deployDriverCRD: true, </ins> }, { <del> name:             "should preserve attachment policy when no CSIDriver present", driverAttachable: true, deployDriverCRD:  false, </del> <ins> name:            "should preserve attachment policy when no CSIDriver present", deployDriverCRD: false, </ins> }, } for _, t := range tests { test := t It(t.name, func() { var err error <del> init(testParameters{registerDriver: test.deployDriverCRD, attachable: test.driverAttachable}) </del> <ins> init(testParameters{registerDriver: test.deployDriverCRD, disableAttach: test.disableAttach}) </ins> defer cleanup() _, claim, pod := createPod()
Code change:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: in Which test(s) are failing: Since when has it been failing: 2019-02-27 () -- since it was Testgrid link: Reason for failure: Timeout: Anything else we need to know: /kind failing-test /sig storage /priority important-soon /milestone v1.14 cc
cc Could you help with this please?
/assign
Neither of the failing tests mentioned in this issue are present in testgrid anymore. is all clear

Related discussion:
text: _, err = m.cs.StorageV1beta1().VolumeAttachments().Get(attachmentName, metav1.GetOptions{}) if err != nil { if errors.IsNotFound(err) { <del> if test.driverAttachable { </del> <ins> if !test.disableAttach { </ins> framework.ExpectNoError(err, "Expected VolumeAttachment but none was found") } } else { framework.ExpectNoError(err, "Failed to find VolumeAttachment") } } <del> if !test.driverAttachable { </del> <ins> if test.disableAttach { </ins> Expect(err).To(HaveOccurred(), "Unexpected VolumeAttachment found") } })
Code change:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: in Which test(s) are failing: Since when has it been failing: 2019-02-27 () -- since it was Testgrid link: Reason for failure: Timeout: Anything else we need to know: /kind failing-test /sig storage /priority important-soon /milestone v1.14 cc
cc Could you help with this please?
/assign
Neither of the failing tests mentioned in this issue are present in testgrid anymore. is all clear

Related discussion:
text: // define volume limit to be 2 for this test var err error <del> init(testParameters{attachable: true, nodeSelectorKey: "node-attach-limit-csi", attachLimit: 2}) </del> <ins> init(testParameters{nodeSelectorKey: "node-attach-limit-csi", attachLimit: 2}) </ins> defer cleanup() nodeName := m.config.ClientNodeName attachKey := v1.ResourceName(volumeutil.GetCSIAttachLimitKey(m.provisioner))
Code change:
What happened: Currently starting Kubectl failing on Azure Stack. What you expected to happen: Kubectl should start on Azure Stack environment. How to reproduce it (as minimally and precisely as possible): Try to deploy Kubernets on Azure Stack environment.. Anything else we need to know?: Environment: Kubernetes version (use kubectl version): master Cloud provider or hardware configuration: OS (e.g: cat /etc/os-release): Kernel (e.g. uname -a): Install tools: Others: /sig azure /assign
is it ? is a tool ...
my bad its kubelet. I update the title.
then could you provide the kubelet log? I am not sure kubelet on Azure stack is running as a container or process, you could get the logs by: And how do you deploy k8s on azure stack? cc

Related discussion:
text: func TestGetZone(t *testing.T) { cloud := &Cloud{ Config: Config{ <del> Location: "eastus", </del> <ins> Location:            "eastus", UseInstanceMetadata: true, </ins> }, } testcases := []struct {
Code change:
What happened: Currently starting Kubectl failing on Azure Stack. What you expected to happen: Kubectl should start on Azure Stack environment. How to reproduce it (as minimally and precisely as possible): Try to deploy Kubernets on Azure Stack environment.. Anything else we need to know?: Environment: Kubernetes version (use kubectl version): master Cloud provider or hardware configuration: OS (e.g: cat /etc/os-release): Kernel (e.g. uname -a): Install tools: Others: /sig azure /assign
is it ? is a tool ...
my bad its kubelet. I update the title.
then could you provide the kubelet log? I am not sure kubelet on Azure stack is running as a container or process, you could get the logs by: And how do you deploy k8s on azure stack? cc

Related discussion:
text: import ( "context" "fmt" <ins> "os" </ins> "strconv" "strings"
Code change:
What happened: Currently starting Kubectl failing on Azure Stack. What you expected to happen: Kubectl should start on Azure Stack environment. How to reproduce it (as minimally and precisely as possible): Try to deploy Kubernets on Azure Stack environment.. Anything else we need to know?: Environment: Kubernetes version (use kubectl version): master Cloud provider or hardware configuration: OS (e.g: cat /etc/os-release): Kernel (e.g. uname -a): Install tools: Others: /sig azure /assign
is it ? is a tool ...
my bad its kubelet. I update the title.
then could you provide the kubelet log? I am not sure kubelet on Azure stack is running as a container or process, you could get the logs by: And how do you deploy k8s on azure stack? cc

Related discussion:
text: // GetZone returns the Zone containing the current availability zone and locality region that the program is running in. // If the node is not running with availability zones, then it will fall back to fault domain. func (az *Cloud) GetZone(ctx context.Context) (cloudprovider.Zone, error) { <del> metadata, err := az.metadata.GetMetadata() if err != nil { return cloudprovider.Zone{}, err } </del> <ins> if az.UseInstanceMetadata { metadata, err := az.metadata.GetMetadata() if err != nil { return cloudprovider.Zone{}, err } </ins> <del> if metadata.Compute == nil { return cloudprovider.Zone{}, fmt.Errorf("failure of getting compute information from instance metadata") } </del> <ins> if metadata.Compute == nil { return cloudprovider.Zone{}, fmt.Errorf("failure of getting compute information from instance metadata") } </ins> <del> zone := "" if metadata.Compute.Zone != "" { zoneID, err := strconv.Atoi(metadata.Compute.Zone) if err != nil { return cloudprovider.Zone{}, fmt.Errorf("failed to parse zone ID %q: %v", metadata.Compute.Zone, err) </del> <ins> zone := "" if metadata.Compute.Zone != "" { zoneID, err := strconv.Atoi(metadata.Compute.Zone) if err != nil { return cloudprovider.Zone{}, fmt.Errorf("failed to parse zone ID %q: %v", metadata.Compute.Zone, err) } zone = az.makeZone(zoneID) } else { klog.V(3).Infof("Availability zone is not enabled for the node, falling back to fault domain") zone = metadata.Compute.FaultDomain </ins> } <del> zone = az.makeZone(zoneID) } else { klog.V(3).Infof("Availability zone is not enabled for the node, falling back to fault domain") zone = metadata.Compute.FaultDomain } return cloudprovider.Zone{ FailureDomain: zone, Region:        az.Location, }, nil </del> <ins> return cloudprovider.Zone{ FailureDomain: zone, Region:        az.Location, }, nil } // if UseInstanceMetadata is false, get Zone name by calling ARM hostname, err := os.Hostname() if err != nil { return cloudprovider.Zone{}, fmt.Errorf("failure getting hostname from kernel") } return az.vmSet.GetZoneByNodeName(strings.ToLower(hostname)) </ins> } // GetZoneByProviderID implements Zones.GetZoneByProviderID
Code change:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : 1) add metrics into kubelet to monitor ; 2) add throttling to . Why is this needed: Kubelet provides lots of its functionalities through its http server, and currently there is no server-side monitoring and throttling mechanisms. Adding metrics into kubelet to monitor its http server will improve its observability and debuggability; adding throttling will prevent kubelet being overloaded from serving too many http requests.
/sig node

Related discussion:
text: "//pkg/kubelet/apis/resourcemetrics/v1alpha1:go_default_library", "//pkg/kubelet/container:go_default_library", "//pkg/kubelet/prober:go_default_library", <ins> "//pkg/kubelet/server/metrics:go_default_library", </ins> "//pkg/kubelet/server/portforward:go_default_library", "//pkg/kubelet/server/remotecommand:go_default_library", "//pkg/kubelet/server/stats:go_default_library",
Code change:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : 1) add metrics into kubelet to monitor ; 2) add throttling to . Why is this needed: Kubelet provides lots of its functionalities through its http server, and currently there is no server-side monitoring and throttling mechanisms. Adding metrics into kubelet to monitor its http server will improve its observability and debuggability; adding throttling will prevent kubelet being overloaded from serving too many http requests.
/sig node

Related discussion:
text: name = "all-srcs", srcs = [ ":package-srcs", <ins> "//pkg/kubelet/server/metrics:all-srcs", </ins> "//pkg/kubelet/server/portforward:all-srcs", "//pkg/kubelet/server/remotecommand:all-srcs", "//pkg/kubelet/server/stats:all-srcs",
Code change:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : 1) add metrics into kubelet to monitor ; 2) add throttling to . Why is this needed: Kubelet provides lots of its functionalities through its http server, and currently there is no server-side monitoring and throttling mechanisms. Adding metrics into kubelet to monitor its http server will improve its observability and debuggability; adding throttling will prevent kubelet being overloaded from serving too many http requests.
/sig node

Related discussion:
text: <ins> package(default_visibility = ["//visibility:public"]) load( "@io_bazel_rules_go//go:def.bzl", "go_library", ) go_library( name = "go_default_library", srcs = ["metrics.go"], importpath = "k8s.io/kubernetes/pkg/kubelet/server/metrics", deps = [ "//vendor/github.com/prometheus/client_golang/prometheus:go_default_library", ], ) filegroup( name = "package-srcs", srcs = glob(["**"]), tags = ["automanaged"], visibility = ["//visibility:private"], ) filegroup( name = "all-srcs", srcs = [":package-srcs"], tags = ["automanaged"], ) </ins>
Code change:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : 1) add metrics into kubelet to monitor ; 2) add throttling to . Why is this needed: Kubelet provides lots of its functionalities through its http server, and currently there is no server-side monitoring and throttling mechanisms. Adding metrics into kubelet to monitor its http server will improve its observability and debuggability; adding throttling will prevent kubelet being overloaded from serving too many http requests.
/sig node

Related discussion:
text: <ins> /* Copyright 2019 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package metrics import ( "sync" "time" "github.com/prometheus/client_golang/prometheus" ) const ( kubeletSubsystem = "kubelet" ) var ( // HTTPRequests tracks the number of the http requests received since the server started. HTTPRequests = prometheus.NewCounterVec( prometheus.CounterOpts{ Subsystem: kubeletSubsystem, Name:      "http_requests_total", Help:      "Number of the http requests received since the server started", }, // server_type aims to differentiate the readonly server and the readwrite server. // long_running marks whether the request is long-running or not. // Currently, long-running requests include exec/attach/portforward/debug. []string{"method", "path", "host", "server_type", "long_running"}, ) // HTTPRequestsDuration tracks the duration in seconds to serve http requests. HTTPRequestsDuration = prometheus.NewHistogramVec( prometheus.HistogramOpts{ Subsystem: kubeletSubsystem, Name:      "http_requests_duration_seconds", Help:      "Duration in seconds to serve http requests", // Use DefBuckets for now, will customize the buckets if necessary. Buckets: prometheus.DefBuckets, }, []string{"method", "path", "host", "server_type", "long_running"}, ) // HTTPInflightRequests tracks the number of the inflight http requests. HTTPInflightRequests = prometheus.NewGaugeVec( prometheus.GaugeOpts{ Subsystem: kubeletSubsystem, Name:      "http_inflight_requests", Help:      "Number of the inflight http requests", }, []string{"method", "path", "host", "server_type", "long_running"}, ) ) var registerMetrics sync.Once // Register all metrics. func Register() { registerMetrics.Do(func() { prometheus.MustRegister(HTTPRequests) prometheus.MustRegister(HTTPRequestsDuration) prometheus.MustRegister(HTTPInflightRequests) }) } // SinceInSeconds gets the time since the specified start in seconds. func SinceInSeconds(start time.Time) float64 { return time.Since(start).Seconds() } </ins>
Code change:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : 1) add metrics into kubelet to monitor ; 2) add throttling to . Why is this needed: Kubelet provides lots of its functionalities through its http server, and currently there is no server-side monitoring and throttling mechanisms. Adding metrics into kubelet to monitor its http server will improve its observability and debuggability; adding throttling will prevent kubelet being overloaded from serving too many http requests.
/sig node

Related discussion:
text: "k8s.io/kubernetes/pkg/kubelet/apis/resourcemetrics/v1alpha1" kubecontainer "k8s.io/kubernetes/pkg/kubelet/container" "k8s.io/kubernetes/pkg/kubelet/prober" <ins> servermetrics "k8s.io/kubernetes/pkg/kubelet/server/metrics" </ins> "k8s.io/kubernetes/pkg/kubelet/server/portforward" remotecommandserver "k8s.io/kubernetes/pkg/kubelet/server/remotecommand" "k8s.io/kubernetes/pkg/kubelet/server/stats"
Code change:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : 1) add metrics into kubelet to monitor ; 2) add throttling to . Why is this needed: Kubelet provides lots of its functionalities through its http server, and currently there is no server-side monitoring and throttling mechanisms. Adding metrics into kubelet to monitor its http server will improve its observability and debuggability; adding throttling will prevent kubelet being overloaded from serving too many http requests.
/sig node

Related discussion:
text: proxyStream(response.ResponseWriter, request.Request, url) } <ins> // trimURLPath trims a URL path. // For paths in the format of "/metrics/xxx", "metrics/xxx" is returned; // For all other paths, the first part of the path is returned. func trimURLPath(path string) string { parts := strings.SplitN(strings.TrimPrefix(path, "/"), "/", 3) if len(parts) == 0 { return path } if parts[0] == "metrics" && len(parts) > 1 { return fmt.Sprintf("%s/%s", parts[0], parts[1]) } return parts[0] } // isLongRunningRequest determines whether the request is long-running or not. func isLongRunningRequest(path string) bool { longRunningRequestPaths := []string{"exec", "attach", "portforward", "debug"} for _, p := range longRunningRequestPaths { if p == path { return true } } return false } </ins> // ServeHTTP responds to HTTP requests on the Kubelet. func (s *Server) ServeHTTP(w http.ResponseWriter, req *http.Request) { defer httplog.NewLogged(req, &w).StacktraceWhen(
Code change:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : 1) add metrics into kubelet to monitor ; 2) add throttling to . Why is this needed: Kubelet provides lots of its functionalities through its http server, and currently there is no server-side monitoring and throttling mechanisms. Adding metrics into kubelet to monitor its http server will improve its observability and debuggability; adding throttling will prevent kubelet being overloaded from serving too many http requests.
/sig node

Related discussion:
text: http.StatusSwitchingProtocols, ), ).Log() <ins> // monitor http requests var serverType string if s.auth == nil { serverType = "readonly" } else { serverType = "readwrite" } method, path, host := req.Method, trimURLPath(req.URL.Path), req.URL.Host longRunning := strconv.FormatBool(isLongRunningRequest(path)) servermetrics.HTTPRequests.WithLabelValues(method, path, host, serverType, longRunning).Inc() servermetrics.HTTPInflightRequests.WithLabelValues(method, path, host, serverType, longRunning).Inc() defer servermetrics.HTTPInflightRequests.WithLabelValues(method, path, host, serverType, longRunning).Dec() startTime := time.Now() defer servermetrics.HTTPRequestsDuration.WithLabelValues(method, path, host, serverType, longRunning).Observe(servermetrics.SinceInSeconds(startTime)) </ins> s.restfulCont.ServeHTTP(w, req) }
Code change:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : 1) add metrics into kubelet to monitor ; 2) add throttling to . Why is this needed: Kubelet provides lots of its functionalities through its http server, and currently there is no server-side monitoring and throttling mechanisms. Adding metrics into kubelet to monitor its http server will improve its observability and debuggability; adding throttling will prevent kubelet being overloaded from serving too many http requests.
/sig node

Related discussion:
text: assert.Equal(t, http.StatusOK, resp.StatusCode) } <ins> func TestTrimURLPath(t *testing.T) { tests := []struct { path, expected string }{ {"", ""}, {"//", ""}, {"/pods", "pods"}, {"pods", "pods"}, {"pods/", "pods"}, {"good/", "good"}, {"pods/probes", "pods"}, {"metrics", "metrics"}, {"metrics/resource", "metrics/resource"}, {"metrics/hello", "metrics/hello"}, } for _, test := range tests { assert.Equal(t, test.expected, trimURLPath(test.path), fmt.Sprintf("path is: %s", test.path)) } } </ins>
Code 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: When referencing init container's env value from its fields, kubelet complains What you expected to happen: Init container should be supported to get env values from its own fields, as to How to reproduce it (as minimally and precisely as possible): a pod with init container refering its fields value as env value kubectl create -f test-pod-1.yaml cannot be created pod events Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: OS (e.g: ):Kernel (e.g. ):Install tools: Others:
Reiterating the mentions to trigger a notification: <detailsIn response to : 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
The err happens at this line , it seems that we should search for init containers as well

Related discussion:
text: return &container, nil } } <ins> for _, container := range pod.Spec.InitContainers { if container.Name == containerName { return &container, nil } } </ins> return nil, fmt.Errorf("container %s not found", containerName) }