Project Description
The idea for project starts on LEO workshop. The main goal is to provide UI for local configuration that allows easy transition to 1:N management. So here is vision:
- frontend: web-UI, GUI, TUI, CLI, whatever, for now lets start with CLI
- backend: salt/puppet/chef/ansible/cfengine. In general write config for CM and not config files itself.
- features: discovery/edit/create/apply on top of backend. Each step separated, so user can e.g. apply itself by using CM directly.
- default value is keep value as it is, so anything not specific is not modified, but when something is specified then it can "eat" modifications as do salt and others
- supported distros - openSUSE, SLE, ubuntu, debian, fedora at least
- communication between frontend and backend is a CLI and YAML file with defined structure, but not aiming to be any kind of new standard, just textual configuration to transfer data in human readable form.
Advantages:
- easily extensible as it use plugins like e.g. git
- can run as service similar way like e.g. salt server can run it via ssh
- easy move from 1:1 to 1:N
- does not repeat what CM can already do and gets many features for free.
- distro agnostic, so user can use same tool in heterogenous environment
- can work remotely
Disadvantages:
- Overwrite manual changes
- less features then specialized tools like YaST
Use Cases:
- I have one server that I am taking care. And as my project start growing I need more of them and want to have it consistently configured. So easily move from 1:1 to 1:N.
- Company already use salt and I get a task to manage also FTP server configuration over it. I want to experiment with it at first on single server with some UI that allows me to quickly create initial config and then tune it with more advanced settings.
- Company bought another one and they use salt and we are using ansible. Goal is to unify it. I want tool that helps me with conversion.
- I want to start with ansible and prefer GUI for easy start.
Goal for this Hackweek
- POC with users management
- discovery works
- CLI frontend
- salt and ansible backend
- works on opensuse TW and Ubuntu 20.04
- If time permit try quick GUI
- as API (see below) is YAML and CLI, then parts can be written in any language ( but please no shell )
API Proposal:
- as said above communication is done via CLI and yaml file
- discovery using some CM tool to discover and convert to YAML
- backend is just CLI that do YAML->target file(-s) for given CM
- frontend works on top of YAML + can call that CLI
- apply is just different CLI for given backend, additional features like dry run can be also supported by this CLI. machine output is must have
Resources
- Repo with project
-
This project is part of:
Hack Week 20
Activity
Comments
Be the first to comment!
Similar Projects
Testing and adding GNU/Linux distributions on Uyuni by juliogonzalezgil
Join the Gitter channel! https://gitter.im/uyuni-project/hackweek
Uyuni is a configuration and infrastructure management tool that saves you time and headaches when you have to manage and update tens, hundreds or even thousands of machines. It also manages configuration, can run audits, build image containers, monitor and much more!
Currently there are a few distributions that are completely untested on Uyuni or SUSE Manager (AFAIK) or just not tested since a long time, and could be interesting knowing how hard would be working with them and, if possible, fix whatever is broken.
For newcomers, the easiest distributions are those based on DEB or RPM packages. Distributions with other package formats are doable, but will require adapting the Python and Java code to be able to sync and analyze such packages (and if salt does not support those packages, it will need changes as well). So if you want a distribution with other packages, make sure you are comfortable handling such changes.
No developer experience? No worries! We had non-developers contributors in the past, and we are ready to help as long as you are willing to learn. If you don't want to code at all, you can also help us preparing the documentation after someone else has the initial code ready, or you could also help with testing :-)
The idea is testing Salt and Salt-ssh clients, but NOT traditional clients, which are deprecated.
To consider that a distribution has basic support, we should cover at least (points 3-6 are to be tested for both salt minions and salt ssh minions):
- Reposync (this will require using spacewalk-common-channels and adding channels to the .ini file)
- Onboarding (salt minion from UI, salt minion from bootstrap scritp, and salt-ssh minion) (this will probably require adding OS to the bootstrap repository creator)
- Package management (install, remove, update...)
- Patching
- Applying any basic salt state (including a formula)
- Salt remote commands
- Bonus point: Java part for product identification, and monitoring enablement
- Bonus point: sumaform enablement (https://github.com/uyuni-project/sumaform)
- Bonus point: Documentation (https://github.com/uyuni-project/uyuni-docs)
- Bonus point: testsuite enablement (https://github.com/uyuni-project/uyuni/tree/master/testsuite)
If something is breaking: we can try to fix it, but the main idea is research how supported it is right now. Beyond that it's up to each project member how much to hack :-)
- If you don't have knowledge about some of the steps: ask the team
- If you still don't know what to do: switch to another distribution and keep testing.
This card is for EVERYONE, not just developers. Seriously! We had people from other teams helping that were not developers, and added support for Debian and new SUSE Linux Enterprise and openSUSE Leap versions :-)
Pending
In progress
FUSS
FUSS is a complete GNU/Linux solution (server, client and desktop/standalone) based on Debian for managing an educational network.
https://fuss.bz.it/
Seems to be a Debian 12 derivative, so adding it could be quite easy.
[W]Reposync (this will require using spacewalk-common-channels and adding channels to the .ini file)[W]Onboarding (salt minion from UI, salt minion from bootstrap script, and salt-ssh minion) (this will probably require adding OS to the bootstrap repository creator) --> Working for all 3 options (salt minion UI, salt minion bootstrap script and salt-ssh minion from the UI).[W]Package management (install, remove, update...) --> Installing a new package works, needs to test the rest.[I]Patching (if patch information is available, could require writing some code to parse it, but IIRC we have support for Ubuntu already). No patches detected. Do we support patches for Debian at all?[W]Applying any basic salt state (including a formula)
Bring to Cockpit + System Roles capabilities from YAST by miguelpc
Bring to Cockpit + System Roles features from YAST
Cockpit and System Roles have been added to SLES 16 There are several capabilities in YAST that are not yet present in Cockpit and System Roles We will follow the principle of "automate first, UI later" being System Roles the automation component and Cockpit the UI one.
Goals
The idea is to implement service configuration in System Roles and then add an UI to manage these in Cockpit. For some capabilities it will be required to have an specific Cockpit Module as they will interact with a reasource already configured.
Resources
A plan on capabilities missing and suggested implementation is available here: https://docs.google.com/spreadsheets/d/1ZhX-Ip9MKJNeKSYV3bSZG4Qc5giuY7XSV0U61Ecu9lo/edit
Linux System Roles: https://linux-system-roles.github.io/
A CLI for Harvester by mohamed.belgaied
Harvester does not officially come with a CLI tool, the user is supposed to interact with Harvester mostly through the UI. Though it is theoretically possible to use kubectl to interact with Harvester, the manipulation of Kubevirt YAML objects is absolutely not user friendly. Inspired by tools like multipass from Canonical to easily and rapidly create one of multiple VMs, I began the development of Harvester CLI. Currently, it works but Harvester CLI needs some love to be up-to-date with Harvester v1.0.2 and needs some bug fixes and improvements as well.
Project Description
Harvester CLI is a command line interface tool written in Go, designed to simplify interfacing with a Harvester cluster as a user. It is especially useful for testing purposes as you can easily and rapidly create VMs in Harvester by providing a simple command such as:
harvester vm create my-vm --count 5
to create 5 VMs named my-vm-01 to my-vm-05.
Harvester CLI is functional but needs a number of improvements: up-to-date functionality with Harvester v1.0.2 (some minor issues right now), modifying the default behaviour to create an opensuse VM instead of an ubuntu VM, solve some bugs, etc.
Github Repo for Harvester CLI: https://github.com/belgaied2/harvester-cli
Done in previous Hackweeks
- Create a Github actions pipeline to automatically integrate Harvester CLI to Homebrew repositories: DONE
- Automatically package Harvester CLI for OpenSUSE / Redhat RPMs or DEBs: DONE
Goal for this Hackweek
The goal for this Hackweek is to bring Harvester CLI up-to-speed with latest Harvester versions (v1.3.X and v1.4.X), and improve the code quality as well as implement some simple features and bug fixes.
Some nice additions might be: * Improve handling of namespaced objects * Add features, such as network management or Load Balancer creation ? * Add more unit tests and, why not, e2e tests * Improve CI * Improve the overall code quality * Test the program and create issues for it
Issue list is here: https://github.com/belgaied2/harvester-cli/issues
Resources
The project is written in Go, and using client-go the Kubernetes Go Client libraries to communicate with the Harvester API (which is Kubernetes in fact).
Welcome contributions are:
- Testing it and creating issues
- Documentation
- Go code improvement
What you might learn
Harvester CLI might be interesting to you if you want to learn more about:
- GitHub Actions
- Harvester as a SUSE Product
- Go programming language
- Kubernetes API
- Kubevirt API objects (Manipulating VMs and VM Configuration in Kubernetes using Kubevirt)
Rewrite Distrobox in go (POC) by fabriziosestito
Description
Rewriting Distrobox in Go.
Main benefits:
- Easier to maintain and to test
- Adapter pattern for different container backends (LXC, systemd-nspawn, etc.)
Goals
- Build a minimal starting point with core commands
- Keep the CLI interface compatible: existing users shouldn't notice any difference
- Use a clean Go architecture with adapters for different container backends
- Keep dependencies minimal and binary size small
- Benchmark against the original shell script
Resources
- Upstream project: https://github.com/89luca89/distrobox/
- Distrobox site: https://distrobox.it/
- ArchWiki: https://wiki.archlinux.org/title/Distrobox
Create an Android app for Syncthing as part of the Syncthing Tray project by mkittler
Description
There's already an app but code/features already in Syncthing Tray could be reused to create a nicer app with additional features like managing ignore patterns more easily. The additional UI code for the app could then in turn be re-used by other parts of Syncthing Tray, e.g. to implement further steps in the wizard as requested by some users. This way one "UI wrapper codebase" could serve GNU/Linux, Windows and Android (and in theory MacOS) at the same time which is kind of neat.
Goals
- DONE: Learn more about development for Android and development of UIs with Qt Quick
- DONE: Create an experimental app reusing as much existing Syncthing Tray code as possible
- DONE: Build Syncthing as a library also for Android and use it in the app (already done but needs further testing and integration with the rest of the app configuration)
- DONE: Update the Syncthing Tray website, documentation
- DONE: Extend the app so it has at least a start page and an import
- Update forum thread
- DONE: Upload an experimental build on GitHub
- Extend the Syncthing API to download single files on demand (instead of having to sync the whole directory or use ignore patterns)
- Bring back parts of the newly developed mobile UI back to Syncthing Tray on the desktop to fully benefit from the cross-platform development
- Add UI to add/edit folders and devices in desktop tray app
- Add UI to show out-of-sync items in desktop tray app
- Create an alternative "AppWindow" tailored for desktop platforms reusing UI components developed for the mobile app
Resources
- Android SDK/NDK and emulator
- Qt Quick