Question:
<!-- Please only use this template for submitting enhancement requests --The built-in and cluster roles here are deprecated in 1.13 when this issue was resolved: /sig storage /milestone v1.17 /priorit important-longterm
You must be a member of the GitHub team to set the milestone. If you believe you should be able to issue the /milestone command, please contact your and have them propose you as an additional delegate for this responsibility. <detailsIn response to : <!-- Please only use this template for submitting enhancement requests -- /milestone v1.17 /priorit important-longterm 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
/cc /priority important-longterm
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 /assign
Bug triage for 1.17 here with a gentle reminder that code freeze for this release is on November 14. Is this issue still intended for 1.17?

creationTimestamp: null labels: kubernetes.io/bootstrapping: rbac-defaults <del> name: system:csi-external-attacher rules: - apiGroups: - "" resources: - persistentvolumes verbs: - get - list - patch - update - watch - apiGroups: - "" resources: - nodes verbs: - get - list - watch - apiGroups: - storage.k8s.io resources: - volumeattachments verbs: - get - list - patch - update - watch - apiGroups: - "" resources: - events verbs: - create - get - list - patch - update - watch - apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: annotations: rbac.authorization.kubernetes.io/autoupdate: "true" creationTimestamp: null labels: kubernetes.io/bootstrapping: rbac-defaults name: system:csi-external-provisioner rules: - apiGroups: - "" resources: - persistentvolumes verbs: - create - delete - get - list - watch - apiGroups: - "" resources: - persistentvolumeclaims verbs: - get - list - patch - update - watch - apiGroups: - storage.k8s.io resources: - storageclasses verbs: - list - watch - apiGroups: - "" resources: - events verbs: - create - get - list - patch - update - watch - apiGroups: - "" resources: - nodes verbs: - get - list - watch - apiGroups: - storage.k8s.io resources: - csinodes verbs: - get - list - watch - apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: annotations: rbac.authorization.kubernetes.io/autoupdate: "true" creationTimestamp: null labels: kubernetes.io/bootstrapping: rbac-defaults </del> name: system:discovery rules: - nonResourceURLs:


Question:
<!-- 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: kubelet terminated unexpectedly during hack/local-up-cluster kubelet log as a result apiserver cannot find the node to schedule pods What you expected to happen: kubelet runs successfully and hack/local-up-cluster creates a single node cluster How to reproduce it (as minimally and precisely as possible): run hack/local-up-cluster from HEAD Anything else we need to know?: additional cgroups check seemed to be introduced in ; hack/local-up-cluster works when I check out the parent commit have CI for hack/local-up-cluster and , so I'm not sure if it's an error on my side. It would be greatly appreciated if someone could explain it to me Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Debian GNU/Linux Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /sig node cc
Thanks for raising such a detailed issue! cc any thoughts here? Confusingly, I think the kubelet has been assigned a different cgroup for memory and for cpu... however the fact that its using makes me think the user is relying on system defaults. out of curiosity, have you made any mods to how your system assigns cgroups?
It sounds like we might want to handle the error more gracefully. If we can't get the kubelet's cgroup, we should fall back to collecting metrics from all cgroups.
collecting metrics from all the cgroups on the system? Any concerns about how many cgroups there could be? Also, or any interest in implementing this fix (assuming we go with the fallback behavior)? If not, I can try.
thanks for looking into this! Sorry I'm not familiar with cgroups. I'm don't know any modification to my system assigns cgroups in particular
I can put out a PR this week
xref
Thanks!

cgroupRoots = append(cgroupRoots, cm.NodeAllocatableRoot(s.CgroupRoot, s.CgroupDriver)) kubeletCgroup, err := cm.GetKubeletContainer(s.KubeletCgroups) if err != nil { <del> return fmt.Errorf("failed to get the kubelet's cgroup: %v", err) } if kubeletCgroup != "" { </del> <ins> klog.Warningf("failed to get the kubelet's cgroup: %v.  Kubelet system container metrics may be missing.", err) } else if kubeletCgroup != "" { </ins> cgroupRoots = append(cgroupRoots, kubeletCgroup) } runtimeCgroup, err := cm.GetRuntimeContainer(s.ContainerRuntime, s.RuntimeCgroups) if err != nil { <del> return fmt.Errorf("failed to get the container runtime's cgroup: %v", err) } if runtimeCgroup != "" { </del> <ins> klog.Warningf("failed to get the container runtime's cgroup: %v. Runtime system container metrics may be missing.", err) } else if runtimeCgroup != "" { </ins> // RuntimeCgroups is optional, so ignore if it isn't specified cgroupRoots = append(cgroupRoots, runtimeCgroup) }


Question:
Some kubelet metrics use non-standard prometheus collectors unnecessarily. Specifically, we have which can be simple gauges. Since we cannot migrate non-standard prometheus collectors using the internal metrics stability framework, we will need to convert these metrics into standard prometheus variants. /sig instrumentation /assign
GitHub didn't allow me to assign the following users: solodov. Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : Some kubelet metrics use non-standard prometheus collectors unnecessarily. Specifically, we have which can be simple gauges. Since we cannot migrate non-standard prometheus collectors using the internal metrics stability framework, we will need to convert these metrics into standard prometheus variants. /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
recommends that we generate those metrics in the GenericPLEG during the relist. We can generate the data directly from the pods call there ().
I would be interested to work on this issue if no one else is working on it currently
Go for it!
/assign

}, []string{"runtime_handler"}, ) <ins> // RunningPodCount is a gauge that tracks the number of Pods currently running RunningPodCount = metrics.NewGauge( &metrics.GaugeOpts{ Subsystem:      KubeletSubsystem, Name:           "running_pod_count", Help:           "Number of pods currently running", StabilityLevel: metrics.ALPHA, }, ) // RunningContainerCount is a gauge that tracks the number of containers currently running RunningContainerCount = metrics.NewGaugeVec( &metrics.GaugeOpts{ Subsystem:      KubeletSubsystem, Name:           "running_container_count", Help:           "Number of containers currently running", StabilityLevel: metrics.ALPHA, }, []string{"container_state"}, ) </ins> ) var registerMetrics sync.Once


Question:
Some kubelet metrics use non-standard prometheus collectors unnecessarily. Specifically, we have which can be simple gauges. Since we cannot migrate non-standard prometheus collectors using the internal metrics stability framework, we will need to convert these metrics into standard prometheus variants. /sig instrumentation /assign
GitHub didn't allow me to assign the following users: solodov. Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : Some kubelet metrics use non-standard prometheus collectors unnecessarily. Specifically, we have which can be simple gauges. Since we cannot migrate non-standard prometheus collectors using the internal metrics stability framework, we will need to convert these metrics into standard prometheus variants. /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
recommends that we generate those metrics in the GenericPLEG during the relist. We can generate the data directly from the pods call there ().
I would be interested to work on this issue if no one else is working on it currently
Go for it!
/assign

legacyregistry.MustRegister(CgroupManagerDuration) legacyregistry.MustRegister(PodWorkerStartDuration) legacyregistry.MustRegister(ContainersPerPodCount) <del> legacyregistry.RawMustRegister(newPodAndContainerCollector(containerCache)) </del> legacyregistry.MustRegister(PLEGRelistDuration) legacyregistry.MustRegister(PLEGDiscardEvents) legacyregistry.MustRegister(PLEGRelistInterval)


Question:
Some kubelet metrics use non-standard prometheus collectors unnecessarily. Specifically, we have which can be simple gauges. Since we cannot migrate non-standard prometheus collectors using the internal metrics stability framework, we will need to convert these metrics into standard prometheus variants. /sig instrumentation /assign
GitHub didn't allow me to assign the following users: solodov. Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : Some kubelet metrics use non-standard prometheus collectors unnecessarily. Specifically, we have which can be simple gauges. Since we cannot migrate non-standard prometheus collectors using the internal metrics stability framework, we will need to convert these metrics into standard prometheus variants. /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
recommends that we generate those metrics in the GenericPLEG during the relist. We can generate the data directly from the pods call there ().
I would be interested to work on this issue if no one else is working on it currently
Go for it!
/assign

