On Tue, Aug 15, 2017 at 5:19 PM, Hardy Ferentschik <hardy@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@lists.minishift.io
To unsubscribe send an email to minishift-leave@lists.minishift.io