What should the future of 'simp config' look like?
Add your comments directly to the page. Include links to any relevant research, data, or feedback.
Status | IN PROGRESS |
|---|---|
Impact | MEDIUM |
Driver | @Trevor Vaughan |
Approver |
|
Contributors | @Liz Nemsick @Chris Tessmer @Jeanne Greulich @Judith Johnson @Dylan Cochran (Unlicensed) @Brandon Riden (Unlicensed) @Kendall Moore @Adam Yohrling (Unlicensed) @Steven Pritchard @Shark Bruhaha (Unlicensed) @Michael Morrone |
Informed |
|
Due date | May 31, 2019 |
Outcome |
Background
We've struggled with what 'simp config' should act like for quite some time. This page has been created to help us capture the future of the SIMP configuration command and how it should be presented to the user.
Relevant data
Restrictions:
No guaranteed Internet connection
Minimal system load (whatever comes with a 'yum install simp' on a minimized system)
No GUI available
No web client available by default
Expectations
What do you actually feel that simp config should look like and/or do?
Please add your ideas with your Confluence ID beside them for ongoing discussion and consideration
Options considered
| Option 1: | Option 2: |
|---|---|---|
Description | Statically Compiled TUI Something like one of the following: | Q&A Tree Similar to current 'simp config' |
Pros and cons | Easily runs on a minimal system with no external dependencies Can guarantee no external network connections easily Adds an additional language into the mix | Relatively straightforward to build Quite difficult to provide a flexible interface for user help as well as trees of options that are only relevant when a higher level option is selected Has turned out to have a relatively high maintenance burden in terms of small changes since it's effectively half of a framework As it grows, it starts bringing in a LOT of external dependencies that have to be packaged and shipped separately due to licensing and interaction concerns |
Action items
Outcome
Comments
Everything that @Liz Nemsick posted seems quite reasonable except that I think we'll need to opt for a TUI instead of a GUI due to the unknown state of the environment beyond a terminal.
The one item that hung us up last time was network settings. You need those to infer a lot of the information down the line. After talking to various users and developers, it seems like a 'fail fast' approach that allows them to either manually configure the network or run a separate script to configure the network would be preferred.
My only opinion on this topic is that I think whatever is chosen 'simp config' needs to be as absolutely easy to use as possible. I'm completely agnostic to the language choices or specific engineering approach and think the maintainers/developers should simply pick what makes sense there. This answer isn't intended to be passive or dismissive, I just think over-architecting or over-engineering this tool would be a mistake, as it's a one-time use script for only a subset of users getting started. Unless 'simp config' is being redesigned to handle additional installation/configuration approaches beyond "Install SIMP via an ISO" there is no solution that will fit every one of the users. Many people would probably prefer a very small set of questions they have to answer which could directly modify a system to the minimal effect needed to get started. I'd even suggest a step further which is that users who don't want to go through an interactive mode could simply edit a text file and run the command directly. I'm thinking something to the same effect as the Puppet Enterprise installer (ignoring the web UI as there is also a text-based approach). This configures the PE specific components but then defers data/environment level decisions to the maintainer of a control repo (or some other such source) who can further configure and tune the system as needed. In fact, that installer has an option for a control repo so that it can be configured to use r10k/Code Manager immediately following the initial setup. Something that mimics this would be the ideal approach to me.
A few thoughts to begin....I'm sure I'll have more later.
Some of the basic problems I see with existing the simp config are the following:
The decision trees are very brittle.
They contain information (e.g. descriptions, defaults) and validation code replicated from Puppet modules. No DRY here!
They were designed for very specific use cases and do not accommodate any perturbations from these use cases. (For example, if you are using external LDAP and don't need a Sync DN you still have to enter something that passes validation).
They are a royal pain to create and test.
The actions are interspersed with data gathering. IMHO the data should be gathered in one step and applied in another step.
There is no option to skip things you don't know and return to them later. You either have to answer with something that will pass validation, or you are not allowed to move on. If you have run it in dry-run mode, this isn't an issue. But I suspect most people jump right in, get part way through with some actions applied, hit a question they can't answer and abort. Kind of a scary experience.
Some things are set for you, silently, as a courtesy and you can't change, even if you use an 'answers' file. This is good for a newbie, but frustrating to an experienced SIMP/Puppet user.
With this in mind I would like a GUI to include the following characteristics
Gathering of info is separate from applying it
The user should be able to navigate to any section and not be forced to complete any section during the data gathering part.
As with simp config, the partial information gathered should be persisted and optionally reloaded if the program is exited before completion.
The apply operation should not be allowed if required information is missing.
Hieradata set for user automatically, should be visible, but grayed out. If it should be able to be changed by the user (all but simp_options::fips?), there should be an advanced button to support tweaking in the GUI.
The user should be able to toggle help info for each screen/parameter.