legacyregistry.MustRegister(DeprecatedEvictionStatsAge) legacyregistry.MustRegister(DeprecatedDevicePluginRegistrationCount) legacyregistry.MustRegister(DeprecatedDevicePluginAllocationLatency) <ins> legacyregistry.MustRegister(RunningContainerCount) legacyregistry.MustRegister(RunningPodCount) </ins> if utilfeature.DefaultFeatureGate.Enabled(features.DynamicKubeletConfig) { legacyregistry.MustRegister(AssignedConfig) legacyregistry.MustRegister(ActiveConfig)


Question:
Some kubelet metrics use non-standard prometheus collectors unnecessarily. Specifically, we have which can be simple gauges. Since we cannot migrate non-standard prometheus collectors using the internal metrics stability framework, we will need to convert these metrics into standard prometheus variants. /sig instrumentation /assign
GitHub didn't allow me to assign the following users: solodov. Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : Some kubelet metrics use non-standard prometheus collectors unnecessarily. Specifically, we have which can be simple gauges. Since we cannot migrate non-standard prometheus collectors using the internal metrics stability framework, we will need to convert these metrics into standard prometheus variants. /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
recommends that we generate those metrics in the GenericPLEG during the relist. We can generate the data directly from the pods call there ().
I would be interested to work on this issue if no one else is working on it currently
Go for it!
/assign

return time.Since(start).Seconds() } <del> func newPodAndContainerCollector(containerCache kubecontainer.RuntimeCache) *podAndContainerCollector { return &podAndContainerCollector{ containerCache: containerCache, } } // Custom collector for current pod and container counts. type podAndContainerCollector struct { // Cache for accessing information about running containers. containerCache kubecontainer.RuntimeCache } // TODO(vmarmol): Split by source? var ( runningPodCountDesc = prometheus.NewDesc( prometheus.BuildFQName("", KubeletSubsystem, "running_pod_count"), "Number of pods currently running", nil, nil) runningContainerCountDesc = prometheus.NewDesc( prometheus.BuildFQName("", KubeletSubsystem, "running_container_count"), "Number of containers currently running", nil, nil) ) // Describe implements Prometheus' Describe method from the Collector interface. It sends all // available descriptions to the provided channel and retunrs once the last description has been sent. func (pc *podAndContainerCollector) Describe(ch chan<- *prometheus.Desc) { ch <- runningPodCountDesc ch <- runningContainerCountDesc } // Collect implements Prometheus' Collect method from the Collector interface. It's called by the Prometheus // registry when collecting metrics. func (pc *podAndContainerCollector) Collect(ch chan<- prometheus.Metric) { runningPods, err := pc.containerCache.GetPods() if err != nil { klog.Warningf("Failed to get running container information while collecting metrics: %v", err) return } runningContainers := 0 for _, p := range runningPods { runningContainers += len(p.Containers) } ch <- prometheus.MustNewConstMetric( runningPodCountDesc, prometheus.GaugeValue, float64(len(runningPods))) ch <- prometheus.MustNewConstMetric( runningContainerCountDesc, prometheus.GaugeValue, float64(runningContainers)) } </del> const configMapAPIPathFmt = "/api/v1/namespaces/%s/configmaps/%s" func configLabels(source *corev1.NodeConfigSource) (map[string]string, error) {


Question:
Some kubelet metrics use non-standard prometheus collectors unnecessarily. Specifically, we have which can be simple gauges. Since we cannot migrate non-standard prometheus collectors using the internal metrics stability framework, we will need to convert these metrics into standard prometheus variants. /sig instrumentation /assign
GitHub didn't allow me to assign the following users: solodov. Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : Some kubelet metrics use non-standard prometheus collectors unnecessarily. Specifically, we have which can be simple gauges. Since we cannot migrate non-standard prometheus collectors using the internal metrics stability framework, we will need to convert these metrics into standard prometheus variants. /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
recommends that we generate those metrics in the GenericPLEG during the relist. We can generate the data directly from the pods call there ().
I would be interested to work on this issue if no one else is working on it currently
Go for it!
/assign

deps = [ "//pkg/kubelet/container:go_default_library", "//pkg/kubelet/container/testing:go_default_library", <ins> "//pkg/kubelet/metrics:go_default_library", </ins> "//staging/src/k8s.io/apimachinery/pkg/types:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/util/clock:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/util/diff:go_default_library", <ins> "//vendor/github.com/prometheus/client_model/go:go_default_library", </ins> "//vendor/github.com/stretchr/testify/assert:go_default_library", ], )


Question:
Some kubelet metrics use non-standard prometheus collectors unnecessarily. Specifically, we have which can be simple gauges. Since we cannot migrate non-standard prometheus collectors using the internal metrics stability framework, we will need to convert these metrics into standard prometheus variants. /sig instrumentation /assign
GitHub didn't allow me to assign the following users: solodov. Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : Some kubelet metrics use non-standard prometheus collectors unnecessarily. Specifically, we have which can be simple gauges. Since we cannot migrate non-standard prometheus collectors using the internal metrics stability framework, we will need to convert these metrics into standard prometheus variants. /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
recommends that we generate those metrics in the GenericPLEG during the relist. We can generate the data directly from the pods call there ().
I would be interested to work on this issue if no one else is working on it currently
Go for it!
/assign

g.updateRelistTime(timestamp) pods := kubecontainer.Pods(podList) <ins> // update running pod and container count updateRunningPodAndContainerMetrics(pods) </ins> g.podRecords.setCurrent(pods) // Compare the old and the current pods, and generate events.


Question:
Some kubelet metrics use non-standard prometheus collectors unnecessarily. Specifically, we have which can be simple gauges. Since we cannot migrate non-standard prometheus collectors using the internal metrics stability framework, we will need to convert these metrics into standard prometheus variants. /sig instrumentation /assign
GitHub didn't allow me to assign the following users: solodov. Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : Some kubelet metrics use non-standard prometheus collectors unnecessarily. Specifically, we have which can be simple gauges. Since we cannot migrate non-standard prometheus collectors using the internal metrics stability framework, we will need to convert these metrics into standard prometheus variants. /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
recommends that we generate those metrics in the GenericPLEG during the relist. We can generate the data directly from the pods call there ().
I would be interested to work on this issue if no one else is working on it currently
Go for it!
/assign

return state } <ins> func updateRunningPodAndContainerMetrics(pods []*kubecontainer.Pod) { // Set the number of running pods in the parameter metrics.RunningPodCount.Set(float64(len(pods))) // intermediate map to store the count of each "container_state" containerStateCount := make(map[string]int) for _, pod := range pods { containers := pod.Containers for _, container := range containers { // update the corresponding "container_state" in map to set value for the gaugeVec metrics containerStateCount[string(container.State)]++ } } for key, value := range containerStateCount { metrics.RunningContainerCount.WithLabelValues(key).Set(float64(value)) } } </ins> func (pr podRecords) getOld(id types.UID) *kubecontainer.Pod { r, ok := pr[id] if !ok {


Question:
Some kubelet metrics use non-standard prometheus collectors unnecessarily. Specifically, we have which can be simple gauges. Since we cannot migrate non-standard prometheus collectors using the internal metrics stability framework, we will need to convert these metrics into standard prometheus variants. /sig instrumentation /assign
GitHub didn't allow me to assign the following users: solodov. Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : Some kubelet metrics use non-standard prometheus collectors unnecessarily. Specifically, we have which can be simple gauges. Since we cannot migrate non-standard prometheus collectors using the internal metrics stability framework, we will need to convert these metrics into standard prometheus variants. /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
recommends that we generate those metrics in the GenericPLEG during the relist. We can generate the data directly from the pods call there ().
I would be interested to work on this issue if no one else is working on it currently
Go for it!
/assign

"testing" "time" <ins> dto "github.com/prometheus/client_model/go" </ins> "github.com/stretchr/testify/assert" "k8s.io/apimachinery/pkg/types" "k8s.io/apimachinery/pkg/util/clock" "k8s.io/apimachinery/pkg/util/diff" kubecontainer "k8s.io/kubernetes/pkg/kubelet/container" containertest "k8s.io/kubernetes/pkg/kubelet/container/testing" <ins> "k8s.io/kubernetes/pkg/kubelet/metrics" </ins> ) const (


Question:
Some kubelet metrics use non-standard prometheus collectors unnecessarily. Specifically, we have which can be simple gauges. Since we cannot migrate non-standard prometheus collectors using the internal metrics stability framework, we will need to convert these metrics into standard prometheus variants. /sig instrumentation /assign
GitHub didn't allow me to assign the following users: solodov. Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : Some kubelet metrics use non-standard prometheus collectors unnecessarily. Specifically, we have which can be simple gauges. Since we cannot migrate non-standard prometheus collectors using the internal metrics stability framework, we will need to convert these metrics into standard prometheus variants. /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
recommends that we generate those metrics in the GenericPLEG during the relist. We can generate the data directly from the pods call there ().
I would be interested to work on this issue if no one else is working on it currently
Go for it!
/assign

assert.Exactly(t, []*PodLifecycleEvent{event}, actualEvents) } } <ins> func TestRunningPodAndContainerCount(t *testing.T) { fakeRuntime := &containertest.FakeRuntime{} runtimeCache, _ := kubecontainer.NewRuntimeCache(fakeRuntime) metrics.Register(runtimeCache) testPleg := newTestGenericPLEG() pleg, runtime := testPleg.pleg, testPleg.runtime runtime.AllPodList = []*containertest.FakePod{ {Pod: &kubecontainer.Pod{ ID: "1234", Containers: []*kubecontainer.Container{ createTestContainer("c1", kubecontainer.ContainerStateRunning), createTestContainer("c2", kubecontainer.ContainerStateUnknown), createTestContainer("c3", kubecontainer.ContainerStateUnknown), }, }}, {Pod: &kubecontainer.Pod{ ID: "4567", Containers: []*kubecontainer.Container{ createTestContainer("c1", kubecontainer.ContainerStateExited), }, }}, } pleg.relist() // assert for container count with label "running" actualMetricRunningContainerCount := &dto.Metric{} expectedMetricRunningContainerCount := float64(1) metrics.RunningContainerCount.WithLabelValues(string(kubecontainer.ContainerStateRunning)).Write(actualMetricRunningContainerCount) assert.Equal(t, expectedMetricRunningContainerCount, actualMetricRunningContainerCount.GetGauge().GetValue()) // assert for container count with label "unknown" actualMetricUnknownContainerCount := &dto.Metric{} expectedMetricUnknownContainerCount := float64(2) metrics.RunningContainerCount.WithLabelValues(string(kubecontainer.ContainerStateUnknown)).Write(actualMetricUnknownContainerCount) assert.Equal(t, expectedMetricUnknownContainerCount, actualMetricUnknownContainerCount.GetGauge().GetValue()) // assert for running pod count actualMetricRunningPodCount := &dto.Metric{} metrics.RunningPodCount.Write(actualMetricRunningPodCount) expectedMetricRunningPodCount := float64(2) assert.Equal(t, expectedMetricRunningPodCount, actualMetricRunningPodCount.GetGauge().GetValue()) } </ins>


Question:
What happened: tried promoting a test with a tag in its full test description. The hierarchy of ginko-relevant AST's was . The tag was a in the top level . The full test description only came from , so the tag was missed. What you expected to happen: The conformance test list generator should have logged and ERROR and failed a test on the PR, calling out Disruptive as an invalid tag How to reproduce it (as minimally and precisely as possible): Check out locally and follow the directions in to generate the conformance list. The invalid test is in the list. Anything else we need to know?: Is there a function we can use to get the full test description from Ginkgo instead of rolling our own? If not, we should probably be maintaining a stack rather than just the last FYI who ran into this FYI who wrote the code to keep track of last
/sig architecture /area conformance
/milestone v1.16
/priority important-soon
/assign
GitHub didn't allow me to assign the following users: devaips. Note that only and repo collaborators can be assigned and that 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

) const regexDescribe = "Describe|KubeDescribe|SIGDescribe" <del> const regexContext = "Context" </del> <ins> const regexContext = "^Context$" </ins> type visitor struct { <del> FileSet      *token.FileSet lastDescribe describe cMap         ast.CommentMap </del> <ins> FileSet   *token.FileSet describes []describe cMap      ast.CommentMap </ins> //list of all the conformance tests in the path tests []conformanceData } //describe contains text associated with ginkgo describe container type describe struct { <ins> rparen      token.Pos </ins> text        string lastContext context }


Question:
What happened: tried promoting a test with a tag in its full test description. The hierarchy of ginko-relevant AST's was . The tag was a in the top level . The full test description only came from , so the tag was missed. What you expected to happen: The conformance test list generator should have logged and ERROR and failed a test on the PR, calling out Disruptive as an invalid tag How to reproduce it (as minimally and precisely as possible): Check out locally and follow the directions in to generate the conformance list. The invalid test is in the list. Anything else we need to know?: Is there a function we can use to get the full test description from Ginkgo instead of rolling our own? If not, we should probably be maintaining a stack rather than just the last FYI who ran into this FYI who wrote the code to keep track of last
/sig architecture /area conformance
/milestone v1.16
/priority important-soon
/assign
GitHub didn't allow me to assign the following users: devaips. Note that only and repo collaborators can be assigned and that 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

return } <del> err := validateTestName(v.getDescription(at.Value)) </del> <ins> description := v.getDescription(at.Value) err := validateTestName(description) </ins> if err != nil { v.failf(at, err.Error()) return


Question:
What happened: tried promoting a test with a tag in its full test description. The hierarchy of ginko-relevant AST's was . The tag was a in the top level . The full test description only came from , so the tag was missed. What you expected to happen: The conformance test list generator should have logged and ERROR and failed a test on the PR, calling out Disruptive as an invalid tag How to reproduce it (as minimally and precisely as possible): Check out locally and follow the directions in to generate the conformance list. The invalid test is in the list. Anything else we need to know?: Is there a function we can use to get the full test description from Ginkgo instead of rolling our own? If not, we should probably be maintaining a stack rather than just the last FYI who ran into this FYI who wrote the code to keep track of last
/sig architecture /area conformance
/milestone v1.16
/priority important-soon
/assign
GitHub didn't allow me to assign the following users: devaips. Note that only and repo collaborators can be assigned and that 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

} func (v *visitor) getDescription(value string) string { <del> if len(v.lastDescribe.lastContext.text) > 0 { return strings.Trim(v.lastDescribe.text, """) + " " + strings.Trim(v.lastDescribe.lastContext.text, """) + " " + strings.Trim(value, """) </del> <ins> tokens := []string{} for _, describe := range v.describes { tokens = append(tokens, describe.text) if len(describe.lastContext.text) > 0 { tokens = append(tokens, describe.lastContext.text) } } tokens = append(tokens, value) trimmed := []string{} for _, token := range tokens { trimmed = append(trimmed, strings.Trim(token, """)) </ins> } <del> return strings.Trim(v.lastDescribe.text, """) + " " + strings.Trim(value, """) </del> <ins> return strings.Join(trimmed, " ") </ins> } var (


Question:
What happened: tried promoting a test with a tag in its full test description. The hierarchy of ginko-relevant AST's was . The tag was a in the top level . The full test description only came from , so the tag was missed. What you expected to happen: The conformance test list generator should have logged and ERROR and failed a test on the PR, calling out Disruptive as an invalid tag How to reproduce it (as minimally and precisely as possible): Check out locally and follow the directions in to generate the conformance list. The invalid test is in the list. Anything else we need to know?: Is there a function we can use to get the full test description from Ginkgo instead of rolling our own? If not, we should probably be maintaining a stack rather than just the last FYI who ran into this FYI who wrote the code to keep track of last
/sig architecture /area conformance
/milestone v1.16
/priority important-soon
/assign
GitHub didn't allow me to assign the following users: devaips. Note that only and repo collaborators can be assigned and that 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

// It() with a manually embedded [Conformance] tag, which it will complain // about. func (v *visitor) Visit(node ast.Node) (w ast.Visitor) { <ins> lastDescribe := len(v.describes) - 1 </ins> switch t := node.(type) { case *ast.CallExpr: if name := v.matchFuncName(t, regexDescribe); name != "" && len(t.Args) >= 2 { <del> v.lastDescribe = describe{text: name} </del> <ins> v.describes = append(v.describes, describe{text: name, rparen: t.Rparen}) </ins> } else if name := v.matchFuncName(t, regexContext); name != "" && len(t.Args) >= 2 { <del> v.lastDescribe.lastContext = context{text: name} </del> <ins> if lastDescribe > -1 { v.describes[lastDescribe].lastContext = context{text: name} } </ins> } else if v.isConformanceCall(t) { totalConfTests++ v.emit(t.Args[0])


Question:
What happened: tried promoting a test with a tag in its full test description. The hierarchy of ginko-relevant AST's was . The tag was a in the top level . The full test description only came from , so the tag was missed. What you expected to happen: The conformance test list generator should have logged and ERROR and failed a test on the PR, calling out Disruptive as an invalid tag How to reproduce it (as minimally and precisely as possible): Check out locally and follow the directions in to generate the conformance list. The invalid test is in the list. Anything else we need to know?: Is there a function we can use to get the full test description from Ginkgo instead of rolling our own? If not, we should probably be maintaining a stack rather than just the last FYI who ran into this FYI who wrote the code to keep track of last
/sig architecture /area conformance
/milestone v1.16
/priority important-soon
/assign
GitHub didn't allow me to assign the following users: devaips. Note that only and repo collaborators can be assigned and that 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

return nil } } <ins> // If we're past the position of the last describe's rparen, pop the describe off if lastDescribe > -1 && node != nil { if node.Pos() > v.describes[lastDescribe].rparen { v.describes = v.describes[:lastDescribe] } } </ins> return v }


