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

centralized configuration and accessors for default parameters #119

Open
displague opened this issue May 27, 2021 · 0 comments
Open

centralized configuration and accessors for default parameters #119

displague opened this issue May 27, 2021 · 0 comments

Comments

@displague
Copy link
Member

displague commented May 27, 2021

As expressed in equinixmetal-archive/packngo#189 (comment), users would benefit from a common configuration file location and format shared between tools.

What does this look like for packet-python? (Following a rename #106)

# ~/.config/equinix/metal.yaml
---
token: ...

This common file would serve as the default token for all Equinix Metal API client tools, regardless of language, regardless of tool.

Different tools will have their own means of setting provider tokens and this shared/central configuration will not prevent that.

In the packngo issue, the format is described as one that could be shared between Equinix tools. Metal tools could be configured in a metal specific block and individual clients could be configured within sub-blocks.

# ~/.config/equinix/metal.yaml
---
token: ... # default

clients: # this format has not been formalized, perhaps "profile" would be a better name. Tools could allow users to specify the profile to use.
- name: ansible
   token: ... # client specific

The configuration file would allow for defaults such as organization id, project id, facility, metro, device plan, and OS to be specified. Tools do not have to honor these defaults but they will be able to take advantage of them so long as defaults are configured and the tool documentation declares that these values will be used.

  • packet-python would offer accessors and classes for accessing the configured parameters.
  • packet-python may offer new client constructors (or new default behaviors in a renamed module Equinix Metal Python (via rename or new module) #106) that defer to this configuration under various conditions (to be defined).
  • packet-python may allow for environment variables to override the default configuration file.
  • packet-python may allow for environment variables to override the configuration file values.

More ambitious aspects of the packngo issue express that the client should be able to fetch defaults from the Equinix Metal API. The user profile is configured with default organizations and projects, as defined in the Equinix Metal Portal.

This style of configuration is found in other cloud provider toolsets where common configuration is shared between tools. This simplifies the experience of using different tools because the defaults and secrets are already defined allowing client tools to work with little or no configuration.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant