From Fedora Project Wiki

Revision as of 22:14, 7 January 2013 by Kevin (talk | contribs) (add some more thoughts)

Warning.png
This page is a draft only
It is still under construction and content may change. Do not rely on the information on this page.
Important.png
NOTE
This is a draft/ideas container for discussion only, nothing here has been or will be set.

Introduction

Currently Fedora produces live media "spins" for specialised use. There's a "security lab", "design studio" and such for people interested in those areas. They can boot and/or install the live media and have all the tools that a curator in that field thinks would be good to have.

These spins also have some custom changes to the defaults where the curator of those feels it would work better for that group.

Producing, doing QA on, mirroring and other costs are very high for spins. To avoid those issues, I would like to propose:

Fedora Formulas. These would replace all spins except for desktop related ones. The desktop related spins are still needed as a base latform for you to apply formulas to. There could well be desktop formulas however to convert or setup one desktop as another one.

Formulas would be written as ansible playbooks with some metadata associated with them. Ansible has a very small footprint, and is very flexable on playbooks allowing for a widespread set of formulas.

Subject to change

  • Is the lab naming too anoying/cutesy?

Advantages / selling points

  • Better than groups of packages, because you can change config files, set things to start on boot, etc.
  • Allows for interactive querying the user for what they want

Terms

Formula: A ansible playbook that configures a machine(s) for a user.

Mad Scientist: Someone who creates/maintains Formulas

Reagents: base library of playbooks Formulas can reuse/improve

Questions / Discussion items

  • Should formulas be rpms? Or just text files in a git repo?
  • Bugzilla or trac or something else to report bugs/issues with them?
  • QA/Testing: Should there be a updates-testing type of setup? Some standard set of QA that MUST be passed?
  • Documentation: Should be with the playbook? Or seperate?
  • Require a way to 'undo' / 'uninstall' a formula? Or Is this too hard?
  • Dependencies / handle different package versions?
    • foo-1.0 vs foo-2.0 if both are in the repos? or require foo-2.0 for the recipe that needs it?
  • Some tracking/history: What was installed, when, by who, what version?
  • Guidelines:
    • Things formulas should never ever do. (and autoqa checks for them)?
    • Overlap between formulas. Who wins?
    • Can formulas require/depend on others?
    • Any particular language requirements? ansible doesn't care too much, but you need to install things needed to run that lang.
    • Should formulas be able to conflict with others?
    • Should be configuration info, NOT binaries or package data.
    • Should enhance / setup existing packages, never replace them.
    • Make sure no 3rd party stuff installed, all from fedora packages or simple text changes.
  • Way to sign/verify formulas to make sure they are official from Fedora and not tampered with. Signed commits? Signed rpms?
  • We need a frontend for users to interact with. Ideally both a gui and a tui.
    • Search formulas / rate them / give feedback.
    • Download and verify and run formula, with interactive question/answer.
    • Update existing formulas / re-run
    • Way to run optional parts of formulas.
    • Look at history/installed/run formulas.
  • Backend. Needs to talk to frontend, likely git repo and database?

Workflow

- Someone sees a need for a formula

- Write up / propose new formula (peer review? sponsorship?)

- Get reviewed/sponsored

- Pass QA tests

- Pass Docs

- Add to site.

- User searches for and sees new formula

- User uses frontend to download, verify and run

- User enjoys whatever curated functionality they were seeking without having to mess with anything but the formula.

- User provides feedback via frontend / bug reporting method

- Update happens, user sees update and looks at changes, downloads and re-runs

Examples

security lab

installs all packages listed optionally asks the user questions to lock down machine.

all desktops formula

installs all desktop groups asks user if they want gdm/lxdm/lightdm/kdm asks if they want tracker enabled/etc

openstack head controller

installs openstack head stuff configures database, queries user starts up things and sets them to start on boot optionally ssh'es to node and runs node formula on it

openstack compute node

setup node, asks for info about head controller and sets that up

forensics workstation

installs security packages queries user, then stops network entirely locks down everything and isolates machine.

packager

installs fedora-packager queries user to run fedora-packager-setup optionally gives user a tour of packager resources/screencast

xfce

installs xfce group sets up gui runlevel sets lightdm as dm queries user/sets default handlers for url/mail/etc disables some migrations/etc that don't need to run on new users. optionally gives a tour/screencast

pictureframe

installs image viewer/base wm sets up xguest user for autologin queries user for images and runs viewer as guest with them