Implemented a production-ready K3s Kubernetes installer with full lifecycle
support including installation, startup management, and cleanup.
Key features:
- Install first master (cluster init), join additional masters (HA), and workers
- Systemd service management via StartupManager abstraction
- IPv6 support with Mycelium interface auto-detection
- Robust destroy/cleanup with proper ordering to prevent hanging
- Complete removal of services, processes, network interfaces, and data
- Add `reset` boolean parameter to `StartArgs` struct
- Pass `reset` parameter to `startupcmd` calls
- Update service creation logic to handle `reset` flag
- Modify `install_start` and `restart` to pass `reset` parameter
- Add `create: true` to service `get` calls
- Update `running_check` to use `curl` for HTTP status code
- Ensure redis addresses have `redis://` prefix
- Clean up and re-create zinit services before starting
- Remove redundant `service_monitor` call in `startupmanager.start`
Merge the two separate if blocks for handling actions into a single block
since they both use the same logic for getting the name parameter with
get_default('name', 'default').
Changes:
- Combine destroy/install/build and start/stop/restart/lifecycle blocks
- All actions now use consistent name parameter handling
- Reduces code duplication in play() functions
Updated files:
- All 5 horus installer factory files
- Generator template objname_factory_.vtemplate
- Convert all module-level functions to methods on config structs
- Add InstallArgs struct with reset parameter to actions files
- Update factory play() functions to call instance methods with name parameter
- Remove duplicate InstallArgs and wrapper methods from factory files
- Add support for start_pre, start_post, stop_pre, stop_post as callable actions
- Rename running() to running_check() to avoid conflicts
- All lifecycle methods (install, destroy, build, start, stop, etc.) now accept optional name parameter
Affected installers:
- coordinator
- supervisor
- herorunner
- osirisrunner
- salrunner
This provides a cleaner, more consistent API where all installer actions
can be called on specific configuration instances from heroscript files.
- Change default `ArgsGet.name` to 'default'
- Remove logic for overriding `args.name` with `coordinator_default`
- Set `coordinator_default` directly to `args.name`
- Update default coordinator name to 'coordinator'
- Improve status reporting by using dedicated variables
- Adjust `zinit.get` call to use `create: true`
- Set `zinit_default` based on `args.name` when 'default' is provided
- Update `coordinatorServer.name` default to 'coordinator'
- Make 'coordinator' the default for `ArgsGet.name`
- Use `coordinator_default` for `ArgsGet.name` if set
- Adjust `CoordinatorServer.binary_path` default
- Update `zinit.get` to use `create: true`
- Log socket closure for debugging
- Remove unused import `incubaid.herolib.core.texttools`
- Removed the unused files
- Updated the README
- Added all needed scripts in /scripts dir
- Update script paths in CI configuration
- Update script paths in Go code
- Move installation scripts to scripts directory
- Change script path from ./install_v.sh to ./scripts/install_v.sh
- Remove all Redis installation logic from coordinator installer
- Add osal.cmd_exists() check before installing Rust
- Update docs: Redis must be pre-installed
- Add reset flag documentation for forcing rebuilds
- Coordinator now only installs Rust and builds binary
- Add redis_port field to CoordinatorServer struct
- Refactor ensure_redis_running() to use @[params] pattern
- Pass redis_port and redis_addr dynamically from config
- Follow same pattern as cryptpad installer for consistency
- Moved coordinator installer from installers/infra to installers/horus
- Renamed HerocoordinatorServer to CoordinatorServer
- Fixed Redis installer permissions for /var/lib/redis directory
- Integrated coordinator with new modular Redis installer
- Created coordinator installer
- Migrated Redis installer to new modular pattern (_model.v, _actions.v, _factory_.v)
- Fixed Redis config template for 7.0.15 compatibility (commented out unsupported directives)
- Added Redis dependency check to coordinator installer
- Coordinator now auto-installs and starts Redis if not available
- Added progress indicators to coordinator build process
- Consolidated Redis example scripts
- All tests passing: Redis installation, coordinator build, and idempotency verified
Refactors the CryptPad installer to improve its configuration handling.
- The `hostname` and `namespace` are now derived from the installer's `name` property by default.
- Implemented name sanitization to remove special characters (`_`, `-`, `.`).
- Added validation to ensure the namespace does not contain invalid characters.
- Updated the factory's `reload` function to persist changes made to the installer object after its initial creation.
This change ensures consistent and predictable behavior, allowing for both default generation and manual override of configuration values.
Co-authored-by: Mahmoud-Emad <mahmmoud.hassanein@gmail.com>
- Add PostgreSQL configuration options
- Generate PostgreSQL YAML when selected
- Verify PostgreSQL pod readiness
- Update documentation for PostgreSQL usage
- Add PostgreSQL service and pod definitions
- Add Gitea installer module and types
- Implement installation and destruction logic
- Integrate with Kubernetes and TFGW
- Add example usage and documentation
- Update element chat default name to 'elementchat'
- Sanitize element chat name from invalid characters
- Set default namespace based on sanitized name
- Validate namespace for invalid characters
- Update documentation with new default values
This commit refactors the CryptPad Kubernetes installer to be more dynamic and configurable structure.
Key changes include:
- **Dynamic Configuration**: The installer now generates its configuration based on parameters passed from the `.vsh` script, with sensible defaults for any unspecifie
d values.
- **Templated `config.js`**: Introduced a new `config.js` template to allow for greater flexibility and easier maintenance of the CryptPad configuration.
- **Improved Code Structure**: The source code has been updated to be more modular and maintainable.
- **Updated Documentation**: The `README.md` has been updated to include instructions on how to run the installer and customize the installation.
Co-authored-by: Mahmoud-Emad <mahmmoud.hassanein@gmail.com>
- Add Element Chat installer module
- Integrate Conduit and Element Web deployments
- Support TFGW integration for FQDNs and TLS
- Implement installation and destruction logic
- Generate Kubernetes YAML from templates
Co-authored-by: peternashaaat <peternashaaat@gmail.com>
- Use installer.kube_client for Kubernetes operations
- Remove redundant startupmanager calls
- Simplify `delete_resource` command
- Add default values for installer name and hostname
- Refactor `get` function to use new arguments correctly
- Remove commented out example code and unused imports
- Change the factory file<REQUIRED> to load the default instance name
- Update the README file of the installer
Co-authored-by: peternahaaat <peternashaaat@gmail.com>
- Replace kubectl exec calls with Kubernetes client methods
- Improve error handling and logging in Kubernetes client
- Enhance node information retrieval and parsing
- Add comprehensive unit tests for Kubernetes client and Node structs
- Refine YAML validation to allow custom resource definitions
- Update CryptPad installer to use the refactored Kubernetes client
Refactor the installer to use global constants for the maximum number of retries and the check interval when verifying deployments.
This change removes hardcoded values from the FQDN and deployment status checks, improving maintainability and centralizing configuration.
- Add install functionality for kubectl
- Implement destroy functionality for kubectl
- Add platform-specific download URLs for kubectl
- Ensure .kube directory is created with correct permissions
