I think it is important that we come to a consensus here how we want to introduce profiles.
It might affect if we need to write more code or not. Here are the options
#1 The default/minishift profile maps to the current structure of $MINISHIFT_HOME and additional
profiles are under $MINISHIFT_PROFILE
- Pro: Backwards compatible. Unless a user uses profiles, there is no difference at all
- Pro: No special actions during rollout required
- Con: Depending on the point of view, the directory/file layout can be seen as inconsistent
#2 Change the directory/file layout and each VM (including default/minishift) resides under
$MINISHIFT_HOME/profiles. Only the all instances config file will reside in $MINISHIFT_HOME.
- Pro: (Potentially) more consistent file layout
- Con: Requires a 2.0.0 release with potential action on our behalf to reduce migration issues
Anything I missed in the pro/cons lists? In the end it comes down to how important one things
the fact that all profiles reside under $MINISHIFT_HOME/profiles is. IMO we should not let
implementation details drive this decision. Apart from a path/name mapping there is technically
What shall we do?
Minishift Mailing List mailing list -- email@example.com
To unsubscribe send an email to minishift-leave@lists.