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

... via rules) because classes will overwrite the values written by rules. ????

What do you mean with "overwritten" . Autoyast will 'merge' the xml files. Depending of the section you might need a "dontmerge" entry. Of course i hope that the XML file order is not important for autoyast in case Classes and rules are used BUT from my experience entries within EACH xml file MUST be in a correct order. Sort example: a.xml has <user> U1 </user> <group> G1 G2 </group> b.xml has <group> G3 <group> Since a.xml is not sorted and depending what you merge order is ( a.xml with b.xml or b.xml with a.xml ) the desired result c.xml <user> U1 </user> <group> G1 G2 G3 </group> Will not be given. So ITS VERY IMPORTANT that entries within a xml file are sorted. The reference has hints on how to to do a merge to check if the desired result is given. Hth Hajo Reference - (xsltproc) http://suse.gansert.net/?p=38 - http://www.suse.de/~ug/autoyast_doc/rulesandclass.html#merging To sort a xml file i use the following: ( Provided by the Oliver Becker - The Author of the merge.xslt ) xsltproc --output ./MyFile.sorted.xml ./sortxslt ./MyFile.unsorted.xml With sortxslt like: <?xml version="1.0" encoding="UTF-8"?> http://www.w3.org/1999/XSL/Transform" version="1.0"> xsl:copy -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-autoinstall+owner@opensuse.org

Oh i understand. I would not define a standard but would check what autoyast uses as standard. Meaning the classes have only what is really required / must be set. For your example: If managed=true would be the default used by autoyast then you would have no entry for it in your class file. Of course you can have a <networking> section. So the rule could change the settings for certain hosts but during the class merge nothing would be "overwritten" To say it with other words. A default value will not be defined within a class file. Another way in case you would like to define a default within your class file. In your class you have for example a default ( true) for your networking definition which will be overwritten by a pre script. Example: ( not tested) ... # Change managed networking from true to false cp -av /tmp/profile/autoinst.xml /tmp/profile/modified.xml sed -i "/<networking>/,/<\/networking>/{/managed/s/true/false/}" /tmp/profile/modified.xml ... Note "dont_merge" would not help here since i assume that you would end up with something like: ... <networking> <managed config:type="boolean">true</managed> <managed config:type="boolean">false</managed> </networking> ... Does that makes sense ? Cheers Hajo -----Original Message----- From: Joschi Brauchle [mailto:joschi.brauchle@tum.de] Sent: Thursday, September 27, 2012 4:22 PM To: Hans-Joachim Ehlers Cc: opensuse-autoinstall@opensuse.org Subject: Re: [opensuse-autoinstall] Whats the purpose of classes? OR: How to modularize the XML profile? Hello Hajo, yes I am aware that XML entries must be sorted for merging to work correctly. Also you are right that I should not have used the term "overwritten". Consider the following scenario: By default, one wants to control the network via ifup, but for some machines Network manager should be used. The corresponding switch is: <networking> <managed config:type="boolean">true</managed> </networking> So if I put "managed=true" (shorthand notation) in a specific rule for some hosts and "managed=false" in a class file (designed to be a default value) for all other hosts, I will always end up with "managed=false". The reason is that the class is merged after the rule, overruling any previous value of the "managed" tag. Hence, when combining rules and classes, classes will overrule all settings done by rules which are not protected by a "dont_merge". Is that correct? If so, I cannot use classes to define "default" values which shall be changed by rules... .... -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-autoinstall+owner@opensuse.org