Question:
What happened: tried promoting a test with a tag in its full test description. The hierarchy of ginko-relevant AST's was . The tag was a in the top level . The full test description only came from , so the tag was missed. What you expected to happen: The conformance test list generator should have logged and ERROR and failed a test on the PR, calling out Disruptive as an invalid tag How to reproduce it (as minimally and precisely as possible): Check out locally and follow the directions in to generate the conformance list. The invalid test is in the list. Anything else we need to know?: Is there a function we can use to get the full test description from Ginkgo instead of rolling our own? If not, we should probably be maintaining a stack rather than just the last FYI who ran into this FYI who wrote the code to keep track of last
/sig architecture /area conformance
/milestone v1.16
/priority important-soon
/assign
GitHub didn't allow me to assign the following users: devaips. Note that only and repo collaborators can be assigned and that 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

Description: `By default the stdout and stderr from the process being executed in a pod MUST be sent to the pod's logs.` + "nn"}}, }, <ins> // SIGDescribe + KubeDescribe + It, Describe + KubeDescribe + It {"e2e/foo.go", ` var _ = framework.SIGDescribe("Feature", func() { KubeDescribe("Described by", func() { // Description: description1 framework.ConformanceIt("A ConformanceIt", func() {}) }) Describe("Also described via", func() { KubeDescribe("A nested", func() { // Description: description2 framework.ConformanceIt("ConformanceIt", func() {}) }) }) })`, []conformanceData{ {URL: "https://github.com/kubernetes/kubernetes/tree/master/e2e/foo.go#L6", TestName: "Feature Described by A ConformanceIt", Description: "description1nn"}, {URL: "https://github.com/kubernetes/kubernetes/tree/master/e2e/foo.go#L11", TestName: "Feature Also described via A nested ConformanceIt", Description: "description2nn"}, }}, </ins> // KubeDescribe + Context + It {"e2e/foo.go", ` var _ = framework.KubeDescribe("Feature", func() {


Question:
What happened: tried promoting a test with a tag in its full test description. The hierarchy of ginko-relevant AST's was . The tag was a in the top level . The full test description only came from , so the tag was missed. What you expected to happen: The conformance test list generator should have logged and ERROR and failed a test on the PR, calling out Disruptive as an invalid tag How to reproduce it (as minimally and precisely as possible): Check out locally and follow the directions in to generate the conformance list. The invalid test is in the list. Anything else we need to know?: Is there a function we can use to get the full test description from Ginkgo instead of rolling our own? If not, we should probably be maintaining a stack rather than just the last FYI who ran into this FYI who wrote the code to keep track of last
/sig architecture /area conformance
/milestone v1.16
/priority important-soon
/assign
GitHub didn't allow me to assign the following users: devaips. Note that only and repo collaborators can be assigned and that 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

*confDoc = true tests := scanfile(test.filename, code) if !reflect.DeepEqual(tests, test.output) { <del> t.Errorf("code:n%sngot  %vnwant %v", </del> <ins> t.Errorf("code:n%sngot  %+vnwant %+v", </ins> code, tests, test.output) } }


Question: <!-- 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: attach/WaitForAttach timeout value is too small in CSI driver, it's all 15s which is really too small: Compared to built-in driver timeout, it's really too small: is , total is 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 ): 1.13 - 1.15 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 storage /assign

// TODO (vladimirvivien) would be nice to name socket with a .sock extension // for consistency. csiAddrTemplate = "/var/lib/kubelet/plugins/%v/csi.sock" <del> csiTimeout      = 15 * time.Second </del> <ins> csiTimeout      = 2 * time.Minute </ins> volNameSep      = "^" volDataFileName = "vol_data.json" fsTypeBlockName = "block"


Question:
<!-- 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: cd $ $ make ../image- bin webhook ../image- line 145: GOARM: unbound variable Makefile:23: recipe for target 'bin' failed make: [bin] Error 1 What you expected to happen: The binary or image should be built successfully. How to reproduce it (as minimally and precisely as possible): see my desc above, type "make" will see the error message. Anything else we need to know?: Environment*: Kubernetes version (use ): latest Cloud provider or hardware configuration: OS (e.g: ): Ubuntu Kernel (e.g. ): all Install tools: Network plugin and version (if this is a network-related bug): Others:
There are no sig labels on this issue. Please add a sig label by either: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. See the . The in method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
I'm pretty sure this is supposed to be built via from which does default this environment variable.
, thanks for the information! I think the harness of the shell scripts could bring us a little more, GOARM should only been set when the ARCH is ARM Make a binary is possible where a Makefile is presented
That seems reasonable, but we should probably avoid computing this in many places, currently the GOARM=${GOARM:-7} is going to always be 7 when building in the currently supported way. We should change that if we're going to compute it elsewhere. cc-ing for test/images fun ...

export DOCKER_CLI_EXPERIMENTAL := enabled # golang version should match the golang version from https://github.com/coreos/etcd/releases for the current ETCD_VERSION. GOLANG_VERSION?=1.10.4 <del> GOARM=7 </del> <ins> GOARM?=7 </ins> TEMP_DIR:=$(shell mktemp -d) ifeq ($(ARCH),amd64)


Question:
<!-- 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: cd $ $ make ../image- bin webhook ../image- line 145: GOARM: unbound variable Makefile:23: recipe for target 'bin' failed make: [bin] Error 1 What you expected to happen: The binary or image should be built successfully. How to reproduce it (as minimally and precisely as possible): see my desc above, type "make" will see the error message. Anything else we need to know?: Environment*: Kubernetes version (use ): latest Cloud provider or hardware configuration: OS (e.g: ): Ubuntu Kernel (e.g. ): all Install tools: Network plugin and version (if this is a network-related bug): Others:
There are no sig labels on this issue. Please add a sig label by either: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. See the . The in method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
I'm pretty sure this is supposed to be built via from which does default this environment variable.
, thanks for the information! I think the harness of the shell scripts could bring us a little more, GOARM should only been set when the ARCH is ARM Make a binary is possible where a Makefile is presented
That seems reasonable, but we should probably avoid computing this in many places, currently the GOARM=${GOARM:-7} is going to always be 7 when building in the currently supported way. We should change that if we're going to compute it elsewhere. cc-ing for test/images fun ...

# Download etcd in a golang container and cross-compile it statically # For each release create a tmp dir 'etcd_release_tmp_dir' and unpack the release tar there. <ins> arch_prefix="" ifeq ($(ARCH),arm) arch_prefix="GOARM=$(GOARM)" endif </ins> for version in $(BUNDLED_ETCD_VERSIONS); do  etcd_release_tmp_dir=$(shell mktemp -d);  docker run --interactive -v $${etcd_release_tmp_dir}:/etcdbin golang:$(GOLANG_VERSION) /bin/bash -c  "git clone https://github.com/coreos/etcd /go/src/github.com/coreos/etcd  && cd /go/src/github.com/coreos/etcd  && git checkout v$${version}  <del> && GOARM=$(GOARM) GOARCH=$(ARCH) ./build  </del> <ins> && $(arch_prefix) GOARCH=$(ARCH) ./build  </ins> && cp -f bin/$(ARCH)/etcd* bin/etcd* /etcdbin; echo 'done'";  cp $$etcd_release_tmp_dir/etcd $$etcd_release_tmp_dir/etcdctl $(TEMP_DIR)/;  cp $(TEMP_DIR)/etcd $(TEMP_DIR)/etcd-$$version;


Question:
<!-- 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: cd $ $ make ../image- bin webhook ../image- line 145: GOARM: unbound variable Makefile:23: recipe for target 'bin' failed make: [bin] Error 1 What you expected to happen: The binary or image should be built successfully. How to reproduce it (as minimally and precisely as possible): see my desc above, type "make" will see the error message. Anything else we need to know?: Environment*: Kubernetes version (use ): latest Cloud provider or hardware configuration: OS (e.g: ): Ubuntu Kernel (e.g. ): all Install tools: Network plugin and version (if this is a network-related bug): Others:
There are no sig labels on this issue. Please add a sig label by either: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. See the . The in method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
I'm pretty sure this is supposed to be built via from which does default this environment variable.
, thanks for the information! I think the harness of the shell scripts could bring us a little more, GOARM should only been set when the ARCH is ARM Make a binary is possible where a Makefile is presented
That seems reasonable, but we should probably avoid computing this in many places, currently the GOARM=${GOARM:-7} is going to always be 7 when building in the currently supported way. We should change that if we're going to compute it elsewhere. cc-ing for test/images fun ...

include  ../../hack/make-rules/Makefile.manifest REGISTRY ?= gcr.io/kubernetes-e2e-test-images <del> GOARM=7 </del> <ins> GOARM ?= 7 </ins> QEMUVERSION=v2.9.1 GOLANG_VERSION=1.12.6 export


