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

Hi,

> > 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.

Unless we make no name and location change for the default. Since you are
playing the Minikube card. I am just playing devils advocate a bit.

The only issue I see is when user have a default instance and a profile there will be a MINISHIFT_HOME/config/config.json and MINISHIFT_HOME/MACHINE_NAME/config/config.json. I guess this can be confusing for user. May be user does not care as user should be using commands to deal with config.json e.g. `minishift config view`.

> > 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
> > over?
> >
>
> I would leave it to user whether user want to move or wants to start fresh.

How? Just adding some docs somewhere or just a mention in the release annoucement?
Note, in the current form 'minishift update' does not take a major version change
into account. The user might jsut run 'minishift update' and by the time
the binary is released, there is no way back (in terms of a decision on what to do).
See also https://github.com/minishift/minishift/issues/1259

I think we need to fix #1259 asap.

> Also we need to communicate to the user that layout has changed hence we
> expect the user to do the changes

Again, that depends.

> > 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.

The implementations have by now even more diverged. In terms of what they
display, how they display it and the options they support. So what is
better making this distinction clear by a command under the 'openshift' scope
or having seemingly aligned commands?

I somewhat agree to what you are saying on this. However this is not about how it is implemented as from a Kubernetes and OpenShift "service" concept i.e. definition of a service is same for both. So an OpenShift user or Kubernetes user would have same understanding of services and similar expectation from Minishift as well as Minikube.

-Lala

--Hardy