Issue with secret: no auth handler was found for secrets....
by Oliver Weise
Hi,
FWIW: I had a similar issue when using a secret with an SSH private key as source secret, when the key entry was not named "ssh-privatekey" but something else. Because of this OpenShift could not determine the type of authentication to use. My working secret now:
apiVersion: v1
data:
ssh-privatekey: ...
kind: Secret
metadata:
name: bitbucket-login-lsc2-worker
type: Opaque
So, the secret entry holding your credentials might have an invalid name too? Maybe crosscheck the entry name with a secret that you know is working?
Cheers, Oliver
4 years, 10 months
oc cluster up changes in origin v3.10 and Minishift 2.0
by Lalatendu Mohanty
Hi,
You might be aware that OpenShift team is restructuring/re-architecting
the "oc cluster up" code base in v3.10. Hence in Minishift we are trying to
adapt these changes [2].
In the recent discussion with OpenShift developers we came to know that the
remote docker support in "cluster up" is fragile and it will bring more
trouble for future OpenShift features which needs to be enabled in "cluster
up". Refer [1] for more details. Also one of the major reason the remote
docker daemon support is present in "cluster up" to support Minishift.
Minishift uses the remote docker scenario i.e. the docker daemon runs
inside the Minishift VM and we use the oc binary on the host to run the "oc
cluster up" using the remote docker daemon in the VM.
One of the important expectation of Minishif users is around ability to
use/try new features of OpenShift in Minishift. It seems the remote docker
daemon support in "cluster up" is going to make things difficult or hard to
implement new features to "cluster up". Which will also make things more
prone to bugs, bad user experience etc.
I would like to suggest that we drop the support for remote docker in
Minishift. However doing so will make the code backward incompatible to
earlier versions of OpenShift and couple of features (e.g. add-ons) needs
to be checked and modified to suit to the new implementation. This will
also make things more simple/maintanable for OpenShift developers too.
So we should go ahead with Minishift 2.0.0 (major version change) and if
required we can maintain the previous version of Minishift i.e. v1.x for
sometime (only blocker bugs or security fixes) as will help if someone
needs to run older versions of OpenShift with Minishift.
Sugestions, comments?
[1] https://github.com/minishift/minishift/issues/2377
[2] https://github.com/minishift/minishift/pull/2336
Thanks,
Lala
4 years, 10 months
Release announcement for Minishift 1.17.0
by Anjan Nath
Hi All,
The Minishift team is pleased to announce the release of
Minishift 1.17.0.
Minishift [1] 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.
In version 1.17.0, we added some enhancements and bug fixes including:
An option to skip/ignore preflight checks during startup
- Run 'minishift start --skip-startup-checks’
Print https URLs in the output of ‘minishift openshift service list’ command
You can find a detailed list of issues in the release notes[2].
For information about getting started, using, and developing Minishift, see the
documentation [3].
Please try the new release.
The easiest upgrade path is by simply running:
$ minishift update
We are looking forward to your feedback.
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 [4] to receive development updates, ask
questions about Minishift, suggest ideas and talk to the community.
[1] https://github.com/minishift/minishift
[2] https://github.com/minishift/minishift/releases/tag/v1.17.0
[3] https://docs.openshift.org/latest/minishift
[4] https://lists.minishift.io/admin/lists/minishift.lists.minishift.io
4 years, 10 months
