On Fri, Aug 11, 2017 at 3:03 AM, Hardy Ferentschik <hardy(a)ferentschik.de> wrote:
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 profile.
So even if none is explicitly set or specified, a `minishift profile list` would report
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
discovered and set in root.go at the beginning of the bootstrap. This avoids having code
based on profile existence at any other place than root.go.
The interesting question is, how profiles and in particular the default profile reflect
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
structure (no profile sub-directory). The benefit would be that if one does not use
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
In this cases one would need to do a translation in root.go where the default profile
to "just" MINISHIFT_HOME.
The downside is that once one uses profiles the structure is not completely consistent.
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
sub-directory. This means existing Minsihfit setups will break. In our discussion we said
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
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
the structure further down the track when we potentially have some other changes which
are not backwards
After yesterday discussion I also tend to support for option 1 which
provide us backward compatibility and also as you said if something
like v1.2.0 make more sense if we are completely changing our codebase
Minishift Mailing List mailing list -- minishift(a)lists.minishift.io
To unsubscribe send an email to minishift-leave(a)lists.minishift.io