Question:
<!-- 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: cd $ $ make ../image- bin webhook ../image- line 145: GOARM: unbound variable Makefile:23: recipe for target 'bin' failed make: [bin] Error 1 What you expected to happen: The binary or image should be built successfully. How to reproduce it (as minimally and precisely as possible): see my desc above, type "make" will see the error message. Anything else we need to know?: Environment*: Kubernetes version (use ): latest Cloud provider or hardware configuration: OS (e.g: ): Ubuntu Kernel (e.g. ): all Install tools: Network plugin and version (if this is a network-related bug): Others:
There are no sig labels on this issue. Please add a sig label by either: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. See the . The in method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
I'm pretty sure this is supposed to be built via from which does default this environment variable.
, thanks for the information! I think the harness of the shell scripts could bring us a little more, GOARM should only been set when the ARCH is ARM Make a binary is possible where a Makefile is presented
That seems reasonable, but we should probably avoid computing this in many places, currently the GOARM=${GOARM:-7} is going to always be 7 when building in the currently supported way. We should change that if we're going to compute it elsewhere. cc-ing for test/images fun ...

if [[ $(id -u) != 0 ]]; then sudo=sudo fi <del> "${sudo}" "${KUBE_ROOT}/third_party/multiarch/qemu-user-static/register/register.sh" --reset </del> <ins> ${sudo} "${KUBE_ROOT}/third_party/multiarch/qemu-user-static/register/register.sh" --reset </ins> curl -sSL https://github.com/multiarch/qemu-user-static/releases/download/"${QEMUVERSION}"/x86_64_qemu-"${QEMUARCHS[$arch]}"-static.tar.gz | tar -xz -C "${temp_dir}" # Ensure we don't get surprised by umask settings chmod 0755 "${temp_dir}/qemu-${QEMUARCHS[$arch]}-static"


Question:
<!-- 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: cd $ $ make ../image- bin webhook ../image- line 145: GOARM: unbound variable Makefile:23: recipe for target 'bin' failed make: [bin] Error 1 What you expected to happen: The binary or image should be built successfully. How to reproduce it (as minimally and precisely as possible): see my desc above, type "make" will see the error message. Anything else we need to know?: Environment*: Kubernetes version (use ): latest Cloud provider or hardware configuration: OS (e.g: ): Ubuntu Kernel (e.g. ): all Install tools: Network plugin and version (if this is a network-related bug): Others:
There are no sig labels on this issue. Please add a sig label by either: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. See the . The in method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
I'm pretty sure this is supposed to be built via from which does default this environment variable.
, thanks for the information! I think the harness of the shell scripts could bring us a little more, GOARM should only been set when the ARCH is ARM Make a binary is possible where a Makefile is presented
That seems reasonable, but we should probably avoid computing this in many places, currently the GOARM=${GOARM:-7} is going to always be 7 when building in the currently supported way. We should change that if we're going to compute it elsewhere. cc-ing for test/images fun ...

# This function is for building the go code bin() { <ins> local arch_prefix="" if [[ "${ARCH}" == "arm" ]]; then arch_prefix="GOARM=${GOARM:-7}" fi </ins> for SRC in $@; do docker run --rm -it -v "${TARGET}:${TARGET}:Z" -v "${KUBE_ROOT}":/go/src/k8s.io/kubernetes:Z  golang:"${GOLANG_VERSION}"  /bin/bash -c " cd /go/src/k8s.io/kubernetes/test/images/${SRC_DIR} &&  <del> CGO_ENABLED=0 GOARM=${GOARM} GOARCH=${ARCH} go build -a -installsuffix cgo --ldflags '-w' -o ${TARGET}/${SRC} ./$(dirname "${SRC}")" </del> <ins> CGO_ENABLED=0 ${arch_prefix} GOARCH=${ARCH} go build -a -installsuffix cgo --ldflags '-w' -o ${TARGET}/${SRC} ./$(dirname "${SRC}")" </ins> done }


Question:
<!-- 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: cd $ $ make ../image- bin webhook ../image- line 145: GOARM: unbound variable Makefile:23: recipe for target 'bin' failed make: [bin] Error 1 What you expected to happen: The binary or image should be built successfully. How to reproduce it (as minimally and precisely as possible): see my desc above, type "make" will see the error message. Anything else we need to know?: Environment*: Kubernetes version (use ): latest Cloud provider or hardware configuration: OS (e.g: ): Ubuntu Kernel (e.g. ): all Install tools: Network plugin and version (if this is a network-related bug): Others:
There are no sig labels on this issue. Please add a sig label by either: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. See the . The in method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
I'm pretty sure this is supposed to be built via from which does default this environment variable.
, thanks for the information! I think the harness of the shell scripts could bring us a little more, GOARM should only been set when the ARCH is ARM Make a binary is possible where a Makefile is presented
That seems reasonable, but we should probably avoid computing this in many places, currently the GOARM=${GOARM:-7} is going to always be 7 when building in the currently supported way. We should change that if we're going to compute it elsewhere. cc-ing for test/images fun ...

SRCS=regression-issue-74839 ARCH ?= amd64 TARGET ?= $(CURDIR) <del> GOARM = 7 </del> <ins> GOARM ?= 7 </ins> GOLANG_VERSION ?= latest SRC_DIR = $(notdir $(shell pwd))


Question:
<!-- 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: login system root, and run below command from "test/images" dir, Will fail with below error message, ./image- line 91: : command not found This is cause by the empty string like "" cannot be understood as a shell command. What you expected to happen: image should be built successfully. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): latest Cloud provider or hardware configuration: OS (e.g: ): all Kernel (e.g. ):all Install tools: Network plugin and version (if this is a network-related bug): Others:
There are no sig labels on this issue. Please add a sig label by either: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. See the . The in method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign


Question:
<!-- 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: login system root, and run below command from "test/images" dir, Will fail with below error message, ./image- line 91: : command not found This is cause by the empty string like "" cannot be understood as a shell command. What you expected to happen: image should be built successfully. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): latest Cloud provider or hardware configuration: OS (e.g: ): all Kernel (e.g. ):all Install tools: Network plugin and version (if this is a network-related bug): Others:
There are no sig labels on this issue. Please add a sig label by either: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. See the . The in method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign


Question:
<!-- 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: login system root, and run below command from "test/images" dir, Will fail with below error message, ./image- line 91: : command not found This is cause by the empty string like "" cannot be understood as a shell command. What you expected to happen: image should be built successfully. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): latest Cloud provider or hardware configuration: OS (e.g: ): all Kernel (e.g. ):all Install tools: Network plugin and version (if this is a network-related bug): Others:
There are no sig labels on this issue. Please add a sig label by either: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. See the . The in method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign


Question:
<!-- 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: login system root, and run below command from "test/images" dir, Will fail with below error message, ./image- line 91: : command not found This is cause by the empty string like "" cannot be understood as a shell command. What you expected to happen: image should be built successfully. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): latest Cloud provider or hardware configuration: OS (e.g: ): all Kernel (e.g. ):all Install tools: Network plugin and version (if this is a network-related bug): Others:
There are no sig labels on this issue. Please add a sig label by either: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. See the . The in method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign


Question:
<!-- 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: login system root, and run below command from "test/images" dir, Will fail with below error message, ./image- line 91: : command not found This is cause by the empty string like "" cannot be understood as a shell command. What you expected to happen: image should be built successfully. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): latest Cloud provider or hardware configuration: OS (e.g: ): all Kernel (e.g. ):all Install tools: Network plugin and version (if this is a network-related bug): Others:
There are no sig labels on this issue. Please add a sig label by either: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. See the . The in method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign


Question:
<!-- 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: login system root, and run below command from "test/images" dir, Will fail with below error message, ./image- line 91: : command not found This is cause by the empty string like "" cannot be understood as a shell command. What you expected to happen: image should be built successfully. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): latest Cloud provider or hardware configuration: OS (e.g: ): all Kernel (e.g. ):all Install tools: Network plugin and version (if this is a network-related bug): Others:
There are no sig labels on this issue. Please add a sig label by either: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. See the . The in method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign


Question:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: pull-kubernetes-bazel-test Which test(s) are failing: Test_buildClientCertificateManager Testgrid link: Reason for failure: Anything else we need to know:
/remove-kind failing-test /kind flake /sig scheduling
/sig node

// get an expired CSR (simulating historical output) server.backdate = 2 * time.Hour <del> server.expectUserAgent = "FirstClient" </del> <ins> server.SetExpectUserAgent("FirstClient") </ins> ok, err := r.RotateCerts() if !ok || err != nil { t.Fatalf("unexpected rotation err: %t %v", ok, err)


Question:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: pull-kubernetes-bazel-test Which test(s) are failing: Test_buildClientCertificateManager Testgrid link: Reason for failure: Anything else we need to know:
/remove-kind failing-test /kind flake /sig scheduling
/sig node

// if m.Current() == nil, then we try again and get a valid // client server.backdate = 0 <del> server.expectUserAgent = "FirstClient" </del> <ins> server.SetExpectUserAgent("FirstClient") </ins> if ok, err := r.RotateCerts(); !ok || err != nil { t.Fatalf("unexpected rotation err: %t %v", ok, err) }


Question:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: pull-kubernetes-bazel-test Which test(s) are failing: Test_buildClientCertificateManager Testgrid link: Reason for failure: Anything else we need to know:
/remove-kind failing-test /kind flake /sig scheduling
/sig node

} // if m.Current() != nil, then we should use the second client <del> server.expectUserAgent = "SecondClient" </del> <ins> server.SetExpectUserAgent("SecondClient") </ins> if ok, err := r.RotateCerts(); !ok || err != nil { t.Fatalf("unexpected rotation err: %t %v", ok, err) }


Question:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: pull-kubernetes-bazel-test Which test(s) are failing: Test_buildClientCertificateManager Testgrid link: Reason for failure: Anything else we need to know:
/remove-kind failing-test /kind flake /sig scheduling
/sig node

serverCA         *x509.Certificate backdate         time.Duration <ins> userAgentLock   sync.Mutex </ins> expectUserAgent string lock sync.Mutex csr  *certapi.CertificateSigningRequest } <ins> func (s *csrSimulator) SetExpectUserAgent(a string) { s.userAgentLock.Lock() defer s.userAgentLock.Unlock() s.expectUserAgent = a } func (s *csrSimulator) ExpectUserAgent() string { s.userAgentLock.Lock() defer s.userAgentLock.Unlock() return s.expectUserAgent } </ins> func (s *csrSimulator) ServeHTTP(w http.ResponseWriter, req *http.Request) { s.lock.Lock() defer s.lock.Unlock()


Question:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: pull-kubernetes-bazel-test Which test(s) are failing: Test_buildClientCertificateManager Testgrid link: Reason for failure: Anything else we need to know:
/remove-kind failing-test /kind flake /sig scheduling
/sig node

q := req.URL.Query() q.Del("timeout") q.Del("timeoutSeconds") <ins> q.Del("allowWatchBookmarks") </ins> req.URL.RawQuery = q.Encode() t.Logf("Request %q %q %q", req.Method, req.URL, req.UserAgent()) <del> if len(s.expectUserAgent) > 0 && req.UserAgent() != s.expectUserAgent { </del> <ins> if a := s.ExpectUserAgent(); len(a) > 0 && req.UserAgent() != a { </ins> t.Errorf("Unexpected user agent: %s", req.UserAgent()) }


Question:
What happened: The new TestScorePlugin for the scheduler framework is flaky How to reproduce it (as minimally and precisely as possible): An example: Anything else we need to know?: The test evaluates that a pod should be scheduled on specific node with a higher score. I think the test sometimes fails because the higher score node that the test creates didn't propagate yet to the scheduler (i.e., the node exists in etcd, but scheduler hasn't been notified that it exists yet, and so it is not evaluated at all). /kind bug /sig scheduling /assign
/kind flake

if sp.failScore { return 0, framework.NewStatus(framework.Error, fmt.Sprintf("injecting failure for pod %v", p.Name)) } score := 10 <del> if nodeName == sp.highScoreNode { </del> <ins> if sp.numCalled == 1 { // The first node is scored the highest, the rest is scored lower. sp.highScoreNode = nodeName </ins> score = 100 } return score, nil


Question:
What happened: The new TestScorePlugin for the scheduler framework is flaky How to reproduce it (as minimally and precisely as possible): An example: Anything else we need to know?: The test evaluates that a pod should be scheduled on specific node with a higher score. I think the test sometimes fails because the higher score node that the test creates didn't propagate yet to the scheduler (i.e., the node exists in etcd, but scheduler hasn't been notified that it exists yet, and so it is not evaluated at all). /kind bug /sig scheduling /assign
/kind flake

cs := context.clientSet // Add multiple nodes, one of them will be scored much higher than the others. <del> nodes, err := createNodes(cs, "test-node", nil, 10) </del> <ins> _, err := createNodes(cs, "test-node", nil, 10) </ins> if err != nil { t.Fatalf("Cannot create nodes: %v", err) } <del> scPlugin.highScoreNode = nodes[3].Name </del> for i, fail := range []bool{false, true} { scPlugin.failScore = fail


Question:
<!-- 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: Error msg override when saveVolumeData fails. What you expected to happen: return the right error. 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 storage
/assign

if err := saveVolumeData(dataDir, volDataFileName, volData); err != nil { klog.Error(log("failed to save volume info data: %v", err)) <del> if err := os.RemoveAll(dataDir); err != nil { klog.Error(log("failed to remove dir after error [%s]: %v", dataDir, err)) return nil, err </del> <ins> if removeErr := os.RemoveAll(dataDir); removeErr != nil { klog.Error(log("failed to remove dir after error [%s]: %v", dataDir, removeErr)) </ins> } return nil, err }


Question:
What happened: When using a yaml file for input, silently fails at the first missing resource, not returning any further results. What you expected to happen: Searching with cli arguments properly ignores missing resources and continues the query, eg: Would expect similar results with a file input, eg: How to reproduce it (as minimally and precisely as possible): With an input file of : the command fails at apparently the first missing resource: Note: that rearranging the inputs in (so that the missing resource is last) produces the "expected" output: Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: local OS (e.g: ): fedora 30 Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: x-ref:
/sig cli
/assign
Got around to reproducing it and can confirm that I'm getting the same behavior. I'm looking into fixing it now
thanks, any updates on this?
I've learned that in the case of a fake entry, kubectl stops sending API get requests altogether. Learned by running kubectl get -f --ignore-not-found --v=10, the result is shown below. Till now I've been looking into the cobra command framework but now I'm trying to find out where kubectl is making these API calls from(working on finding out where this connection is happening from Slack+debugging, I've asked a more detailed question here ). <img width="1440" alt="Screen Shot 2019-08-12 at 4 13 41 PM" src="https://user-"
that's an interesting find, definitely helpful. When I looked into this I got to the section of get's main run function, and it seems like it should be continuing on any errors (see ) but maybe the ResourceBuilder is actually stopping when it hits a 404?
This behavior comes from where the not found errors are being ignored and where the input list is flattened. Errors are ignored here: While flattening occurs here: As the visitor iterates through the objects in the list if an error occurs, such as not found, it will stop iterating over the objects in the list and return that not found error. The logic will then ignore it and continue. Any objects that came before the not found object in the list will have been visited and will then be included in the output. To make the behavior consistent between the two ways of getting the set of objects, the would need to be updated to support filtering errors.
Just submitted a PR adding that functionality to the FlattenListVisitor. The behavior is now consistent between the two methods.

// FlattenListVisitor flattens any objects that runtime.ExtractList recognizes as a list // - has an "Items" public field that is a slice of runtime.Objects or objects satisfying <del> // that interface - into multiple Infos. An error on any sub item (for instance, if a List // contains an object that does not have a registered client or resource) will terminate // the visit. // TODO: allow errors to be aggregated? </del> <ins> // that interface - into multiple Infos. Returns nil in the case of no errors. // When an error is hit on sub items (for instance, if a List contains an object that does // not have a registered client or resource), returns an aggregate error. </ins> type FlattenListVisitor struct { visitor Visitor typer   runtime.ObjectTyper


Question:
What happened: When using a yaml file for input, silently fails at the first missing resource, not returning any further results. What you expected to happen: Searching with cli arguments properly ignores missing resources and continues the query, eg: Would expect similar results with a file input, eg: How to reproduce it (as minimally and precisely as possible): With an input file of : the command fails at apparently the first missing resource: Note: that rearranging the inputs in (so that the missing resource is last) produces the "expected" output: Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: local OS (e.g: ): fedora 30 Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: x-ref:
/sig cli
/assign
Got around to reproducing it and can confirm that I'm getting the same behavior. I'm looking into fixing it now
thanks, any updates on this?
I've learned that in the case of a fake entry, kubectl stops sending API get requests altogether. Learned by running kubectl get -f --ignore-not-found --v=10, the result is shown below. Till now I've been looking into the cobra command framework but now I'm trying to find out where kubectl is making these API calls from(working on finding out where this connection is happening from Slack+debugging, I've asked a more detailed question here ). <img width="1440" alt="Screen Shot 2019-08-12 at 4 13 41 PM" src="https://user-"
that's an interesting find, definitely helpful. When I looked into this I got to the section of get's main run function, and it seems like it should be continuing on any errors (see ) but maybe the ResourceBuilder is actually stopping when it hits a 404?
This behavior comes from where the not found errors are being ignored and where the input list is flattened. Errors are ignored here: While flattening occurs here: As the visitor iterates through the objects in the list if an error occurs, such as not found, it will stop iterating over the objects in the list and return that not found error. The logic will then ignore it and continue. Any objects that came before the not found object in the list will have been visited and will then be included in the output. To make the behavior consistent between the two ways of getting the set of objects, the would need to be updated to support filtering errors.
Just submitted a PR adding that functionality to the FlattenListVisitor. The behavior is now consistent between the two methods.

if info.Mapping != nil && !info.Mapping.GroupVersionKind.Empty() { preferredGVKs = append(preferredGVKs, info.Mapping.GroupVersionKind) } <ins> errs := []error{} </ins> for i := range items { item, err := v.mapper.infoForObject(items[i], v.typer, preferredGVKs) if err != nil { <del> return err </del> <ins> errs = append(errs, err) continue </ins> } if len(info.ResourceVersion) != 0 { item.ResourceVersion = info.ResourceVersion } if err := fn(item, nil); err != nil { <del> return err </del> <ins> errs = append(errs, err) </ins> } } <del> return nil </del> <ins> return utilerrors.NewAggregate(errs) </ins> }) }


