On Fri, Aug 11, 2017 at 3:03 AM, Hardy Ferentschik <hardy(a)ferentschik.de>
I wanted to circle back to the roll-out of the profile feature.
I think we agreed that from a user point of view there should always be a
So even if none is explicitly set or specified, a `minishift profile list`
that the 'default' profile is in use (or 'minishift' tbd).
Also from an implementation point of view there should always be a
profile. The profile is
discovered and set in root.go at the beginning of the bootstrap. This
avoids having code branches
based on profile existence at any other place than root.go.
The interesting question is, how profiles and in particular the default
profile reflect on
the file system. There are two main approaches.
The first one is the one which is also taken by Minikube. The default
profile uses the existing
structure (no profile sub-directory). The benefit would be that if one
does not use profiles nothing
is going to change on a file system level. Everything will look the same.
The other benefit is, that
it is truly backwards compatible and an existing VM and configuration is
continue to work.
In this cases one would need to do a translation in root.go where the
default profile would map
to "just" MINISHIFT_HOME.
The downside is that once one uses profiles the structure is not
completely consistent. The default
profile is not just another directory in the profiles directory.
The alternative is to make profiles consistent and also move the default
profile into the profiles
sub-directory. This means existing Minsihfit setups will break. In our
discussion we said that we
in this case can add something in root.go which allows the user to migrate
at least config and cache
into the new default location. An existing VM would need to be delete,
since files cannot just be moved.
Note, that we give the user not much of a choice. If the user wanted to
keep the existing VM, he would
have to download an earlier version of Minishift. Thinking about semantic
versioning, one could almost
argue that rolling out profiles would harbor a 2.0.0 release.
As much as I like consistency, I have to admit that the first option is
growing on me. It allows us to roll
out profiles without having to add code for migration. If we really
wanted, we could then clean up
the structure further down the track when we potentially have some other
changes which are not backwards
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".
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.
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
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
Minishift Mailing List mailing list -- minishift(a)lists.minishift.io
To unsubscribe send an email to minishift-leave(a)lists.minishift.io