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 platform to apply formulas. 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
Help needed
- frontend developers (gtk? qt? commandline/non gui)
- backend developers (don't care what framework, web interface?)
- formula writers/qa/docs
- group to determine guidelines (FPC? :)
- security/signing/auditing folks.
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