2:55 a.m.
On Tue, Aug 15, 2017 at 5:19 PM, Hardy Ferentschik <hardy(a)ferentschik.de>
wrote:
Hi,
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
Question,
1. If we go with #1 and user has the default instance (i.e. VM name
minishift) what should "minishift profle list" should return?
I guess you would expect it to return "minishift" but from backward
compatibility and consistency point of view "minishift" commands should
work fine with default instance without running "minishift profile set" or
"--profile".
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
no difference.
What shall we do?
--Hardy
_______________________________________________
Minishift Mailing List mailing list -- minishift(a)lists.minishift.io
To unsubscribe send an email to minishift-leave(a)lists.minishift.io