Extremadura2007MeetingMinutes: Difference between revisions
(add link to presentation) |
(correct link to pdf) |
||
Line 3: | Line 3: | ||
= FAI presentation = | = FAI presentation = | ||
Heninng Sprang gave a presentation - it can be seen [[ | Heninng Sprang gave a presentation - it can be seen [[ Media:fai_presentation_extremadura2007.pdf | here ]] | ||
= Fai development meeting = | = Fai development meeting = |
Revision as of 16:30, 20 October 2007
Some notes about the extremadura development workshop:
FAI presentation
Heninng Sprang gave a presentation - it can be seen here
Fai development meeting
We had a little meeting about some FAI related stuff at the Extremadura work meeting in october 2007. Here are the minutes from this meeting:
Issues of setup harddisk(2)
There are currently problems to "preserve the right stuff" based on disk topologies. The problems relates to the inability of having the correct and same sorting of disks and device files for them. It is there in all newer kernels - which means since woody, probably. That means, it is no problem that is newly introduced by setup harddisk2. That doesn't mean, it should not be worked on, if possible, but it means setup harddisk is no regression regarding this if it cannot handle this correctly.
Possible things to do to solve it:
- set UUIDS at first install, and keep them somehow even through new installs, set disk configs to preserve by UUID
- Store serialnumbers of the disk in the disk config file, and preserve data based on this
- look into content of disks (e.g. .diskname) to preserve based on this (e.g. with the help of faimountdisk)
Apart from that, LVM with the new tool work fine - you can:
- keep some volumes by name
- Keep all volumes or none
Stockholm has some further requirements on setup harddisk:
- It should be possible to add physical volumes to existsing groups in lvm
Henning Sprang thinks, this is advanced, and more an update topic - "setup harddisk" is something else than "change logical volume config".
A proposal for next steps to do to work a structrued way to get setup harddisks well tested, with the goal of getting it into FAI soon (maybe as default disk config tool, or in parallel with the current one):
- create a list of goals of setup harddisk 2, and check if they are met - best put at Setup_harddisks_2
- create a list of existing serious bugs that prevent putting the tools into the next stable FAI version - also at Setup_harddisks_2
- make a list of advanced wishlist things (like stockholm change stuff for lvm) - for the next version, on another wiki page - e.g. SetupHarddiskWishlist
Unit tests for FAI
Someone mentions something like "it would be good to have unit tests for FAI, but it is not possible" because the test setup is so hard.
We discuss this a little bit. The point is, Unit tests are possible. You doin't check how FAI acts on a real disk (for example with setup harddisks), but you check that the script, for a given input (which is the text output from a tool reading the disk config, and the disks geometry), the command run is the right one. The point of unit test is exactly not testoing many components together, but single ones, if the do the right thing on the right input. When looking at the whole disk after modification by setup harddisk(AND it's calls to sfdisk, or whatever), you test setup harddsk AND sfdisk, not only one.
Some comments from Henning Sprang (not from the meeting but now, when writing these minutes): There are some thoughts about the use of shunit to do such things, there is also a unit test module for perl, and there is crucible, for system level, testing. I mailed that to the list some times. There also a wiki page, where further thoughts should be collected: Testing
Testing start with the definition
Thoughts about improving the quality on the FAI guide
Holger is not content with the state of the FAI guide (and quite some people agree directly, some when listening to his arguments). It is hard to update and it's not very well maintained, translations are very old.
Holger has a lot of ideas about a technical infrastructure, and a workflow how these things can be improved. It involves editing in MoinMoin Wiki, exporting to docbook(-XML?!), and from there creating various other formats. Such a system is successfull used in Skolelinux.
Henning Sprang is still a bit skeptical about quality control in a wiki, but might change his mind when reading a description of the workflow.(on the other hand, he also admits that the current system/format is not good, and this might be thevreasin for the guide being outdated and not optimally structured).
Holger should document his ideas in some full sentences, probably on the page: FaiGuideEditingAndTranslationInfrastructure.
Status of Debian Edu installs
- There is a howto on the debian wiki of how Edu systems are generated manually from a plain debian install, and a description of how a FAI install of some system types can be made - see
- http://wiki.debian.org/DebianEdu/HowTo/Debian2DebianEdu
- http://wiki.debian.org/DebianEdu/HowTo/FaiInstallDebianEdu
Henning Sprang will further test this if it works for him, too.
GUI
Further discussion for this has moved to some other time - Kugg has created some templates in HTML, details of those, and the required controls for editing stuff need to be details.