What should the future of 'simp config' look like?

Owned by Trevor Vaughan
Last updated: Jan 28, 2019 by Judith Johnson
1 min read

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 Brandon Riden Kendall Moore Adam Yohrling Steven Pritchard Shark Bruhaha Michael Morrone
Informed
Due date
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

(plus) Easily runs on a minimal system with no external dependencies

(plus) Can guarantee no external network connections easily

(minus) Adds an additional language into the mix

(plus) Relatively straightforward to build

(minus) 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

(minus) Has turned out to have a relatively high maintenance burden in terms of small changes since it's effectively half of a framework

(minus) 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