Question:
What happened: When using a yaml file for input, silently fails at the first missing resource, not returning any further results. What you expected to happen: Searching with cli arguments properly ignores missing resources and continues the query, eg: Would expect similar results with a file input, eg: How to reproduce it (as minimally and precisely as possible): With an input file of : the command fails at apparently the first missing resource: Note: that rearranging the inputs in (so that the missing resource is last) produces the "expected" output: Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: local OS (e.g: ): fedora 30 Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: x-ref:
/sig cli
/assign
Got around to reproducing it and can confirm that I'm getting the same behavior. I'm looking into fixing it now
thanks, any updates on this?
I've learned that in the case of a fake entry, kubectl stops sending API get requests altogether. Learned by running kubectl get -f --ignore-not-found --v=10, the result is shown below. Till now I've been looking into the cobra command framework but now I'm trying to find out where kubectl is making these API calls from(working on finding out where this connection is happening from Slack+debugging, I've asked a more detailed question here ). <img width="1440" alt="Screen Shot 2019-08-12 at 4 13 41 PM" src="https://user-"
that's an interesting find, definitely helpful. When I looked into this I got to the section of get's main run function, and it seems like it should be continuing on any errors (see ) but maybe the ResourceBuilder is actually stopping when it hits a 404?
This behavior comes from where the not found errors are being ignored and where the input list is flattened. Errors are ignored here: While flattening occurs here: As the visitor iterates through the objects in the list if an error occurs, such as not found, it will stop iterating over the objects in the list and return that not found error. The logic will then ignore it and continue. Any objects that came before the not found object in the list will have been visited and will then be included in the output. To make the behavior consistent between the two ways of getting the set of objects, the would need to be updated to support filtering errors.
Just submitted a PR adding that functionality to the FlattenListVisitor. The behavior is now consistent between the two methods.

import ( "bytes" <ins> "errors" </ins> "fmt" "io" "io/ioutil" <ins> "strings" </ins> "testing" "time"


Question:
What happened: When using a yaml file for input, silently fails at the first missing resource, not returning any further results. What you expected to happen: Searching with cli arguments properly ignores missing resources and continues the query, eg: Would expect similar results with a file input, eg: How to reproduce it (as minimally and precisely as possible): With an input file of : the command fails at apparently the first missing resource: Note: that rearranging the inputs in (so that the missing resource is last) produces the "expected" output: Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: local OS (e.g: ): fedora 30 Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: x-ref:
/sig cli
/assign
Got around to reproducing it and can confirm that I'm getting the same behavior. I'm looking into fixing it now
thanks, any updates on this?
I've learned that in the case of a fake entry, kubectl stops sending API get requests altogether. Learned by running kubectl get -f --ignore-not-found --v=10, the result is shown below. Till now I've been looking into the cobra command framework but now I'm trying to find out where kubectl is making these API calls from(working on finding out where this connection is happening from Slack+debugging, I've asked a more detailed question here ). <img width="1440" alt="Screen Shot 2019-08-12 at 4 13 41 PM" src="https://user-"
that's an interesting find, definitely helpful. When I looked into this I got to the section of get's main run function, and it seems like it should be continuing on any errors (see ) but maybe the ResourceBuilder is actually stopping when it hits a 404?
This behavior comes from where the not found errors are being ignored and where the input list is flattened. Errors are ignored here: While flattening occurs here: As the visitor iterates through the objects in the list if an error occurs, such as not found, it will stop iterating over the objects in the list and return that not found error. The logic will then ignore it and continue. Any objects that came before the not found object in the list will have been visited and will then be included in the output. To make the behavior consistent between the two ways of getting the set of objects, the would need to be updated to support filtering errors.
Just submitted a PR adding that functionality to the FlattenListVisitor. The behavior is now consistent between the two methods.

t.Fatal(spew.Sdump(test.Infos)) } } <ins> func TestFlattenListVisitorWithVisitorError(t *testing.T) { b := newDefaultBuilder(). FilenameParam(false, &FilenameOptions{Recursive: false, Filenames: []string{"../../artifacts/deeply-nested.yaml"}}). Flatten() test := &testVisitor{InjectErr: errors.New("visitor error")} err := b.Do().Visit(test.Handle) if err == nil || !strings.Contains(err.Error(), "visitor error") { t.Fatal(err) } if len(test.Infos) != 6 { t.Fatal(spew.Sdump(test.Infos)) } } </ins>


Question:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: CRI-O e2e Which test(s) are failing: e2e suite [sig-network] Services should be able to change the type from ExternalName to NodePort e2e suite [sig-network] Services should be able to create a functioning NodePort service 19s See link: https://openshift-gce- Since when has it been failing: Anything else we need to know:
/sig network
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry.
/milestone v1.16 /assign FYI Looks like two other release-blocking tests too: - The changes link testgrid gives () suggests two other PR's, but I agree that seems the likely culprit
Based on the , Service is reachable on and but failing to reach on node's IP over nodePort i.e. . From the log, it is not clear why its not reachable on node's internal IP. Could you provide from the CRI-O based node when trying to reach nodePort service. Secondly, need to make sure, node is listening on allocated nodePort. As this issue seems much on system-level, I need to setup k8s cluster/node with CRI-O runtime and troubleshoot to find the root cause.
[sig-network] ESIPP [Slow] [DisabledForLargeClusters] should work from pods [sig-network] Services should only allow access from service loadbalancer source ranges [Slow] seems flaky to me. Most of time execPod starts running and might be terminating immediately after some time which causes this issue. [1.] e2e is failing as might have terminated and so no PodIP leading to invalid . [2.] empty . The same issue had been observed in for E2E and to fix the issue, we introduced execPod deployment to make sure execPod would remain in desired running state. It's better to address this change in another PR and emphasize using pausePod deployment.
Thanks, for helping me setting up CRI-O based cluster. Kubernetes e2e suite [sig-network] Services should be able to change the type from ExternalName to NodePort e2e suite [sig-network] Services should be able to create a functioning NodePort service 19s From log, it is clear that, these services are failing to reach over allocated nodePort. But on my CRIO based testing cluster, they are reachable. or Could you please check if they failing at your end too or it's testgrid Job-specific issue?
Hey, I did some local tests and was able to reproduce the failure. I started the cluster via (check that the variable is correct and does not point to ): Executed the tests by (again, watch out for the variable to be correct): Error output: Since I'm now able to reproduce the issue I can go further in debugging and find out how to fix this. Is anyone furhter, or If not, then I will target for fixing the issue this week. :)
Thanks for reproducing this. FYI we've seem similar failure on , but I haven't reproduced the problem locally yet. We are looking to at least turn on verbose on the test command for debugging:
The issue is that we try to automatically discover the node IP by obtaining its status here: In our setup the node has IP which for sure does not work if we try to access it within the pod. I'm thinking about a proper solution and will propose it as a PR.
If this issue has been triaged, please comment . If you aren't able to handle this issue, consider unassigning yourself and/or adding the label. I am a bot run by vllry.
/assign

