How should clients select/merge profiles?

[Arthur Busser]

I am currently working on a piece of software that will fetch secrets from Scaleway's Secret Manager. The program should configure its client with whatever is provided in its environment. My question is: what is the standard on building the profile used when building the client?

I can get a profile from the configuration file, if such a file exists:

func getConfigProfile() *scw.Profile {
    config, err := scw.LoadConfig()
    if err != nil {
        return &scw.Profile{}
    }
    profile, err := config.GetActiveProfile()
    if err != nil {
        return &scw.Profile{}
    }
    return profile
}

And I can merge that with the profile based on environment variables,
in the same order that the Scaleway CLI seems to do it:

profile := scw.MergeProfiles(getConfigProfile(), scw.LoadEnvProfile())

And pass that to the client:

c, err := scw.NewClient(scw.WithProfile(profile))

Easy enough, the SDK is well made ;)

From my understanding of the SDK's source code, this would default to whatever settings the user has in their configuration file and override those settings with whatever SCW_ environment variables are set. This seems to be what I am looking for, but...

1. Have I missed something? Is there another way the user could pass configuration?
2. Could the SDK include a DefaultProfile() *Profile function that does what I am attempting to do? I would be willing to contribute that function :)

[Jules Castéran]

Hi, thank you for your interest.
As you have done, the standard way is to override loaded config with env profile.

For the profile, you may want to let the user choose the profile name, defaulting to the active profile.
We do it in different tools, CLI with --profile <profile-name>, Terraform, Waypoint.

In terraform we also allow overriding fields in the loaded profile in the provider config

provider scaleway {
  profile = "<profile-name>"
  zone = "fr-par-2"
  access-key = "..."
}

For the config, there is configuration in the cli with --config <path>, this is the only tool that add this as there is already SCW_CONFIG.

The active profile loading can be tricky and is not completely consistent between all our tools.

CLI

A profile is loaded with this steps for the profile name:

• use --profile if present
• use SCW_PROFILE if present
• use active_profile from config if present
• "default"

Then the env profile is merged into this loaded profile.

Terraform

For terraform there is more profiles that are being merged. It goes as:

Env >> Provider >> Active >> Default

The env profile and active ones are the same as in your example. The default one is an hardcoded zone and region in the plugin.

For the provider one it goes further, a profile is loaded from config if profile is given, then all given fields are used as override (access_key, project_id...)

----

To keep it simple I would recommend to do as you did and maybe add a profile option to override the active profile if you feel it is needed.
That would be a great improvement to have all this standardized by the sdk, we can keep this issue open for tracking.

[Arthur Busser]

Thank you for your answer.

Adding a --profile flag is not an option in my case. The CLI I am developing is not Scaleway-specific. But the SDK's default behavior of reading the SCW_PROFILE is good enough 👍

I agree that it would be nice for the SDK to provide this "default profile" functionality.

I guess to start the discussion we should agree on what that means and what the API should look like.