Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

test framework does not help investigating daemonset pods #9983

Closed
chrischdi opened this issue Jan 11, 2024 · 5 comments · Fixed by #9984
Closed

test framework does not help investigating daemonset pods #9983

chrischdi opened this issue Jan 11, 2024 · 5 comments · Fixed by #9984
Assignees
Labels
area/e2e-testing Issues or PRs related to e2e testing kind/feature Categorizes issue or PR as related to a new feature. triage/accepted Indicates an issue or PR is ready to be actively worked on.

Comments

@chrischdi
Copy link
Member

What would you like to be added (User Story)?

As a developer, I'd like to save the logs of pods running in my e2e tests as daemonsets.

Detailed Description

The cloud-provider-vsphere project makes use of CAPI and CAPV to setup a test environment / provision a kubernetes cluster.

On top it deploys the Cloud Provider as Daemonset.

When investigating issues it is important to be able to analyse the logs of the Daemonset pods.

The current utilities in CAPI's test framework only focus on being able to stream and save logs of Deployments via:

func WatchDeploymentLogsByLabelSelector(ctx context.Context, input WatchDeploymentLogsByLabelSelectorInput) {

and

func WatchDeploymentLogsByName(ctx context.Context, input WatchDeploymentLogsByNameInput) {

Under the hood this helpers use the function:

func watchPodLogs(ctx context.Context, input watchPodLogsInput) {

For watching and saving logs for Daemonsets in other projects, it would be helpful to either being able to extend the functionality by exposing watchPodLogs publicly, or by implementing similar functions for Daemonsets.

This could also help analysing Daemonset logs for CAPI providers, which may also deploy daemonsets for a functional cluster (cloud-provider, csi, cni).

Anything else you would like to add?

cc @DanielXiao

/assign sbueringer

Label(s) to be applied

/kind feature
One or more /area label. See https://github.com/kubernetes-sigs/cluster-api/labels?q=area for the list of labels.

@k8s-ci-robot k8s-ci-robot added kind/feature Categorizes issue or PR as related to a new feature. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Jan 11, 2024
@chrischdi
Copy link
Member Author

xref: Example which needed to copy-paste the watchPodLogs function (+ dependent functions) kubernetes/cloud-provider-vsphere@18a42a9

@sbueringer
Copy link
Member

@chrischdi Just for my understanding. I got it correctly that we could use this func to stream DaemonSet logs from workload clusters?

@chrischdi
Copy link
Member Author

Yes, workload or also Management Cluster.

@chrischdi
Copy link
Member Author

The function itself would come down to:

type WatchDaemonSetLogsByLabelSelectorInput struct {
	GetLister framework.GetLister
	Cache     toolscache.Cache
	ClientSet *kubernetes.Clientset
	Labels    map[string]string
	LogPath   string
}

// WatchDaemonSetLogsByLabelSelector streams logs for all containers for all pods belonging to a daemonset on the basis of label. Each container's logs are streamed
// in a separate goroutine so they can all be streamed concurrently. This only causes a test failure if there are errors
// retrieving the daemonset, its pods, or setting up a log file. If there is an error with the log streaming itself,
// that does not cause the test to fail.
func WatchDaemonSetLogsByLabelSelector(ctx context.Context, input WatchDaemonSetLogsByLabelSelectorInput) {
	Expect(ctx).NotTo(BeNil(), "ctx is required for WatchDaemonSetLogsByLabelSelector")
	Expect(input.Cache).NotTo(BeNil(), "input.Cache is required for WatchDaemonSetLogsByLabelSelector")
	Expect(input.ClientSet).NotTo(BeNil(), "input.ClientSet is required for WatchDaemonSetLogsByLabelSelector")
	Expect(input.Labels).NotTo(BeNil(), "input.Selector is required for WatchDaemonSetLogsByLabelSelector")

	daemonSetList := &appsv1.DaemonSetList{}
	Eventually(func() error {
		return input.GetLister.List(ctx, daemonSetList, client.MatchingLabels(input.Labels))
	}, retryableOperationTimeout, retryableOperationInterval).Should(Succeed(), "Failed to get daemonsets for labels")

	for _, daemonSet := range daemonSetList.Items {
		watchPodLogs(ctx, watchPodLogsInput{
			Cache:          input.Cache,
			ClientSet:      input.ClientSet,
			Namespace:      daemonSet.Namespace,
			DeploymentName: daemonSet.Name,
			LabelSelector:  daemonSet.Spec.Selector,
			LogPath:        input.LogPath,
		})
	}
}

@sbueringer
Copy link
Member

Sounds good

/triage accepted

Let's make sure we start using this func in CAPV for CPI & CSI (I think) once this is implemented and cherry-picked

@k8s-ci-robot k8s-ci-robot added triage/accepted Indicates an issue or PR is ready to be actively worked on. and removed needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Jan 11, 2024
@sbueringer sbueringer added the area/e2e-testing Issues or PRs related to e2e testing label Jan 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/e2e-testing Issues or PRs related to e2e testing kind/feature Categorizes issue or PR as related to a new feature. triage/accepted Indicates an issue or PR is ready to be actively worked on.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants