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

How should clients select/merge profiles? #1676

Open
busser opened this issue Apr 28, 2023 · 2 comments
Open

How should clients select/merge profiles? #1676

busser opened this issue Apr 28, 2023 · 2 comments
Assignees
Labels
enhancement New feature or request priority:low Low priority such as UX improvements and esthetics

Comments

@busser
Copy link

busser commented Apr 28, 2023

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 :)
@Codelax
Copy link
Member

Codelax commented May 5, 2023

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.

@busser
Copy link
Author

busser commented May 6, 2023

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.

@remyleone remyleone added enhancement New feature or request priority:low Low priority such as UX improvements and esthetics labels Oct 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request priority:low Low priority such as UX improvements and esthetics
Projects
None yet
Development

No branches or pull requests

3 participants