Feature request: support additional pod fields

[phoban01]

Description

A common use case for lib-volume-populator is restoring data from remote storage services (eg AWS S3). Currently there is no easy way to to configure authentication for the populator pod to such remote storage services.

Whilst there are alternatives it seems a common enough use-case to justify inclusion as part of the lib-volume-populator.

Supporting the ability to configure the following fields on the pod should enable the majority of authentication needs:

• spec.serviceAccount / spec.serviceAccountName
• spec.env
• spec.volumes.configMap
• spec.volumes.secrets
• metadata.annotations

Alternatives considered

We could implement a mutating webhook to modify the pod spec as part of admission control.

[everpeace]

If I understood correctly, you can achive your issue via ProviderFunctionConfig:

lib-volume-populator/populator-machinery/controller.go

Lines 186 to 193 in 8355999

	type ProviderFunctionConfig struct {
	// PopulateFn is the provider specific data population function
	PopulateFn func(context.Context, PopulatorParams) error
	// PopulateCompleteFn is the provider specific data population completeness check function, return true when data transfer gets completed
	PopulateCompleteFn func(context.Context, PopulatorParams) (bool, error)
	// PopulateCleanupFn is the provider specific data population cleanup function, cleanup resouces after data population completed
	PopulateCleanupFn func(context.Context, PopulatorParams) error
	}

You can create any pods, or even multiple pods or complex workflows, by PopulateFn. And, you can notify the completion via PopulateCompleteFn.

Note: PodConfig and ProviderConfig is mutually exclusive.

[phoban01]

Thanks, I belatedly realised this 😊