5:40 a.m.
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.
> 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
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?
--Hardy