My 2 cents.

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. 

Lala might have more understanding of above whether it will work accurately and efficiently.

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

I also feel, going with option 2 is cleaner way. 

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

IMO, we should leave it to user to decide to update minishift and perform migration. However, I 
believe most of users shouldn't bother to delete his $MINISHIFT_HOME directory and start over.

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

Yes, it is very good opportunity to sort out those things.


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

Budh Ram Gurung