My background is ‘infrastructure as code’ type projects and so my life is made up of identifiers such as GUIDs, MAC addresses, TCPv4 and TCPv6 addresses and lots of magic numbers provided by vendors such as AWS. All of these identifiers are out of my control but often directly map to settings and secrets that I wish to manage.
As it stands it is just about impossible to map these identifiers across to doppler as the system limits the length of a config name to just 15 characters.
Environment names do not have this limitation but instead suffer from 2 other issues I have posted for the consideration list in the past.
you can not directly clone/copy an environment to create a new one.
The GUI is designed to only handle a few environments under a project, too many and you have to scroll the screen left and right to find the environment. This single line of entries is then ordered from oldest to newest, so the environment you have just created is always the hardest to reach.
As an extension of this request, it would also be helpful if a note could be added to a config and for that note to be displayed like a tooltip when the mouse is placed over the config name - all of the above identifiers are a real pain to use without additional hints being available.
This is an interesting use-case! Doppler’s design is definitely geared more toward deployment environments (e.g., dev, stg, prd). Usually, there are only a handful of these, so the current UI design works well. Your use case seems to be using us more like a database than what we had initially envisioned. Would you mind elaborating some on the types of data you’re storing in these configs? I would imagine much of it is configuration data that could be potentially stored in a database rather than Doppler. Is it SSL certificates or something along those lines? Any additional context you can provide us here would be helpful!
I’m passing this feedback along to our Product team. I don’t know if we’ll be able to accommodate your requests, but it’s definitely a use case we hadn’t really considered before and are discussing internally!
The use-case at the moment is that of building the CI environments for the dev, stg and prd systems.
These are all built by using cloud-init, shell scripts and ansible scripts, so Doppler is a logical starting point as it can be loaded the instance that a single network interface is up and running. It then just provides the large number of values needed to build the system on a target environment - VMware, AWS etc.
The only major issue is the very short string that can be allocated to a config name as a target system will always have some form of mapping that can be used, but just about every option is or maybe longer than 15 characters.
I already have this issue with our deployment environments as the logical name we want to use is the full DNS names, not short-hand options like dev, stg and prod - hence the major limitations I am finding when trying to use Environments instead of Configs to manage things.
For a firm example -
We use CircleCI for our CI system and this allows us to deploy local build/CI nodes. For my environment, these are created by just running a one-line script as they are auto built, deployed and configured, but each of these needs a unique identifier - the full DNS name would be ideal as that would mean that everyone knows what the set of values is linked to. I already have 5 such systems so the limitations of the GUI mean that using Environments is a problem as and when I define the next one, while the name length limitations mean that configs are a problem if I want to use a human-readable name (full DNS names).
Currently, the only system-related name that I can use is something like “0050560123c8” which is the mangling of the MAC address of one of the systems interface cards, which should read “00:50:56:01:23:c8”, but that is too long. This is a usable unique identifier, but not human-friendly.
