It has probably already happened to you: Creating volume /dev/sda2 failed with error -1008 Did it tell anything useful to you? Maybe if Storage gave you some more info, you could have continued, fix the problem by yourself.
This project has been already discussed during CSM Workshop. Here are some hints: aschnell: The infrastructure is available, just add some hundred messages to getErrorString() in Storage.cc. aschnell: One could of course also use exceptions but that looks like a task for more than a weeks work. mvidner: The method link is Storage::getErrorString. A quick and dirty way would be to simply add the raw identifiers from enum ErrorCodes: case DISKREMOVEPARTITIONINVALIDVOLUME: return "DISKREMOVEPARTITIONINVALIDVOLUME";
No Hackers yet
Looking for hackers with the skills:
This project is part of:
Hack Week 11
Activity
Similar Projects
openSUSE on ZoL from OpenZFS project by jkohoutek
Idea is to have SUSE system with OpenZFS as root FS.
Why ZFS
Ways in which ZFS is better than BTRFS
Main goal
Have OpenZFS as install option in the installer and utilize zedenv Boot Environment Manager for SUSE updates install
Goals
- synergy of ZFS with dracut, so snapshots are correctly added to the grub
- synergy of zedenv with zypper
- before every update snapshot is created
- when new kernel or other package which requires reboot is about to be installed, the update will be processed to the new boot environment snapshot and grub configuration changed to boot to this new one
- integrate Root on ZFS as install option to the YaST
- configure Kiwi for the ZFS install images
Completed goals
- prepare ZFS pool compatible with openSUSE installation ✓
- install openSUSE with root on ZFS ✓
- boot to the prepared and installed system ✓
Resources:
mgr-ansible-ssh - Intelligent, Lightweight CLI for Distributed Remote Execution by deve5h
Description
By the end of Hack Week, the target will be to deliver a minimal functional version 1 (MVP) of a custom command-line tool named mgr-ansible-ssh (a unified wrapper for BOTH ad-hoc shell & playbooks) that allows operators to:
- Execute arbitrary shell commands on thousand of remote machines simultaneously using Ansible Runner with artifacts saved locally.
- Pass runtime options such as inventory file, remote command string/ playbook execution, parallel forks, limits, dry-run mode, or no-std-ansible-output.
- Leverage existing SSH trust relationships without additional setup.
- Provide a clean, intuitive CLI interface with --help for ease of use. It should provide consistent UX & CI-friendly interface.
- Establish a foundation that can later be extended with advanced features such as logging, grouping, interactive shell mode, safe-command checks, and parallel execution tuning.
The MVP should enable day-to-day operations to efficiently target thousands of machines with a single, consistent interface.
Goals
Primary Goals (MVP):
Build a functional CLI tool (mgr-ansible-ssh) capable of executing shell commands on multiple remote hosts using Ansible Runner. Test the tool across a large distributed environment (1000+ machines) to validate its performance and reliability.
Looking forward to significantly reducing the zypper deployment time across all 351 RMT VM servers in our MLM cluster by eliminating the dependency on the taskomatic service, bringing execution down to a fraction of the current duration. The tool should also support multiple runtime flags, such as:
mgr-ansible-ssh: Remote command execution wrapper using Ansible Runner
Usage: mgr-ansible-ssh [--help] [--version] [--inventory INVENTORY]
[--run RUN] [--playbook PLAYBOOK] [--limit LIMIT]
[--forks FORKS] [--dry-run] [--no-ansible-output]
Required Arguments
--inventory, -i Path to Ansible inventory file to use
Any One of the Arguments Is Required
--run, -r Execute the specified shell command on target hosts
--playbook, -p Execute the specified Ansible playbook on target hosts
Optional Arguments
--help, -h Show the help message and exit
--version, -v Show the version and exit
--limit, -l Limit execution to specific hosts or groups
--forks, -f Number of parallel Ansible forks
--dry-run Run in Ansible check mode (requires -p or --playbook)
--no-ansible-output Suppress Ansible stdout output
Secondary/Stretched Goals (if time permits):
- Add pretty output formatting (success/failure summary per host).
- Implement basic logging of executed commands and results.
- Introduce safety checks for risky commands (shutdown, rm -rf, etc.).
- Package the tool so it can be installed with pip or stored internally.
Resources
Collaboration is welcome from anyone interested in CLI tooling, automation, or distributed systems. Skills that would be particularly valuable include:
- Python especially around CLI dev (argparse, click, rich)