Central repository for Minishift demo content
by Budh Ram Gurung
I have been thinking around this since last three to four months
but haven't got time properly to share.
I think it is the right time to shoot it.
I have been working on this repo  to get a central place to collect
all the demo content around Minishift.
Following are my future plans:
- One section to show all the examples related to Minishift CLI 
- One section to show all the examples related to OpenShift doing
- One section to show all Kubernetes specific
- Others if applicable
Inside Minishift CLI section, we can create a release specific page
showing release specific examples/features and shared with the
community after each release (the idea came from the gist page
@gerard shared for one of previous release)
It would be easy for us to share this one source and users to try
examples from it as well.
Let me know your opinions/comments/suggestions on this idea.
Budh Ram Gurung
Software Engineer - Devtools
5 years, 8 months
Minishift-1.6.0 release announcement
by Praveen Kumar
The Minishift team is pleased to announce the release of Minishift 1.6.0.
Minishift  is a command-line tool that provisions and manages a
single-node OpenShift cluster. You can run Minishift on GNU/Linux,
Microsoft Windows or macOS.
This release adds several new features, enhancements, and bug fixes,
Create multiple instances of Minishift 
With this feature you can now create multiple instances of Minishift.
Each instance can have different configurations as per the requirement
and you can switch between them when required.
$ minishift --profile foo start --memory 4GB
$ minishift --profile bar start --iso-url centos
$ minishift profile list
- foo Running
- bar Running (active)
Uninstall add-on command 
You can now uninstall add-on with `minishift addons uninstall
<addon-name>`. See the documentation for more details .
Remove add-on command 
‘Minishift addons remove <addon-name>’ will remove the specified
addon from the System. For more details see .
This release also includes many changes and bug fixes, which are
detailed in the release notes . For information about getting
started, using, and developing Minishift, see the documentation .
Please try the new release. The easiest upgrade path is by simply
running: '$ minishift update'. We are looking forward to your
The Minishift community hangs out at #minishift channel on Freenode
and it is the perfect place to discuss anything Minishift-related.
You can sign up for our mailing list to receive development
updates, questions about Minishift, suggest ideas, and talk to the
5 years, 8 months
Rollout of profile feature
by Hardy Ferentschik
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 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
5 years, 8 months