jiebi/CodeConvo huggingface dataset:
Change:
What happened: What you expected to happen: EndpointNamespace should be the string name of the namespace used. How to reproduce it (as minimally and precisely as possible): Create a glusterfs PV using an EndpointNamespace entry and run 'kubectl describe pv' on the resulting PV. Anything else we need to know?: Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.2", GitCommit:"", GitTreeState:"clean", BuildDate:"2019-08-05T17:09:13Z", GoVersion:"go1.12.7", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.2", GitCommit:"", GitTreeState:"clean", BuildDate:"2019-08-05T09:15:22Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: Brightbox OS (e.g: ): Ubuntu 18.04.3 LTS Kernel (e.g. ): Linux bionic-vm 4.15.0-58-generic -Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x8664 x8664 x86_64 GNU/Linux Install tools: kubeadm 1.15
/sig cli
/assign

Discussion:
} func printGlusterfsPersistentVolumeSource(glusterfs *corev1.GlusterfsPersistentVolumeSource, w PrefixWriter) { <ins> endpointsNamespace := "<unset>" if glusterfs.EndpointsNamespace != nil { endpointsNamespace = *glusterfs.EndpointsNamespace } </ins> w.Write(LEVEL_2, "Type:tGlusterfs (a Glusterfs mount on the host that shares a pod's lifetime)n"+ "    EndpointsName:t%vn"+ "    EndpointsNamespace:t%vn"+ "    Path:t%vn"+ "    ReadOnly:t%vn", <del> glusterfs.EndpointsName, glusterfs.EndpointsNamespace, glusterfs.Path, glusterfs.ReadOnly) </del> <ins> glusterfs.EndpointsName, endpointsNamespace, glusterfs.Path, glusterfs.ReadOnly) </ins> } func printPersistentVolumeClaimVolumeSource(claim *corev1.PersistentVolumeClaimVolumeSource, w PrefixWriter) {

func TestPersistentVolumeDescriber(t *testing.T) { block := corev1.PersistentVolumeBlock file := corev1.PersistentVolumeFilesystem <ins> foo := "glusterfsendpointname" </ins> deletionTimestamp := metav1.Time{Time: time.Now().UTC().AddDate(-10, 0, 0)} testCases := []struct { name               string

}, }, }, <ins> expectedElements:   []string{"EndpointsNamespace", "<unset>"}, </ins> unexpectedElements: []string{"VolumeMode", "Filesystem"}, }, {

}, expectedElements: []string{"Driver", "VolumeHandle", "ReadOnly", "VolumeAttributes"}, }, <ins> { name:   "test19", plugin: "gluster", pv: &corev1.PersistentVolume{ ObjectMeta: metav1.ObjectMeta{Name: "bar"}, Spec: corev1.PersistentVolumeSpec{ PersistentVolumeSource: corev1.PersistentVolumeSource{ Glusterfs: &corev1.GlusterfsPersistentVolumeSource{ EndpointsNamespace: &foo, }, }, }, }, expectedElements:   []string{"EndpointsNamespace", "glusterfsendpointname"}, unexpectedElements: []string{"VolumeMode", "Filesystem"}, }, </ins> } for _, test := range testCases {
Change:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: docker image built from source doesn't work with below error message, run binary doesn't work either, What you expected to happen: profile could be loaded successfully. How to reproduce it (as minimally and precisely as possible): cd test/images make all WHAT=apparmor-loader create namespace create DaemonSet with the built image check the log of the pod, kubectl logs apparmor-loader-dcbvp -n apparmor Anything else we need to know?: should init the flags in the source. 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

Discussion:
) func main() { <ins> klog.InitFlags(nil) </ins> flag.Usage = func() { fmt.Fprintf(os.Stderr, "Usage: %s [FLAG]... [PROFILE_DIR]...n", os.Args[0]) fmt.Fprintf(os.Stderr, "Load the AppArmor profiles specified in the PROFILE_DIR directories.n")
Change:
I followed the document to create an e2e cluster However, doesn't work after the cluster is up. I got the following error: /cc
/cc
where are you trying to ssh from? Can you ssh to a Linux instance in GCE? If you run do you see ssh keys there? Do any of them match a public key that you have under ? There could be a delay the very first time you try to ssh; we noted this in , but we could add it to the README too. If you try a second time after a couple minutes does it still fail?
Yeah I can ssh to a linux instance in the same cluster. It still fails after a long. I've removed all my ssh keys from cloud metadata, and recreating a cluster. Let me see how it goes this time.
I still got the same error after recreating the cluster. I can ssh into linux nodes in the same cluster just fine.

Discussion:
if (-not (Test-Path $user_dir)) { # If for some reason Create-NewProfile failed to create the user profile # directory just continue on to the next user. <del> continue </del> <ins> return </ins> } # NOTE: there is a race condition here where someone could try to ssh to
Change:
doesn't work for Windows node. After some investigation, I think the problem is that for Docker the log file reads is a symlink to the actual docker container log file. On linux, I believe fsnotify follows symlink by default , so it works on linux. However, on windows I believe it doesn't follow the symlink. I tried to replace the symlink file with an actual file and append log to it, will start working after that. The proposed solution is to explicitly follow the symlink in Kubelet, so that we get more consist behavior across different platforms.
/cc
Note that this happened to be fixed by in HEAD. But we may still want to follow the symlink which is a more proper fix.

Discussion:
"io" "math" "os" <ins> "path/filepath" </ins> "time" "github.com/docker/docker/daemon/logger/jsonfilelog/jsonlog"

// Note that containerID is only needed when following the log, or else // just pass in empty string "". func ReadLogs(ctx context.Context, path, containerID string, opts *LogOptions, runtimeService internalapi.RuntimeService, stdout, stderr io.Writer) error { <ins> // fsnotify has different behavior for symlinks in different platform, // for example it follows symlink on Linux, but not on Windows, // so we explicitly resolve symlinks before reading the logs. // There shouldn't be security issue because the container log // path is owned by kubelet and the container runtime. evaluated, err := filepath.EvalSymlinks(path) if err != nil { return fmt.Errorf("failed to try resolving symlinks in path %q: %v", path, err) } path = evaluated </ins> f, err := os.Open(path) if err != nil { return fmt.Errorf("failed to open log file %q: %v", path, err)
Change:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which test(s) are failing: When is specified in kubetest, the is trying to delete all namespaces except , and (see ) With Kubernetes 1.14 the features was enabled which creates their lease objects in a separate namespace which could sometimes not be cleaned up correctly. () Since when has it been failing: Testgrid link: Reason for failure: The SetupSuite is trying to delete system namespace Anything else we need to know:
/sig testing

Discussion:
"k8s.io/klog" <ins> corev1 "k8s.io/api/core/v1" </ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/kubernetes/pkg/version" e2elog "k8s.io/kubernetes/test/e2e/framework/log"

metav1.NamespaceSystem, metav1.NamespaceDefault, metav1.NamespacePublic, <ins> corev1.NamespaceNodeLease, </ins> }) if err != nil { e2elog.Failf("Error deleting orphaned namespaces: %v", err)
Change:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: Working on a generalization of the max-in-flight filter, I noticed it is positioned inconsistently in the secure vs insecure handler chains. At I see it is very late in the secure handler chain, just before authorization. At I see it comes much earlier, preceding audit, authentication, and timeout (unlike the secured chain). NB: by "early" and "late" here I refer to the order in which the filters run, which is the opposite of the order in which they are constructed. What you expected to happen: I expected the two handler chains to put the filters they have in common in the same order. 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:
/cc

Discussion:
// BuildInsecureHandlerChain sets up the server to listen to http. Should be removed. func BuildInsecureHandlerChain(apiHandler http.Handler, c *server.Config) http.Handler { handler := apiHandler <ins> handler = genericfilters.WithMaxInFlightLimit(handler, c.MaxRequestsInFlight, c.MaxMutatingRequestsInFlight, c.LongRunningFunc) </ins> handler = genericapifilters.WithAudit(handler, c.AuditBackend, c.AuditPolicyChecker, c.LongRunningFunc) handler = genericapifilters.WithAuthentication(handler, server.InsecureSuperuser{}, nil, nil) handler = genericfilters.WithCORS(handler, c.CorsAllowedOriginList, nil, nil, nil, "true") handler = genericfilters.WithTimeoutForNonLongRunningRequests(handler, c.LongRunningFunc, c.RequestTimeout) <del> handler = genericfilters.WithMaxInFlightLimit(handler, c.MaxRequestsInFlight, c.MaxMutatingRequestsInFlight, c.LongRunningFunc) </del> handler = genericfilters.WithWaitGroup(handler, c.LongRunningFunc, c.HandlerChainWaitGroup) handler = genericapifilters.WithRequestInfo(handler, server.NewRequestInfoResolver(c)) handler = genericapifilters.WithCacheControl(handler)
Change:
What happened: Ref , there are some GCE wrapper functions that don't properly respect the passed in context, e.g: We need to figure out a better way to handle this, but I'm hesitate to change it right away without enough thinking. File this issue for tracking purpose. cc
/sig cloud-provider /area provider/gcp
How about checking the deadline of the passed in ctx: If the timeout is longer than what cloud.ContextWithCallTimeout expects, create context with 1 hour timeout.
We should consider () as well as deadline. How about monitor user's timeout like this? cancel our context when timeout.
If the time period till ctx.Deadline() is shorter than 1 hour, there is no need to call cloud.ContextWithCallTimeout(). We can use ctx directly in that case.
Another option may be better:
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

Discussion:
"fmt" "net/http" "path" <ins> "time" </ins> <del> compute "google.golang.org/api/compute/v1" </del> <ins> "google.golang.org/api/compute/v1" </ins> "k8s.io/apimachinery/pkg/types" "k8s.io/klog" <del> "github.com/GoogleCloudPlatform/k8s-cloud-provider/pkg/cloud" </del> "github.com/GoogleCloudPlatform/k8s-cloud-provider/pkg/cloud/filter" "github.com/GoogleCloudPlatform/k8s-cloud-provider/pkg/cloud/meta" cloudprovider "k8s.io/cloud-provider"

// ListRoutes in the cloud environment. func (g *Cloud) ListRoutes(ctx context.Context, clusterName string) ([]*cloudprovider.Route, error) { <del> timeoutCtx, cancel := cloud.ContextWithCallTimeout() </del> <ins> timeoutCtx, cancel := context.WithTimeout(ctx, 1*time.Hour) </ins> defer cancel() mc := newRoutesMetricContext("list")

// CreateRoute in the cloud environment. func (g *Cloud) CreateRoute(ctx context.Context, clusterName string, nameHint string, route *cloudprovider.Route) error { <del> timeoutCtx, cancel := cloud.ContextWithCallTimeout() </del> <ins> timeoutCtx, cancel := context.WithTimeout(ctx, 1*time.Hour) </ins> defer cancel() mc := newRoutesMetricContext("create")

// DeleteRoute from the cloud environment. func (g *Cloud) DeleteRoute(ctx context.Context, clusterName string, route *cloudprovider.Route) error { <del> timeoutCtx, cancel := cloud.ContextWithCallTimeout() </del> <ins> timeoutCtx, cancel := context.WithTimeout(ctx, 1*time.Hour) </ins> defer cancel() mc := newRoutesMetricContext("delete")
Change:
Which jobs are failing: pull-kubernetes-bazel-test Which test(s) are failing: //pkg/kubelet/dockershim/network/cni:godefaulttest Since when has it been failing: Unsure, it doesn't appear in triage, but I see it regularly in PRs. Testgrid link: This package is the top flake currently Reason for failure: Anything else we need to know: /sig node /sig network
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/assign
The test results have the following three phenomena. b c

Discussion:
import ( "bytes" <del> "context" </del> "encoding/json" "fmt" "io/ioutil"

f, err = os.Create(pluginExec) require.NoError(t, err) <ins> // TODO: use mock instead of fake shell script plugin </ins> const execScriptTempl = `#!/usr/bin/env bash <ins> echo -n "{ "cniVersion": "{{.CNIVersion}}", "ip4": { "ip": "{{.PodIP}}/24" } }" if [ "$CNI_COMMAND" = "VERSION" ]; then exit fi </ins> cat > {{.InputFile}} env > {{.OutputEnv}} echo "%@" >> {{.OutputEnv}} export $(echo ${CNI_ARGS} | sed 's/;/ /g') &> /dev/null mkdir -p {{.OutputDir}} &> /dev/null <del> echo -n "$CNI_COMMAND $CNI_NETNS $K8S_POD_NAMESPACE $K8S_POD_NAME $K8S_POD_INFRA_CONTAINER_ID" >& {{.OutputFile}} echo -n "{ "cniVersion": "{{.CNIVersion}}", "ip4": { "ip": "{{.PodIP}}/24" } }"` </del> <ins> echo -n "$CNI_COMMAND $CNI_NETNS $K8S_POD_NAMESPACE $K8S_POD_NAME $K8S_POD_INFRA_CONTAINER_ID" >& {{.OutputFile}}` </ins> inputFile := path.Join(testDataDir, binName+".in") outputFile := path.Join(testDataDir, binName+".out")

cniPlugin.execer = fexec cniPlugin.loNetwork.CNIConfig = mockLoCNI <del> mockLoCNI.On("AddNetworkList", context.TODO(), cniPlugin.loNetwork.NetworkConfig, mock.AnythingOfType("*libcni.RuntimeConf")).Return(&types020.Result{IP4: &types020.IPConfig{IP: net.IPNet{IP: []byte{127, 0, 0, 1}}}}, nil) mockLoCNI.On("DelNetworkList", context.TODO(), cniPlugin.loNetwork.NetworkConfig, mock.AnythingOfType("*libcni.RuntimeConf")).Return(nil) </del> <ins> mockLoCNI.On("AddNetworkList", mock.AnythingOfType("*context.emptyCtx"), cniPlugin.loNetwork.NetworkConfig, mock.AnythingOfType("*libcni.RuntimeConf")).Return(&types020.Result{IP4: &types020.IPConfig{IP: net.IPNet{IP: []byte{127, 0, 0, 1}}}}, nil) mockLoCNI.On("DelNetworkList", mock.AnythingOfType("*context.emptyCtx"), cniPlugin.loNetwork.NetworkConfig, mock.AnythingOfType("*libcni.RuntimeConf")).Return(nil) </ins> // Check that status returns an error if err := cniPlugin.Status(); err == nil {
Change:
What happened: CRI CPU metrics are incorrect when using a large number of cores, due to a overflow. What you expected to happen: CPU metrics should be correct for arbitrarily high numbers of cores. How to reproduce it (as minimally and precisely as possible): Deploy a pod with 20 CPU units allocated, and fetch the CRI metrics. The metrics will be incorrect. Environment: Kubernetes version (use ): 1.14.4 CRI: CRI-O cc cc /sig node /sig scalability
How did you get the cri cpu metrics?
kubelet /stats/summary API. For "large" pods, we confirmed that cri-o/cgroupfs calculations were being generated correctly and CPU data overflows at the kubelet CRI stats provider layer. Overflows of CPU data in /stats/summary results in metrics-server having bad data which further propagates to the HPA scaling Pods incorrectly.

Discussion:
if nanoSeconds <= 0 { return nil, fmt.Errorf("zero or negative interval (%v - %v)", newStats.Timestamp, cachedStats.Timestamp) } <del> usageNanoCores := (newStats.UsageCoreNanoSeconds.Value - cachedStats.UsageCoreNanoSeconds.Value) * uint64(time.Second/time.Nanosecond) / uint64(nanoSeconds) </del> <ins> usageNanoCores := uint64(float64(newStats.UsageCoreNanoSeconds.Value-cachedStats.UsageCoreNanoSeconds.Value) / float64(nanoSeconds) * float64(time.Second/time.Nanosecond)) </ins> // Update cache with new value. usageToUpdate := usageNanoCores

var value0 uint64 var value1 uint64 = 10000000000 <ins> // Test with a large container of 100+ CPUs var value2 uint64 = 188427786383 </ins> tests := []struct { desc          string cpuUsageCache map[string]*cpuUsageRecord

}, expected: &value1, }, <ins> { desc: "should return correct value if elapsed UsageCoreNanoSeconds exceeds 18446744073", stats: &runtimeapi.ContainerStats{ Attributes: &runtimeapi.ContainerAttributes{ Id: "1", }, Cpu: &runtimeapi.CpuUsage{ Timestamp: int64(time.Second / time.Nanosecond), UsageCoreNanoSeconds: &runtimeapi.UInt64Value{ Value: 68172016162105, }, }, }, cpuUsageCache: map[string]*cpuUsageRecord{ "1": { stats: &runtimeapi.CpuUsage{ Timestamp: 0, UsageCoreNanoSeconds: &runtimeapi.UInt64Value{ Value: 67983588375722, }, }, }, }, expected: &value2, }, </ins> } for _, test := range tests {
Change:
The upper test heavily flakes in master:
/cc
Hey I think this might have something to do with your changes. Something is definitely a bit off. It probably is a faulty test...
duplicate of
Looks like an occasional failure, and I don't think this is caused by my code change because I run tests for a few times, and sometime it is passed.... Still I can help to locate the root cause.
I revert my code change, test still fails from time to time...
I think i've found out the root cause, I'll pull a request soon, . cc

Discussion:
import ( "bytes" <del> "context" </del> "encoding/json" "fmt" "io/ioutil"

f, err = os.Create(pluginExec) require.NoError(t, err) <ins> // TODO: use mock instead of fake shell script plugin </ins> const execScriptTempl = `#!/usr/bin/env bash <ins> echo -n "{ "cniVersion": "{{.CNIVersion}}", "ip4": { "ip": "{{.PodIP}}/24" } }" if [ "$CNI_COMMAND" = "VERSION" ]; then exit fi </ins> cat > {{.InputFile}} env > {{.OutputEnv}} echo "%@" >> {{.OutputEnv}} export $(echo ${CNI_ARGS} | sed 's/;/ /g') &> /dev/null mkdir -p {{.OutputDir}} &> /dev/null <del> echo -n "$CNI_COMMAND $CNI_NETNS $K8S_POD_NAMESPACE $K8S_POD_NAME $K8S_POD_INFRA_CONTAINER_ID" >& {{.OutputFile}} echo -n "{ "cniVersion": "{{.CNIVersion}}", "ip4": { "ip": "{{.PodIP}}/24" } }"` </del> <ins> echo -n "$CNI_COMMAND $CNI_NETNS $K8S_POD_NAMESPACE $K8S_POD_NAME $K8S_POD_INFRA_CONTAINER_ID" >& {{.OutputFile}}` </ins> inputFile := path.Join(testDataDir, binName+".in") outputFile := path.Join(testDataDir, binName+".out")

cniPlugin.execer = fexec cniPlugin.loNetwork.CNIConfig = mockLoCNI <del> mockLoCNI.On("AddNetworkList", context.TODO(), cniPlugin.loNetwork.NetworkConfig, mock.AnythingOfType("*libcni.RuntimeConf")).Return(&types020.Result{IP4: &types020.IPConfig{IP: net.IPNet{IP: []byte{127, 0, 0, 1}}}}, nil) mockLoCNI.On("DelNetworkList", context.TODO(), cniPlugin.loNetwork.NetworkConfig, mock.AnythingOfType("*libcni.RuntimeConf")).Return(nil) </del> <ins> mockLoCNI.On("AddNetworkList", mock.AnythingOfType("*context.emptyCtx"), cniPlugin.loNetwork.NetworkConfig, mock.AnythingOfType("*libcni.RuntimeConf")).Return(&types020.Result{IP4: &types020.IPConfig{IP: net.IPNet{IP: []byte{127, 0, 0, 1}}}}, nil) mockLoCNI.On("DelNetworkList", mock.AnythingOfType("*context.emptyCtx"), cniPlugin.loNetwork.NetworkConfig, mock.AnythingOfType("*libcni.RuntimeConf")).Return(nil) </ins> // Check that status returns an error if err := cniPlugin.Status(); err == nil {
Change:
Per PR the test fails to error properly. One line of particular interest from that PR: If you wonder why it does not fail on docker, that's because the test does not report the error correctly but fails the same way. This issue is intended to track the discussion and resolution of making this test error properly so that it is useful to CI Signal /sig networking /cc
The label(s) cannot be appled. These labels are supported: <detailsIn response to : Per PR the test fails to error properly. One line of particular interest from that PR: If you wonder why it does not fail on docker, that's because the test does not report the error correctly but fails the same way. ` /cc </details
I'm following up on this in
/sig network

Discussion:
framework.Failf("ginkgo.Failed to delete pod %s: %v", testAgnhostPod.Name, err) } }() <del> err = f.WaitForPodRunning(testAgnhostPod.Name) </del> <ins> err = f.WaitForPodReady(testAgnhostPod.Name) </ins> framework.ExpectNoError(err, "failed to wait for pod %s to be running", testAgnhostPod.Name) runCommand := func(arg string) string {

pod.Spec.HostNetwork = true _, err := cs.CoreV1().Pods(ns).Create(pod) framework.ExpectNoError(err) <del> framework.ExpectNoError(f.WaitForPodRunning(podName)) </del> <ins> framework.ExpectNoError(f.WaitForPodReady(podName)) </ins> framework.Logf("Netexec pod %q in namespace %q running", podName, ns) defer func() {

pod.Labels = jig.Labels _, err = cs.CoreV1().Pods(ns).Create(pod) framework.ExpectNoError(err) <del> framework.ExpectNoError(f.WaitForPodRunning(pod.Name)) </del> <ins> framework.ExpectNoError(f.WaitForPodReady(pod.Name)) </ins> defer func() { framework.Logf("Cleaning up the echo server pod") err := cs.CoreV1().Pods(ns).Delete(serverPodName, nil)

podTemplate.Labels = jig.Labels pod, err := cs.CoreV1().Pods(ns).Create(podTemplate) framework.ExpectNoError(err) <ins> framework.ExpectNoError(f.WaitForPodReady(pod.Name)) </ins> ginkgo.By("waiting for the service to expose an endpoint") err = e2eendpoints.ValidateEndpointsPorts(cs, ns, serviceName, e2eendpoints.PortsByPodName{serverPodName: {servicePort}})
Change:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: Miss APIGroup of DataSource. What you expected to happen: kubectl describe pvc should also describe the apigroup 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:
/assign
/sig storage

Discussion:
} if pvc.Spec.DataSource != nil { w.Write(LEVEL_0, "DataSource:n") <del> w.Write(LEVEL_1, "Name:t%vn", pvc.Spec.DataSource.Name) </del> <ins> if pvc.Spec.DataSource.APIGroup != nil { w.Write(LEVEL_1, "APIGroup:t%vn", *pvc.Spec.DataSource.APIGroup) } </ins> w.Write(LEVEL_1, "Kind:t%vn", pvc.Spec.DataSource.Kind) <ins> w.Write(LEVEL_1, "Name:t%vn", pvc.Spec.DataSource.Name) </ins> } printPodsMultiline(w, "Mounted By", mountPods)

}, Status: corev1.PersistentVolumeClaimStatus{}, }, <del> expectedElements: []string{"nDataSource:n  Name:      srcpvcn  Kind:      PersistentVolumeClaim"}, </del> <ins> expectedElements: []string{"nDataSource:n  Kind:      PersistentVolumeClaimn  Name:      srcpvc"}, </ins> }, { name: "snapshot-datasource",

}, Status: corev1.PersistentVolumeClaimStatus{}, }, <del> expectedElements: []string{"DataSource:n  Name:      src-snapshotn  Kind:      VolumeSnapshotn"}, </del> <ins> expectedElements: []string{"DataSource:n  APIGroup:  snapshot.storage.k8s.ion  Kind:      VolumeSnapshotn  Name:      src-snapshotn"}, </ins> }, }