* Kicbase/ISO: Update cni-plugins from v1.6.2 to v1.7.1
* Updating kicbase image to v0.0.46-1747341282-20771
* Updating ISO to v1.35.0-1747341198-20771
* Update service tests to use-
discoveryv1.EndpointSlice instead of deprecated core.Endpoints
This PR addresses the deprecation warnings for core.Endpoints which is deprecated in Kubernetes v1.33+ in favor of discoveryv1.EndpointSlice.
Changes:
- Replaced all core.Endpoints references with discoveryv1.EndpointSlice
- Updated mock interfaces and test data structures to use the new API
- Maintained all existing test functionality and assertions
- No behavioral changes - just API modernization
Fixes#20677
* fixed lint issue
- make lint now runs without error
* Fix multiple panics in pkg/minikube/service tests by improving mock client initialization
This commit addresses a series of nil pointer dereference panics in the test suite for pkg/minikube/service, ensuring all tests pass reliably. The changes focus on improving the initialization of mock Kubernetes clients to prevent nil pointer dereferences in the fake client's `Invokes` method. The fixes include:
1. **TestPrintURLsForService/throw_error_without_template Panic**:
- Issue: A panic occurred due to an uninitialized `FakeCoreV1` field in `MockCoreClient`, causing a nil pointer dereference when `Services().Get` was called.
- Fix: Initialized `FakeCoreV1` with `Fake: &testing_fake.Fake{}` in the `TestPrintURLsForService` setup, ensuring the fake client is properly configured.
2. **TestGetServiceURLs/correctly_return_serviceURLs Panic**:
- Issue: A similar panic occurred in `GetServiceURLs` due to the `FakeCoreV1` field not being initialized in `MockCoreClient` returned by `MockClientGetter`.
- Fix: Updated `MockClientGetter.GetCoreClient` to initialize `FakeCoreV1` with `Fake: &testing_fake.Fake{}`, ensuring all tests using `MockClientGetter` have a properly initialized client.
3. **TestDeleteSecret/ok Panic**:
- Issue: A panic occurred in `DeleteSecret` when calling `secrets.Delete` for the `foo` namespace, as `secretsNamespaces` lacked an entry for `foo`, returning a nil interface.
- Fix: Added a `MockSecretInterface` for the `foo` namespace to `secretsNamespaces`, ensuring `client.Secrets("foo")` returns a valid interface. Updated `initializeMockObjects` to verify the `Fake` field for the new entry.
Additional improvements:
- Ensured `initializeMockObjects` consistently initializes `Fake` fields across all mock interfaces (`serviceNamespaces`, `serviceNamespaceOther`, `endpointSliceNamespaces`, and `secretsNamespaces`).
- Verified that all test setups align with mock configurations, preventing similar issues in other tests (e.g., `TestCreateSecret`, `TestWaitAndMaybeOpenService`).
- Confirmed no linting issues with `make lint` and validated all tests pass with `go test -v ./pkg/minikube/service/...`.
* Kicbase/ISO: Update cri-dockerd from v0.3.15 to v0.4.0
* Updating kicbase image to v0.0.46-1747166185-20747
* Updating ISO to v1.35.0-1747160120-20747
* build: Fix docker run when selinux is enabled
When mouting volumes we need to use :Z suffix to allow access to the
mounted directory. This fixes docker run when running on Fedora an other
distros using selinux by default.
* build: Use jammy based xcgo image for hyperkit
Image was built from:
https://github.com/nirs/xcgo
Maybe we need to add this repo under the minikube organization or
include the code in minikube repo.
With this I could build hyperkit using:
$ make hyperkit_in_docker
$ file out/docker-machine-driver-hyperkit
out/docker-machine-driver-hyperkit: Mach-O 64-bit x86_64 executable, flags:<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE>
* Addon configuration now takes an optional config file to load from
instead of forcing prompts
Fixes#20124
* Using a rarer value for default instead of changeme so it has less chance to interfere with other possible user defaults
* Fixing expected values of test cases
* making addonConfigFile private
* Keeping registry_creds configs together.
* Starting a typed AddonConfig struct so each addon con loads its
configs in a typed way.
* Started configs for RegistryCreds using this convention and moved
registry_creds config processing to its own file
(configure_registry_creds.go)
* Making registry creds structs private and other PR feedback cleanups
* Changing default value back to 'changeme'
* Simplifying duplicate consts
* Adding missed comma
* lint fixes
* Generating docs
* Copyright for new file
* vmnet: Improve --network vmnet-shared validation
Previously we did not check that the helper can run with the
--close-from=4 option, so the command could succeed when incorrect
sudoers configuration. For example a user with liberal NOPASSWD rule,
but without the closefrom_override option.
When the check failed, we log unhelpful log:
libmachine: Failed to run vmnet-helper:
%!w(*exec.ExitError=&{0x14000135e30 [115 117 100 111 58 32 97 ... 101 100 10]})
And we returned a bool, so the caller could not provide a suggestion how
to resolve the issue.
Fix by:
- Rename vment.HelperAvaialble to vment.ValidateHelper
- Return an error describing the issue, including a reason.Kind that can
be used to provide a suggestion for resolving the issue.
- Include the ExitError.Stderr int the error. This includes helpful
error messages from sudo.
- Add new reason.NotConfiguredVmnetHelper error
- Improve log when vment.ValidateHelper() succeeded
Example error flow - vment-helper not installed:
% minikube start --driver vfkit --network vmnet-shared
😄 minikube v1.35.0 on Darwin 15.4.1 (arm64)
✨ Using the vfkit (experimental) driver based on user configuration
🙈 Exiting due to NOT_FOUND_VMNET_HELPER: failed to validate vmnet-shared network:
stat /opt/vmnet-helper/bin/vmnet-helper: no such file or directory
💡 Suggestion:
vmnet-helper was not found on the system, resolve by:
Option 1) Installing vmnet-helper:
https://github.com/nirs/vmnet-helper#installation
Option 2) Using the nat network:
minikube start<no value> --driver vfkit --network nat
I resolved the issue by installing vmnet-helper but I did not configured
the sudoers rule:
% minikube start --driver vfkit --network vmnet-shared
😄 minikube v1.35.0 on Darwin 15.4.1 (arm64)
✨ Using the vfkit (experimental) driver based on user configuration
🙈 Exiting due to NOT_CONFIGURED_VMNET_HELPER: failed to validate vmnet-shared network:
exit status 1: sudo: you are not permitted to use the -C option
💡 Suggestion:
Configure vmnet-helper to run without a password.
Please install a vmnet-helper sudoers rule using these instructions:
https://github.com/nirs/vmnet-helper#granting-permission-to-run-vmnet-helper
After installing the sudoers rule minikube could start.
* vfkit: Use helper --socket instead of --fd
The --fd option avoids the need to manage a bound unix sockets, in
particular the limit on unix socket length. It is also more secure;
only the process inheriting the socket can access the helper. However it
requires the sudo --close-from= option, which may not work for some
users. We don't understand why it does not work, and debugging it is
hard since users are not happy to share their local sudoers
configuration.
Avoid the trouble by switching to the --socket option. In this case we
pass a unix socket path to the helper and vfkit. The helper creates a
bound unix datagram socket in the specified path, and waits until vfkit
connects to the socket. When vfkit connects to the unix socket the
programs are connected in the same way they are connected by passing
file descriptors.
When running minikube we will see 3 new files in the machine directory:
- `vfkit-fb64-7802.sock`: vfkit unix datagram socket
- `vmnet-helper.sock`: vmnet-helper unix datagram socket
- `vmnet-helper.sock.lock`: lockfile for vment-helper socket
The files are deleted when vmnet-helper and vfkit are terminated
gracefully. If they are killed the stale files are replaced on the next
start.
Issues:
- If the path exceeds the limit (104 characters), opening the socket
will fail. We have the sames issue with vfkit management socket.
* vment: Fallback to interactive sudo
If vmnet-helper sudoers rule is not configured or does not work for the
user, maybe because the user has disabled the NOPASSWD option, we used
to fail, recommending to configure vmnet sudoers rule. This does not
help a user that cannot fix the sudoers configuration.
Since we switched to --socket mode, we can work without a sudoers rule.
If we can interact with the user, we fall back to interactive sudo. The
user can enter a password to start the machine.
Example run with --interactive=false:
% minikube start --driver vfkit --network vmnet-shared --interactive=false
😄 minikube v1.35.0 on Darwin 15.4.1 (arm64)
✨ Using the vfkit (experimental) driver based on user configuration
🙈 Exiting due to NOT_CONFIGURED_VMNET_HELPER: failed to validate vmnet-shared network:
exit status 1: sudo: a password is required
💡 Suggestion:
Configure vmnet-helper to run without a password.
Please install a vmnet-helper sudoers rule using these instructions:
https://github.com/nirs/vmnet-helper#granting-permission-to-run-vmnet-helper
Example run with --interactive (default):
% minikube start --driver vfkit --network vmnet-shared
😄 minikube v1.35.0 on Darwin 15.4.1 (arm64)
✨ Using the vfkit (experimental) driver based on user configuration
💡 Unable to run vmnet-helper without a password
To configure vment-helper to run without a password, please check the documentation:
https://github.com/nirs/vmnet-helper/#granting-permission-to-run-vmnet-helper
Password:
👍 Starting "minikube" primary control-plane node in "minikube" cluster
🔥 Creating vfkit VM (CPUs=2, Memory=6000MB, Disk=20000MB) ...
🐳 Preparing Kubernetes v1.33.0 on Docker 27.4.0 ...
▪ Generating certificates and keys ...
▪ Booting up control plane ...
▪ Configuring RBAC rules ...
🔗 Configuring bridge CNI (Container Networking Interface) ...
🔎 Verifying Kubernetes components...
▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5
🌟 Enabled addons: storage-provisioner, default-storageclass
🏄 Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default