On Fri, Aug 11, 2017 at 1:43 PM, Hardy Ferentschik <hardy(a)ferentschik.de>
> 1. I would also like to keep the things consistent both in code and
> filesystem e.g. minishift profile list should print `minishift-default`
> 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
VMs are stored is $MINISHIFT_HOME/profiles/<profile-name>/<addons, cache,
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
Note, you only need to do this in one location and everything else should
without any further conditional logic. It is just about making the
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
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
> moving minishift openshift service to minishift service for aligning with
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(a)lists.minishift.io
To unsubscribe send an email to minishift-leave(a)lists.minishift.io