Support Helm using the -config.file but hosted in the values.yaml

[mbrancato]

Is your feature request related to a problem? Please describe.

It is extremely confusing what config is relevant in the Helm chart today.

The config in the Helm chart today is for a dependency "Phlare", and can seem like it is part of the Pyroscope configuration.

pyroscope/operations/pyroscope/helm/pyroscope/values.yaml

Lines 155 to 169 in bbe05cc

	structuredConfig: {}
	# -- Contains Phlare's configuration as a string.
	# @default -- The config depends on other values been set, details can be found in [`values.yaml`](./values.yaml)
	config: |
	{{- if .Values.minio.enabled }}
	storage:
	backend: s3
	s3:
	endpoint: "{{ include "pyroscope.fullname" . }}-minio:9000"
	bucket_name: {{(index .Values.minio.buckets 0).name | quote }}
	access_key_id: {{ .Values.minio.rootUser | quote }}
	secret_access_key: {{ .Values.minio.rootPassword | quote }}
	insecure: true
	{{- end }}

But when you look closer, this is not the Pyroscope configuration file. The example uses:

storage:
  backend: s3
  s3:
    endpoint: "minio:9000"

But Pyroscope uses:

s3_storage_backend:
  endpoint: "minio:9000"

This means that most of the available configuration parameters are left to be specified in the extraArgs section as CLI params.

Describe the solution you'd like

There should be a structured Pyroscope configuration that aligns with the Pyroscope documentation in the Helm chart values.

[wokwong]

I have a same confusion. So, I need to configue s3_storage_backend in the extraArgs section to use s3, right?

[marcsanmi]

👋 Hi,

Let me try to clarify two different aspects about Pyroscope's configuration:

1. Regarding the s3_storage_backend reference in the documentation - this is actually just describing the schema/structure of properties that can be used under the storage.s3 configuration block. It's not meant to be used as a configuration key itself. The correct configuration would look like:

storage:
  backend: s3
  s3:
    endpoint: ...
    bucket_name: ...
    ...

2. About configuration options - there are several ways to customize the S3 configuration:

• Extend/override specific settings using structuredConfig
• Provide your own complete configuration by overriding the config parameter
• Use extraArgs with corresponding CLI flags for additional parameters

The current values.yaml provides default settings, but these are meant to be customized according to your needs.

[wokwong]

👋 Hi,

Let me try to clarify two different aspects about Pyroscope's configuration:

1. Regarding the s3_storage_backend reference in the documentation - this is actually just describing the schema/structure of properties that can be used under the storage.s3 configuration block. It's not meant to be used as a configuration key itself. The correct configuration would look like:

storage:
backend: s3
s3:
endpoint: ...
bucket_name: ...
...
2. About configuration options - there are several ways to customize the S3 configuration:

• Extend/override specific settings using structuredConfig
• Provide your own complete configuration by overriding the config parameter
• Use extraArgs with corresponding CLI flags for additional parameters

The current values.yaml provides default settings, but these are meant to be customized according to your needs.

Thanks for your reply。

Another question about path-style :
The pyroscope's logs shows that it uses s3 path-style by default (force_path_style is not set). However,some object storage services support only virtual-hosted-style. How should I configure to use virtual-hosted-style ?

[marcsanmi]

If I'm not wrong, there's this open PR that aims to address this.

[wokwong]

Hi @marcsanmi ,
I checked this PR and felt that it was not the same as what I said.

According to the doc，set force_path_style to true to force the bucket lookup to be using path-style，but I didn't set it，the logs shows that it uses path-style too。It means that Pyroscope only supports path_style,not virtual-hosted-style ?

[marcsanmi]

That PR is introducing a new config BucketLookupType where you'll be able to set virtual-hosted-style. Note it also flags force-path-style as deprecated.

It should be available in the next release.

[wokwong]

OK，I get it，thank you for your patience.

[marcsanmi]

No problem! Closing this, feel free to reopen it in case something is missing