Make orthos/cobbler more ansible aware
an idea by trenn
Updated almost 3 years ago. No love. 1 follower. Has no hacker: grab it!

Enhance ansible usage in orthos

What is this about

ansible is an interesting approach to manage machines inside a network, cluster, data center,... If you already have some background, great! If you want to learn more about what this new technology is..., even better. Come in, join and play with it.

Orthos already makes use of ansible to scan machine inventory, but it's not implemented well:

  • Some data (json based result file) is mapped wrongly (e.g. cpu core count on ARM)
  • Some is missing, e.g. which distro got installed is still done by old scripts
  • A not well implemented inventory.yml creation should get replaced by using mainline dynamic ansible inventory plugin: cobbler.py
  • Ideally the inventory.yml could get kind of exported, so that the ordinary users can make use of it and by that have all ansible scripts/plugins available to users to configure, connect, monitor via ansible roles and scripts our machines.

Related github projects:

  • https://github.com/openSUSE/orthos2
  • https://github.com/ansible-collections/community.general/blob/main/plugins/inventory/cobbler.py
  • https://github.com/cobbler/cobbler

Alternative/Additionals:

I can help and point to where one could enhance our installations by:

  • Ubuntu/Centos/Windows/others
  • Fiddle out cobbler/orthos into separate services and try to package them into containers

Resources

This is about #installation #ansible #cobbler #orthos #django #python #fun

No Hackers yet

Join this project

Looking for hackers with the skills:

python3 django installation ansible

This project is part of:

Hack Week 22

Activity

  • almost 3 years ago: trenn added keyword "python3" to this project.
  • almost 3 years ago: trenn added keyword "django" to this project.
  • almost 3 years ago: trenn added keyword "installation" to this project.
  • almost 3 years ago: trenn added keyword "ansible" to this project.
  • almost 3 years ago: trenn originated this project.


    • Comments

    • pgarciaq
      almost 3 years ago by pgarciaq | Reply

      Are you aware of Beaker? That's the Red Hat equivalent to Orthos, and it's already Ansible-aware.

      https://beaker-project.org/ https://doc.distributed-ci.io/ansible-playbook-dci-beaker/

    Similar Projects

    openQA log viewer by mpagot

    Description

    *** Warning: Are You at Risk for VOMIT? ***

    Do you find yourself staring at a screen, your eyes glossing over as thousands of lines of text scroll by? Do you feel a wave of text-based nausea when someone asks you to "just check the logs"?

    You may be suffering from VOMIT (Verbose Output Mental Irritation Toxicity).

    This dangerous, work-induced ailment is triggered by exposure to an overwhelming quantity of log data, especially from parallel systems. The human brain, not designed to mentally process 12 simultaneous autoinst-log.txt files, enters a state of toxic shock. It rejects the "Verbose Output," making it impossible to find the one critical error line buried in a 50,000-line sea of "INFO: doing a thing."

    Before you're forced to rm -rf /var/log in a fit of desperation, we present the digital antacid.

    No panic: The openQA Log Visualizer (Also known as the "VOMIT-B-Gone 9000")

    This is your web-based hazmat suit for handling toxic log environments. It bravely dives into the chaotic, multi-machine mess of your openQA test runs, finds all the related, verbose logs, and force-feeds them into a parser.

    image

    Goals

    Work on the existing POC openqa-log-visualizer and change it to something usable

    Resources

    openqa-log-visualizer

    Improve/rework household chore tracker `chorazon` by gniebler

    Description

    I wrote a household chore tracker named chorazon, which is meant to be deployed as a web application in the household's local network.

    It features the ability to set up different (so far only weekly) schedules per task and per person, where tasks may span several days.

    There are "tokens", which can be collected by users. Tasks can (and usually will) have rewards configured where they yield a certain amount of tokens. The idea is that they can later be redeemed for (surprise) gifts, but this is not implemented yet. (So right now one needs to edit the DB manually to subtract tokens when they're redeemed.)

    Days are not rolled over automatically, to allow for task completion control.

    We used it in my household for several months, with mixed success. There are many limitations in the system that would warrant a revisit.

    It's written using the Pyramid Python framework with URL traversal, ZODB as the data store and Web Components for the frontend.

    Goals

    • Add admin screens for users, tasks and schedules
    • Add models, pages etc. to allow redeeming tokens for gifts/surprises
    • …?

    Resources

    tbd (Gitlab repo)

    Improve chore and screen time doc generator script `wochenplaner` by gniebler

    Description

    I wrote a little Python script to generate PDF docs, which can be used to track daily chore completion and screen time usage for several people, with one page per person/week.

    I named this script wochenplaner and have been using it for a few months now.

    It needs some improvements and adjustments in how the screen time should be tracked and how chores are displayed.

    Goals

    • Fix chore field separation lines
    • Change screen time tracking logic from "global" (week-long) to daily subtraction and weekly addition of remainders (more intuitive than current "weekly time budget method)
    • Add logic to fill in chore fields/lines, ideally with pictures, falling back to text.

    Resources

    tbd (Gitlab repo)

    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/