Project Description
During the last 3 years working on zypper we constantly reiterated the idea to refactor zypper to get rid of a lot of cruft that has collected over the years ,but just recently I realized that we maybe should go one step further.
Meet velcro, a new frontend and backend server implemented in Rust that is completly agnostic to the way how software is installed and maintained on a system. It is utilizing backends that implement the specific application management behavior controlled over a generic, programming language agnostic protocol, to support backends in various languages.
The Velcro protocol will support a lot of different features in a generic way but its important that the backends can decide which one of those they want to support. The zypp backend will for example support something like patches, the flatpak backend however does not. The frontend needs to tell the user which featues are avaible.
The following concepts should be available in velcro:
Repository management: add , remove, modify, refresh package/application sources
Application management: add, remove applications/packages
Update: update all packages on the system,
Query: search for existing applications or packages
This is not another packagekit, we explicitely do not want to use D-Bus as a protocol language, this works only on full blown Linux installations and is not what we are looking for. We need a simple lightweight way of having backends using standard Linux facilities with minimal dependencies.
Goal for this Hackweek
Currently this is only a idea, but we should get all the details on how to communicate between the different velcro building blocks together and decide which IPC protocol is used. And hopefully start hacking on the prototype.
Resources
Looking for hackers with the skills:
rust packagemanagement softwaremanagement libzypp rpm flatpak snap
This project is part of:
Hack Week 20
Activity
Comments
Be the first to comment!
Similar Projects
A CLI for Harvester by mohamed.belgaied
[comment]: # Harvester does not officially come with a CLI tool, the user is supposed to interact with Harvester mostly through the UI [comment]: # Though it is theoretically possible to use kubectl to interact with Harvester, the manipulation of Kubevirt YAML objects is absolutely not user friendly. [comment]: # 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