Ok, so I actually figured out that what I wanted to do is not possible with classes. My idea was to have a modular XML file like this: /autoyast/ |--base_that_includes_common_stuff_via_classes.xml |--classes | |--common | | |--common_partitioning.xml | | |--common_whatever.xml | | `--... | `--amendments | |--file_selected_via_rules.xml | `--... `--rules `--rules.xml Unfortunately, classes are merged AFTER rules were merged. Hence I cannot use classes to define a default profile (which is then amended via rules) because classes will overwrite the values written by rules. I guess I have to stick to my current layout, which is /autoyast/ |--giant_base.xml |--conf1.xml |--conf2.xml | ... |--confN.xml `--rules `--rules.xml Or does anyone have a suggestion how I can create a modular default profile? Thanks! On 09/27/2012 10:13 AM, Joschi Brauchle wrote:
Hello Hajo,
thank you very much for your explanation.
It confirmed my belief that "classes" are nothing else than a method to merge external XMLs, as --------- <class>
common <configuration>partition.xml</configuration> </class> --------- simply fetches /<basedir>/classes/common/partition.xml to merge it. Really, the "class_name" tag is unnecessary, it just adds a subdir.Hence, I think that the term "class" as well as the docs saying "Classes represent configurations for groups of target systems" is misleading, because that is just *one specific* use case (amongst many others that do not really fit this description).
On 09/26/2012 06:29 PM, Hans-Joachim Ehlers wrote:
From the doc
... 6.2. Classes Classes represent configurations for groups of target systems. Unlike rules, classes have to be configured in the control file. Then classes can be assigned to target systems. ...
So if a class definition exist in the autoinst.xml it will be loaded and the merge process start again. This means the selection is NOT done via the rules.xml
So you could have a base autoinst.xml file which includes all common stuff like
Example: project1.xml
<classes config:type="list"> <class>
common <configuration>partition.xml</configuration> </class> <class>common <configuration>software.xml</configuration> </class> <class>common <configuration>nfsclient.xml</configuration> </class> <class>project1 <configuration>software.xml</configuration> </class> </classes>You could have a project2.xml with selects it unique settings from the class project2 but still using the common stuff. Of course in the rules.xml you must select which "project" will be used.
This is my understanding. I tried to use Xincludes but failed and i never used classes.
I use many small xml files which will be used to generated a autoinstall xml file before the node boots. Meaning i am using a configuration file which includes all required settings for a node and merge that stuff via a script to a final $(hostname).xml
Example:
The configuration: ... Default: Os = SLES11SP1 kernel = 32 Xml = Lvm.xml , Software.xml , Nfsclient.xml , post_script.xml
MyNode1: Template = Default Xml = SpecialSoftware.xml Kernel = 64
MyNode2: Template = Default
...
Will lead to a MyNode1.xml which is build of ALL xml named in Default: & MyNode1: but kernel type is 64bit. My rules.xml has has 2 entries: One to fetch the $(hostname).xml and another to include a generic script.xml.
Hm, basically this logic could be implemented with classes right away and i would have no need to do a merge beforehand which can cause problems.
Cheers Hajo