-
Notifications
You must be signed in to change notification settings - Fork 1.3k
[installer] Rename and print OR remove --danger-use-unsupported-config
flag
#8107
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
Comments
This is a rough UX. Can we change to flag to something that connects it to
The user of the installer is considered someone who is ok with low-level access and is often other Gitpod folks. I think the safety is good but we should still make it easy. To go with this, when we warn folks lets tell them how to fix it, ie add the flag vs just ignore it. If folks have experimental config sections in their YAML, chances are they want to use them. Should we just bail at this point and emit the warning that they should re-run with the flag or remove the experimental config? |
Given that the main config surface for most people out there should be the Replicated UI and that the term “experimental” in the config file should be warning enough, I would also vote for removing the flag entirely. |
--danger-use-unsupported-config
flag
Fixes #8107 Users when they explicitely add the `experimental` section into their config, probably know that they are using it. We might add a section in the [config documentation](#8107) to make it a bit more explicit that it might be dangerous to use. But having to use a flag doesn't really make sense, as discussed in the issue. This PR removes that flag. Signed-off-by: Tarun Pothulapati <[email protected]>
I think I would respectfully disagree. The experimental config is not for most users (truthfully, it's mostly for SaaS) and there's a danger that people read "experimental" as "beta" or "this is some brilliant stuff that's coming in the future - use it now to be bleeding-edge" which it absolutely isn't. It's unsupported configuration which allows users to go outside the tracks of the Installer's framework |
OK, convinced me. In particular, I think @csweichel's argument is key:
|
Fixes #8107 This PR updates the flag descriptions, and the `render` display notes to be more explicit on what experimental config is. This flag is required, to make sure users are opting in explicitely/ knowlingly to use the experimental config. Signed-off-by: Tarun Pothulapati <[email protected]>
Fixes #8107 This PR updates the flag descriptions, and the `render` display notes to be more explicit on what experimental config is. This flag is required, to make sure users are opting in explicitely/ knowlingly to use the experimental config. Signed-off-by: Tarun Pothulapati <[email protected]>
Fixes #8107 This PR updates the flag descriptions, and the `render` display notes to be more explicit on what experimental config is. This flag is required, to make sure users are opting in explicitely/ knowlingly to use the experimental config. Signed-off-by: Tarun Pothulapati <[email protected]>
Bug description
when using experimental settings in installer, error message is not very helpful.
would be good to tell user how to enable experimental options in that message.
Also, after digging through source code I did find the switch for it:
-danger-use-unsupported-config enable use of unsupported config
which doesn't mention anything that it enables experimental settings.
Steps to reproduce
Workspace affected
No response
Expected behavior
No response
Example repository
No response
Anything else?
No response
The text was updated successfully, but these errors were encountered: