Project Description

Chimera is a Kubernetes policy engine. Its policies are WebAssembly modules, that can be published on regular OCI registries (same place where container images are pushed).

Each Chimera Policy lives inside of a dedicated Git repository and its build artifact lives inside of an OCI registry. For example, the pod-privileged-policy source code can be found inside of this GitHub repository, while its artifact can be downloaded from this public OCI registry.

The scope of this project is to simplify the discovery of Chimera Policies.

Goal for this Hackweek

Create a website where all the Chimera Policies are listed. Each Policy will have a series of attributes like: name, description, GitHub project, OCI registry, tags.

The website should allow the user to filter the policies by name, category and tags.

As a first iteration we would like to rely on GitHub Pages to host the entire website. The idea would be to create a GitHub repository and have in there a gh-pages branch with the following contents:

  • dataset.json: the list of policies to show
  • website resources: html, js, css,...

The dataset file will be managed by hand via pull requests. Each change done to the dataset or to any other file inside of this branch, will result in an automatic deployment of the website (GitHub does that automatically for us).

The website will do all the actions (render the main page with all the policies, search policies, show policy details,...) using client side code.

Resources

We need help from someone with front-end skills and experience developing client-side applications.

Looking for hackers with the skills:

javascript ux front-end web

This project is part of:

Hack Week 20

Activity

  • over 4 years ago: j_renner liked this project.
  • over 4 years ago: dleidi started this project.
  • over 4 years ago: dleidi liked this project.
  • over 4 years ago: flavio_castelli added keyword "javascript" to this project.
  • over 4 years ago: flavio_castelli added keyword "ux" to this project.
  • over 4 years ago: flavio_castelli added keyword "front-end" to this project.
  • over 4 years ago: flavio_castelli added keyword "web" to this project.
  • over 4 years ago: flavio_castelli originated this project.

  • Comments

    Be the first to comment!

    Similar Projects

    Kudos aka openSUSE Recognition Platform by lkocman

    Description

    Relevant blog post at news-o-o

    I started the Kudos application shortly after Leap 16.0 to create a simple, friendly way to recognize people for their work and contributions to openSUSE. There’s so much more to our community than just submitting requests in OBS or gitea we have translations (not only in Weblate), wiki edits, forum and social media moderation, infrastructure maintenance, booth participation, talks, manual testing, openQA test suites, and more!

    Goals

    • Kudos under github.com/openSUSE/kudos with build previews aka netlify

    • Have a kudos.opensuse.org instance running in production

    • Build an easy-to-contribute recognition platform for the openSUSE communit a place where everyone can send and receive appreciation for their work, across all areas of contribution.

    • In the future, we could even explore reward options such as vouchers for t-shirts or other community swag, small tokens of appreciation to make recognition more tangible.

    Resources

    (Do not create new badge requests during hackweek, unless you'll make the badge during hackweek)


    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:

    1. Execute arbitrary shell commands on thousand of remote machines simultaneously using Ansible Runner with artifacts saved locally.
    2. Pass runtime options such as inventory file, remote command string/ playbook execution, parallel forks, limits, dry-run mode, or no-std-ansible-output.
    3. Leverage existing SSH trust relationships without additional setup.
    4. Provide a clean, intuitive CLI interface with --help for ease of use. It should provide consistent UX & CI-friendly interface.
    5. 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):

    1. Add pretty output formatting (success/failure summary per host).
    2. Implement basic logging of executed commands and results.
    3. Introduce safety checks for risky commands (shutdown, rm -rf, etc.).
    4. 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:

    1. Python especially around CLI dev (argparse, click, rich)