feat: Introduce kind Immutable#658
Draft
ralgozino wants to merge 64 commits into
Draft
Conversation
- Introduced new Immutable kind in the KFD API with associated functionalities. - Implemented ClusterCreator, ClusterDeleter, CertificatesRenewer, and KubeconfigGetter for the Immutable kind. - Added ExtraSchemaValidator for Immutable kind to validate schemas. - Updated schema.go to include the new Immutable kind in the ExtraSchemaValidatorFactory.
- Introduced a new validation framework in `schema.go` to ensure the integrity of the Immutable KFD configuration. - Added various validation checks including cluster name length, node configuration, uniqueness of hostnames, MAC addresses, and IP addresses. - Implemented cross-reference checks for control plane, etcd, and node group members to ensure they reference existing nodes. - Added network validation to check for CIDR overlaps and IP consistency with infrastructure nodes. - Enhanced HA validation to provide warnings for sub-optimal configurations. - Introduced a logging mechanism for validation warnings using logrus. - Added utility functions for IP extraction and CIDR overlap checks in `ip.go`.
…figs - Add `infrastructure_generate.go` to handle the generation of node configurations, including install and bootstrap Butane files, and their conversion to Ignition. - Introduce templates for control plane, load balancer, and worker nodes in Butane format. - Create a new `Infrastructure` struct in the `create` package to manage the infrastructure phase. - Implement tests for the infrastructure generation logic, covering folder structure creation, template rendering, and config extraction. - Embed Butane templates for easier access and rendering during the configuration generation process.
- Introduced new configuration management for infrastructure, merging user-defined settings with defaults. - Added support for dynamic retrieval of SSH user, Flatcar version, and install disk settings from configuration. - Enhanced the Prepare method to initialize configuration values and render Butane templates for nodes. - Implemented a new method to split multi-document YAML files generated by Butane into individual files per node. - Removed deprecated Butane templates for control plane, load balancer, and worker nodes, consolidating template management. - Added a ToolValidator to ensure required tools are available for different operation phases. - Updated the ClusterCreator to handle the new configuration structure and improved error handling. - Created a sample configuration file (furyctl.yaml) for user reference. - Added support for schema paths and validation for supported phases in the Immutable kind.
…lates for Kubernetes
add a basic implementation of the serve command that starts an HTTP server to serve assets from a defined path and waits for user confirmation to stop
- Implement tests for reading SSH public keys from specified paths. - Cover scenarios including privateKeyPath, keyPath (deprecated), both specified, explicit publicKeyPath, derived publicKeyPath, and error cases. - Ensure proper handling of empty public key files and non-existent public key files. - Include environment variable expansion in path testing.
WIP: A base cabling of kubernetes, distribution and plugins phases for Immutable kind based on what kind OnPremises does.
Add missing pieces so the infrastructure phase for Immutable is run when running furyctl apply. Add dummy file to the ugprades paths, otherwise furyctl fails, can be removed once we have an upgrade path
Add support for Immutable kind in the get supported-versions command. Render table dynamically so we don't have to adjust manually the spacing when the data changes.
Update unit tests for the get supported-versions output to include Immutable kind.
Stop using the extractos for OnPrem and use the extractors for Immutable instead. Add extractors for the Infrastructure phase.
Tack node's status via the ipxeServer. Nodes will send an update to a /status endpoint when the are installing the OS and when the have booted. furyctl will let the user know when all the nodes are in booted stated.
Render files at the root of the infrastructure templates folder. Allows for example to render the boot.ipxe file.
Use better names for igntion files: - bootstrap is now install-flatcar.json - install is now node-config.json Update directories, variables and function names accordingly
- Refactor infrastructure phase logic with new nomenclature for the butane (and ignition) files. - Remove unused code. - Remove unneeded methods. - Improve logging. - Linting.
Automatically continue when all nodes have booted instead of waiting for user confirmation.
- Pass also the flatcar version to the templates so they can build the right URL to download the Flatcar image. - Make the Downloader client NOT decompress the downloaded files for the Flatcar image, otherwise the flatcar-install will try to deflate it again. - Download the signature of the Flatcar image when downloading the image.
Remove unneeded helper wrapper funcs to check for binaries in cache when downloading assets. Our packages already do that.
Don't try to save the status to the cluster when running the infrastructure phase alone until the cluster has been created.
Ask for user confirmation when there are unsafe changes (unsafe reducers) to the infrastructure phase
Close waiting for user input channel when all nodes have booted otherwise we will try to close the server if the user presses enter even if it already has been closed when all nodes booted.
Write supported versions table to standard output instead of using logrus.Info. Relates to: #651
Remove configData from the Infrastructure phase signature because we don't need the merged configuration in this phase. The defaults that are merged with the user data are only available for the distribution phase.
Reduce cyclomatic complexity in Creator logic of Immutable kind by moving the confirmation logic to dedicated funcs
We want to have this code duplicated, because each provider can have different schemas and support different phases, so having a common base is a downside that could introduce changes in a provider that are not wanted.
Improve confirmation messages showing WARN logs and a descriptive prompt when manual intervention or dangerous changes are detected.
Add `**` as recursive matcher for the extractions rules. This can be used to match changes on any of the child nodes of a path, simplifying the number of rules needed.
Port some linting changes on error wrapping from #659
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary 💡
Caution
Work in progress
Introduce a new
Immutablekind, based on Flatcar Container Linux, in alpha status. Note that all the usual features for a kind are supported yet (notably updates).This PR relies on the new kind also being introduced to the distribution in the related PR below.
Relates:
Description 📝
This PR introduces changes to furyctl to support a new
Immutablekind for the SIGHUP Distritbution based on Flatcar Container Linux.This new kind is a sibling of the OnPremises kind, the main difference being that we now support an
infrastructurephase that takes care of creating and configuring the machines via iPXE that later will be the loadbalancers and kubernetes nodes.This PR adds support for the
immutablekind to following features of furyctl:furyctl apply: creates an Immutable cluster from scratch and reconfigures it on each apply, including all the phases:infrastructure,kubernetes,distribution, andplugins.furyctl apply --phase <phase>: supported.furyctl apply --post-apply-phase <phase>: supportedfuryctl apply --upgrade: exits saying that no upgrade paths are available.furyctl get kubeconfig: supported.furyctl get upgrade-paths: supported.furyctl get supported-versions: supported.furyctl download dependencies: supported.furcytl delete cluster: not supported by exits gracefully with a non implemented error.furyctl diff: not supported yet.furyctl dump templates: not supported yet.furyctl renew certificates: supported.furyctl validate dependencies: supported.furyctl validate downloads: supported.furyctl, for the new Immutable kind, handles also downloading Flatcar assets (kernel, initramfs, disk image, sysexts) that are defined in the immutable.yaml file present in the installer-immutable repository.
The version of the installer is specified in the distribution's kfd.yaml file like for the other installers.
New features
The following features, required by this new kind, have been added to furyctl:
furyctl servecommand that starts an HTTP server to serve static files from a path.**recursive matcher to rules extractor. Allowing to specify immutability rules for fields and all its children without needing to specify all of them.Breaking Changes 💔
None
Tests performed 🧪
All the commands specified in the description have been tested. Changes should impact only this new kind and the other kinds are untouched.
Future work 🔧