testEndpointReachability(clusterIP, sp.Port, sp.Protocol, execPod) } } func testReachabilityOverNodePorts(nodes *v1.NodeList, sp v1.ServicePort, pod *v1.Pod) { internalAddrs := e2enode.CollectAddresses(nodes, v1.NodeInternalIP) externalAddrs := e2enode.CollectAddresses(nodes, v1.NodeExternalIP) for _, internalAddr := range internalAddrs { <ins> // If the node's internal address points to localhost, then we are not // able to test the service reachability via that address if isInvalidOrLocalhostAddress(internalAddr) { e2elog.Logf("skipping testEndpointReachability() for internal adddress %s", internalAddr) continue } </ins> testEndpointReachability(internalAddr, sp.NodePort, sp.Protocol, pod) } for _, externalAddr := range externalAddrs {


Question:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: CRI-O e2e Which test(s) are failing: e2e suite [sig-network] Services should be able to change the type from ExternalName to NodePort e2e suite [sig-network] Services should be able to create a functioning NodePort service 19s See link: https://openshift-gce- Since when has it been failing: Anything else we need to know:
/sig network
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry.
/milestone v1.16 /assign FYI Looks like two other release-blocking tests too: - The changes link testgrid gives () suggests two other PR's, but I agree that seems the likely culprit
Based on the , Service is reachable on and but failing to reach on node's IP over nodePort i.e. . From the log, it is not clear why its not reachable on node's internal IP. Could you provide from the CRI-O based node when trying to reach nodePort service. Secondly, need to make sure, node is listening on allocated nodePort. As this issue seems much on system-level, I need to setup k8s cluster/node with CRI-O runtime and troubleshoot to find the root cause.
[sig-network] ESIPP [Slow] [DisabledForLargeClusters] should work from pods [sig-network] Services should only allow access from service loadbalancer source ranges [Slow] seems flaky to me. Most of time execPod starts running and might be terminating immediately after some time which causes this issue. [1.] e2e is failing as might have terminated and so no PodIP leading to invalid . [2.] empty . The same issue had been observed in for E2E and to fix the issue, we introduced execPod deployment to make sure execPod would remain in desired running state. It's better to address this change in another PR and emphasize using pausePod deployment.
Thanks, for helping me setting up CRI-O based cluster. Kubernetes e2e suite [sig-network] Services should be able to change the type from ExternalName to NodePort e2e suite [sig-network] Services should be able to create a functioning NodePort service 19s From log, it is clear that, these services are failing to reach over allocated nodePort. But on my CRIO based testing cluster, they are reachable. or Could you please check if they failing at your end too or it's testgrid Job-specific issue?
Hey, I did some local tests and was able to reproduce the failure. I started the cluster via (check that the variable is correct and does not point to ): Executed the tests by (again, watch out for the variable to be correct): Error output: Since I'm now able to reproduce the issue I can go further in debugging and find out how to fix this. Is anyone furhter, or If not, then I will target for fixing the issue this week. :)
Thanks for reproducing this. FYI we've seem similar failure on , but I haven't reproduced the problem locally yet. We are looking to at least turn on verbose on the test command for debugging:
The issue is that we try to automatically discover the node IP by obtaining its status here: In our setup the node has IP which for sure does not work if we try to access it within the pod. I'm thinking about a proper solution and will propose it as a PR.
If this issue has been triaged, please comment . If you aren't able to handle this issue, consider unassigning yourself and/or adding the label. I am a bot run by vllry.
/assign

} } <ins> // isInvalidOrLocalhostAddress returns `true` if the provided `ip` is either not // parsable or the loopback address. Otherwise it will return `false`. func isInvalidOrLocalhostAddress(ip string) bool { parsedIP := net.ParseIP(ip) if parsedIP == nil || parsedIP.IsLoopback() { return true } return false } </ins> // testEndpointReachability tests reachability to endpoints (i.e. IP, ServiceName) and ports. Test request is initiated from specified execPod. // TCP and UDP protocol based service are supported at this moment // TODO: add support to test SCTP Protocol based services.


Question:
[x] write e2e tests for all admission operations [x] (for resource APIs) [x] (for discovery docs) [x] switch to v1 admission APIs in e2e - [x] remove skips/time.Sleeps - and promote to conformance tests - AdmissionWebhook should have tests for all stable operations. Those tests should go through the conformance process before being released. This ticket is to help track what operations are yet to be covered by conformance tests. These stable endpoints should be hit by e2e tests tagged with [conformance]. There are tests currently hitting 6 of the corresponding beta endpoints that could be updated to use stable. Tests should be written to exercise the remaining 9 untested stable endpoints as well. These twelve tests could be updated to use the stable API, and subsequently promoted to conformance. / ! ! These will need tests written for them.  untested beta/admissionregistration !
/sig api-machinery
/assign
/area conformance
/assign ^ This is a requirement for graduation to GA.
can we get another apisnoop run? We've coverage for admissionregistration and apiextensions and I'd like to get confirmation from apisnoop that we've got full coverage now.
Keeping this open until tests are actually promoted to conformance
is ready for review. It adds our admission e2e tests to conformance as part of graduation to GA.
is updated currently not hit by any tests, one will need to be updated or written to cover it. Might want to ensure you've promoted one test that hit's each endpoint. !
The PR to do that is at


Question:
[x] write e2e tests for all admission operations [x] (for resource APIs) [x] (for discovery docs) [x] switch to v1 admission APIs in e2e - [x] remove skips/time.Sleeps - and promote to conformance tests - AdmissionWebhook should have tests for all stable operations. Those tests should go through the conformance process before being released. This ticket is to help track what operations are yet to be covered by conformance tests. These stable endpoints should be hit by e2e tests tagged with [conformance]. There are tests currently hitting 6 of the corresponding beta endpoints that could be updated to use stable. Tests should be written to exercise the remaining 9 untested stable endpoints as well. These twelve tests could be updated to use the stable API, and subsequently promoted to conformance. / ! ! These will need tests written for them.  untested beta/admissionregistration !
/sig api-machinery
/assign
/area conformance
/assign ^ This is a requirement for graduation to GA.
can we get another apisnoop run? We've coverage for admissionregistration and apiextensions and I'd like to get confirmation from apisnoop that we've got full coverage now.
Keeping this open until tests are actually promoted to conformance
is ready for review. It adds our admission e2e tests to conformance as part of graduation to GA.
is updated currently not hit by any tests, one will need to be updated or written to cover it. Might want to ensure you've promoted one test that hit's each endpoint. !
The PR to do that is at

"strings" "time" <ins> "k8s.io/utils/pointer" </ins> admissionregistrationv1 "k8s.io/api/admissionregistration/v1" appsv1 "k8s.io/api/apps/v1" v1 "k8s.io/api/core/v1"


Question:
[x] write e2e tests for all admission operations [x] (for resource APIs) [x] (for discovery docs) [x] switch to v1 admission APIs in e2e - [x] remove skips/time.Sleeps - and promote to conformance tests - AdmissionWebhook should have tests for all stable operations. Those tests should go through the conformance process before being released. This ticket is to help track what operations are yet to be covered by conformance tests. These stable endpoints should be hit by e2e tests tagged with [conformance]. There are tests currently hitting 6 of the corresponding beta endpoints that could be updated to use stable. Tests should be written to exercise the remaining 9 untested stable endpoints as well. These twelve tests could be updated to use the stable API, and subsequently promoted to conformance. / ! ! These will need tests written for them.  untested beta/admissionregistration !
/sig api-machinery
/assign
/area conformance
/assign ^ This is a requirement for graduation to GA.
can we get another apisnoop run? We've coverage for admissionregistration and apiextensions and I'd like to get confirmation from apisnoop that we've got full coverage now.
Keeping this open until tests are actually promoted to conformance
is ready for review. It adds our admission e2e tests to conformance as part of graduation to GA.
is updated currently not hit by any tests, one will need to be updated or written to cover it. Might want to ensure you've promoted one test that hit's each endpoint. !
The PR to do that is at

"k8s.io/apimachinery/pkg/apis/meta/v1/unstructured" "k8s.io/apimachinery/pkg/types" "k8s.io/apimachinery/pkg/util/intstr" <ins> "k8s.io/apimachinery/pkg/util/uuid" </ins> utilversion "k8s.io/apimachinery/pkg/util/version" "k8s.io/apimachinery/pkg/util/wait" "k8s.io/client-go/dynamic" clientset "k8s.io/client-go/kubernetes" <ins> "k8s.io/client-go/util/retry" </ins> "k8s.io/kubernetes/test/e2e/framework" e2edeploy "k8s.io/kubernetes/test/e2e/framework/deployment" e2elog "k8s.io/kubernetes/test/e2e/framework/log" e2epod "k8s.io/kubernetes/test/e2e/framework/pod" "k8s.io/kubernetes/test/utils/crd" imageutils "k8s.io/kubernetes/test/utils/image" <del> "k8s.io/utils/pointer" </del> "github.com/onsi/ginkgo" "github.com/onsi/gomega"