On Fri, Aug 11, 2017 at 1:43 PM, Hardy Ferentschik <hardy@ferentschik.de> wrote:

> 1. I would also like to keep the things consistent both in code and
> filesystem e.g. minishift profile list should print `minishift-default` if
> no profile is mentioned. The VM name should be also "minishift-default".

Sure, I don't see an issue here even when using approach 1. There is only
one translation needed to make this work. Assuming the directory in which profile
VMs are stored is $MINISHIFT_HOME/profiles/<profile-name>/<addons, cache, config.json, machine,...>.

In code you probably build your path in the form of profile_dir = filepath.Join(GetMinishiftHome, 'profile', profileName).
All you need is one conditional check and translation at this point.
If profile name == 'default', then drop 'profile' (and use 'minishift' as machine name).

Note, you only need to do this in one location and everything else should just work
without any further conditional logic. It is just about making the 'default' profile
match the current layout.

> 2.  We have features line addons and we have config.json which we want to
> keep separate for each instance/profile. Hence changing the layout where
> each instance have different directory structure would make sense to me.
> However minikube just uses one config.jason for all instances.

You are not breaking this. This will still be the case.

> 3. The new layout will be different hence we should do a 2.0.0 release.
> Which will be cleaner approach than try to fit in to the older filesystem
> layout.

Ok, if I understand correctly, you are in favour of doing a break right now. Go for option 2,
where even the default profile will move into a new location.

Right. As the VM instance name change and the layout change will not be backward compatible change. 

You also want a 2.0.0 release indicating a backwards incompatible change.

As part of this, do you want to put anything in place to migrate existing config, add-ons, etc
or leave it to the user. Effectively he should delete his $MINISHIFT_HOME directory and start

I would leave it to user whether user want to move or wants to start fresh. Also we need to communicate to the user  that layout has changed hence we expect the user to do the changes. I can not think of the details now. But need to find out how exactly we want to do it. 

> 4. If we plan to do a 2.0.0 release we need to fix some other things e.g.
> moving minishift openshift service to minishift service for aligning with
> minikube.

The move of the service command still gets a -1 from my side, but if the majority things this
should be done, it would be a good opportunity to do so.

I think we agreed that services is something common to both minikube and minishift. Also the user experience needs to be aligned.  I think we should keep this similar to Minikube as we got user feedback on this.



Minishift Mailing List mailing list -- minishift@lists.minishift.io
To unsubscribe send an email to minishift-leave@lists.minishift.io