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
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)
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