Debugging autoyast

[686f6c6d]

During my 12.1 bughunt, I (re-)encountered some inconsistencies that
I've been wanting to ask (and nag) about since I started working with
autoyast a few years back, and a few new ones:

1. autoyast generates a lot of messages.
For an autoyast dev, this might be wonderful, but dumb users like
myself are simply lost in tens of thousands of messages. It makes
finding errors in the logs really hard, especially when you don't know
what string(s) you're looking for.
It would be great if there was, for example, an additional
warnings-and-errors-only log.


2. autoyast generates a lot of "noise" in diffs.
When cloning a system with yast or editing it manually and then
running it through yast again to check for errors, yast changes the
profile in various ways. This makes it sometimes harder to see the
"real" differences. (In general, one could say everything is fine
because the inconsistencies below all "converge" towards a final
state, but nevertheless I sometimes wonder why these things happen.)


2.a) (this is new in 12.1 and did not happen before:) for some reason
the DNS settings are not kept for stage 2, so I need this script in
12.1:
<script>
<debug config:type="boolean">true</debug>
<feedback config:type="boolean">false</feedback>
<filename>fixresolv</filename>
<interpreter>shell</interpreter>
<network_needed config:type="boolean">true</network_needed>
<source><![CDATA[resolv=$(cat /etc/resolv.conf)
if [ -z "$resolv" ]; then
echo "# resolv.conf was empty, ftfy.
nameserver a.b.c.d" >> /etc/resolv.conf
fi
]]></source>
</script>


2.b) <keep_install_network> is _always_ deleted by yast.


2.c) even though a <runlevel> section exists, the package
yast2-runlevel is not automatically installed.


2.d) even though mail settings (aliases, mailrelay) exist, the package
yast2-mail is not automatically installed.


2.e) When *cloning* an existing system, I see inconsistent and
sometimes non-helpful behavior. What happens is that for certain
settings (see below), there are different cases that can happen:
1. tag doesn't exist vs.
2. tag exists but is empty vs.
3. tag exists with default/cloned value
Of these three, only the last one is really helpful because I can
actually see what value the cloned machine had set. Some of the
settings where I have seen this in 12.1 are:
<languages>, <filesystem_id>, <partition_id>,
<displaymanager_shutdown>,
<displaymanager_xserver_tcp_port_6000_open>, <run_updatedb_as>,
<hibernate_system>, <smtpd_listen_remote>, <dhclient_client_id>,
<nss_base_{passwd,group,shadow}>.
I have only had my eye really close on the <password_settings>
section, the behavior was like this:
* random existence of default value or empty tag (this happened
for both the complete section or parts of it, depending on which parts
of it were set to the default on the cloned machine)
* if it did exist with empty values, yast (sometimes) deletes
(some of!) those tags
* if it did not exist, yast (sometimes) inserts (some of!) those
tags with the default (non-empty) values (but *only* if the whole
<password_settings> did not exist. if only parts are missing, these
are not inserted)
In the two former cases (no tag/empty tag), the user has to remove
them from the profile, run it through yast again, and only then will
the values appear (or it will not be added again by yast and wasn't so
important anyway).


2.f) While the sections in the profile seem to be sorted alphabetically by yast,
1. the order of <users> seems to be random,
2. the order of the <*packages> and <*patterns> sections seems to
be nonrandom, but isn't nonalphabetic either.
Does the order of these sections matter? If not, could the please be
sorted deterministically (alphabetically, or, f.e., in order of UIDs
for the users)? Right now, when comparing different profiles, the user
has to do a lot of "merging" first before he/she can see the real
differences.


It would be really great if the debugging possibilites in autoyast
would be improved. They've been a source of frustration to me over the
last weeks.

That all sounds so negative. Let me end with a big thank you to all
contributors: Thank you. autoyast saves me a lot of time. (:

[Hans-Joachim Ehlers]

Post by 686f6c6d
2.f) While the sections in the profile seem to be sorted alphabetically by yast,

The original author of the merge.xml has written for us some xslt files.

Sort XML file
$ xsltproc --output node.xml.sorted sort.xslt node.xml

Make XML file more human readable
$ xsltproc --output node.xml.pretty pretty.xslt node.xml


We needed these xslt file to be able todo a merge independent from autoyast.

Note:
Maybe the CDATA section gets lost ....

$ cat sort.xslt

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">

<xsl:param name="order" />

<xsl:output indent="yes" />

<xsl:template match="/*">
<xsl:copy>
<xsl:copy-of select="@*" />
<xsl:for-each select="*">
<xsl:sort select="string-length(substring-before($order, name()))" />
<xsl:sort select="name()" />
<xsl:copy-of select="." />
</xsl:for-each>
</xsl:copy>
</xsl:template>

</xsl:stylesheet>

$ cat pretty.xslt
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">

<xsl:strip-space elements="*" />
<xsl:output indent="yes" />

<xsl:template match="node()">
<xsl:copy>
<xsl:copy-of select="@*" />
<xsl:apply-templates />
</xsl:copy>
</xsl:template>

</xsl:stylesheet>

Hth
Hajo

��{.n�+�����������j�h�{-jY~�{.n�+�������Ǩ�

[Uwe Gansert]

Post by 686f6c6d
1. autoyast generates a lot of messages.
For an autoyast dev, this might be wonderful, but dumb users like
myself are simply lost in tens of thousands of messages. It makes
finding errors in the logs really hard, especially when you don't know
what string(s) you're looking for.
It would be great if there was, for example, an additional
warnings-and-errors-only log.

I know what you mean but it's not autoyast that is so verbose, it's yast
as whole. If you do a manual installation or an autoinstallation makes
no big difference. Especially libstorage and the package resolver are
way too verbose.
I can not change that easily.

The loglines start like this:
2012-04-18 14:18:56 <3>
2012-04-18 14:18:56 <2>
2012-04-18 14:18:56 <1>
the 3 means it was logged by y2error
a 2 means it's a warning
a 1 means, it's just a y2milestone (like a 'I was here' message for
devlopers).

but I know, reading a y2log file requires some experience

Post by 686f6c6d
2. autoyast generates a lot of "noise" in diffs.
When cloning a system with yast or editing it manually and then
running it through yast again to check for errors, yast changes the
profile in various ways. This makes it sometimes harder to see the
"real" differences. (In general, one could say everything is fine
because the inconsistencies below all "converge" towards a final
state, but nevertheless I sometimes wonder why these things happen.)

autoyast transforms the XML file into ycp data structures and feeds
those to the yast modules. The yast modules works with those and returns
data structures back to autoyast where they are transformed into XML again.
There is no information about any order that was in the XML file.
The yast module often also returns the default values - even if they did
not exist in the XML file before. That's important if defaults change.
If a key gets lost, it's either not supported anymore or you found a bug.

Post by 686f6c6d
2.a) (this is new in 12.1 and did not happen before:) for some reason
the DNS settings are not kept for stage 2, so I need this script in

please open a bug for that

Post by 686f6c6d
2.b)<keep_install_network> is _always_ deleted by yast.

you mean the UI always drops that value?
That's a bug then. Bugzilla please.

Post by 686f6c6d
2.c) even though a<runlevel> section exists, the package
yast2-runlevel is not automatically installed.

that's with every module.
Every yast module tells autoyast "In your XML File, I am <bla_bla>"
So autoyast knows whom to feed with the data from the XML file.
The good thing with that is, AutoYaST itself does not have to know all
yast modules that have autoyast support. You can create an autoyast
module without changing anything in autoyast for it.
The bad thing about that is, that autoyast can not know what to do with
unknown sections.
If there is a <runlevel> section but no yast2-runlevel module installed,
then autoyast does not know what to do with that section - it ignores it
then. Maybe an error popup would be nice in that case.
Autoyast reads that information from the desktop files in
/usr/share/applications/YaST2/

Post by 686f6c6d
2.d) even though mail settings (aliases, mailrelay) exist, the package
yast2-mail is not automatically installed.

same as above
AutoYaST itself knows nothing about mail or which module is required to
deal with those keys.
When you install yast2-mail, then autoyast knows what to do with those
keys because the desktop file is there

Post by 686f6c6d
2.e) When *cloning* an existing system, I see inconsistent and
sometimes non-helpful behavior. What happens is that for certain
1. tag doesn't exist vs.

that's not so nice

Post by 686f6c6d
2. tag exists but is empty vs.

then the default is an empty string or the system has an empty string
configured for that key

Post by 686f6c6d
<languages>,<filesystem_id>,<partition_id>,

languages is probably really empty on the system
If you don't have secondary languages installed it's empty. That's okay.
filesystem_id I should remove
partition_id should never be empty - that would be a bug

Post by 686f6c6d
<displaymanager_shutdown>,
<displaymanager_xserver_tcp_port_6000_open>,<run_updatedb_as>,
<hibernate_system>,<smtpd_listen_remote>,<dhclient_client_id>,
<nss_base_{passwd,group,shadow}>.

okay, those I don't know. They come from different yast modules and
different developers. I'd have to check one by one and get in contact
with the developer (three different developers in this case)

Post by 686f6c6d
I have only had my eye really close on the<password_settings>

if you think you find inconsistency, then please open a bug report.
I'll take a look and fix it or assign it to the right developer

Post by 686f6c6d
2.f) While the sections in the profile seem to be sorted alphabetically by yast,
1. the order of<users> seems to be random,

they are probably stored in a hash in yast internally. So the order is
the order the ycp-interpreter has sorted the keys in the hash-map
That does not help you but explains why the order is random for the
naked eye :)

Post by 686f6c6d
2. the order of the<*packages> and<*patterns> sections seems to
be nonrandom, but isn't nonalphabetic either.

same as 1 maybe. I'd have to take a closer look

Post by 686f6c6d
Does the order of these sections matter?

no, for users and patterns the order does not matter. But autoyast does
not know that, so it can not sort stuff like that by itself (well, for
patterns that's not true, that really in the autoyast core) but users
must be sorted by yast2-users

Post by 686f6c6d
If not, could the please be
sorted deterministically (alphabetically, or, f.e., in order of UIDs
for the users)?

that could be changed for sure in the yast2-users module
packages and patterns are handled in the autoyast core which is code
that I maintain by myself.

Post by 686f6c6d
That all sounds so negative. Let me end with a big thank you to all

never mind. Feedback is always appreciated - I don't take anything
personal :)
I know how frustrating it can be to debug something for days
--
ciao, Uwe Gansert

SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg)
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer
Home: http://www.suse.de/~ug - Blog: http://suse.gansert.net
listening to: "Traum vom Tod II" by Subway to Sally

[686f6c6d]

On Thu, Apr 19, 2012 at 17:42, Hans-Joachim Ehlers

Post by 686f6c6d
2.f) While the sections in the profile seem to be sorted alphabetically by yast,

The original author of the merge.xml has written for us some xslt files. [...]
We needed these xslt file to be able todo a merge independent from autoyast.

I'm not too skilled in XSLT; this basically does the same kind of
merging autoyast does, right?

Post by 686f6c6d
1. autoyast generates a lot of messages.
For an autoyast dev, this might be wonderful, but dumb users like
myself are simply lost in tens of thousands of messages. It makes
finding errors in the logs really hard, especially when you don't know
what string(s) you're looking for.
It would be great if there was, for example, an additional
warnings-and-errors-only log.

I know what you mean but it's not autoyast that is so verbose, it's yast as
2012-04-18 14:18:56 <3>
2012-04-18 14:18:56 <2>
2012-04-18 14:18:56 <1>
the 3 means it was logged by y2error
a 2 means it's a warning
a 1 means, it's just a y2milestone (like a 'I was here' message for
devlopers).
but I know, reading a y2log file requires some experience

Wow, thanks, that is really useful information! I have noticed these
numbers before but could never make heads or tails of them. I assumed
they were some kind of "yast hierarchy depth" indicator. *leaves to
grep "<[23]>" from recent y2log's*
*returns grinning*: 199 (<2>) + 91 (<3>) lines are much better to work

Post by 686f6c6d
2. autoyast generates a lot of "noise" in diffs.
When cloning a system with yast or editing it manually and then
running it through yast again to check for errors, yast changes the
profile in various ways. This makes it sometimes harder to see the
"real" differences. (In general, one could say everything is fine
because the inconsistencies below all "converge" towards a final
state, but nevertheless I sometimes wonder why these things happen.)

autoyast transforms the XML file into ycp data structures and feeds those to
the yast modules. The yast modules works with those and returns data
structures back to autoyast where they are transformed into XML again.
There is no information about any order that was in the XML file.

Ah, too bad. So to change this behaviour, the respective yast modules
would need to be changed, right?

The yast module often also returns the default values - even if they did not
exist in the XML file before. That's important if defaults change.
If a key gets lost, it's either not supported anymore or you found a bug.

Ok, I will keep that in mind, investigate further and file bugs
accordingly as you suggest below.

Post by 686f6c6d
2.a) (this is new in 12.1 and did not happen before:) for some reason
the DNS settings are not kept for stage 2, so I need this script in

please open a bug for that

https://bugzilla.novell.com/show_bug.cgi?id=758539

Post by 686f6c6d
2.b)<keep_install_network>  is _always_ deleted by yast.

you mean the UI always drops that value?
That's a bug then. Bugzilla please.

https://bugzilla.novell.com/show_bug.cgi?id=758529

Post by 686f6c6d
2.c) even though a<runlevel>  section exists, the package
yast2-runlevel is not automatically installed. [2.d) same for yast2-mail]

that's with every module.
Every yast module tells autoyast "In your XML File, I am <bla_bla>"
So autoyast knows whom to feed with the data from the XML file.
[...]
AutoYaST itself knows nothing about mail or which module is required to deal
with those keys.
When you install yast2-mail, then autoyast knows what to do with those keys
because the desktop file is there

(Without any knowledge of *yast code:) If that is the case, couldn't
autoyast dynamically create a list of section-to-module entries and
add these modules?
Ah: Reading your comments below, I think I see the problem: This data
is in "/usr/share/applications/YaST2/". The module has to be installed
already for those files to exist and for autoyast to know anything
about the sections.
But on the "profile server" side, when creating a profile with YaST,
this is also true, correct? So if I assume I can only add those
sections whose modules are already installed on the server, couldn't
YaST then add those modules involved to the <packages> section? Or are
they pumping their sections into YaST "anonymously"?

The good thing with that is, AutoYaST itself does not have to know all yast
modules that have autoyast support. You can create an autoyast module
without changing anything in autoyast for it.
The bad thing about that is, that autoyast can not know what to do with
unknown sections.
If there is a <runlevel> section but no yast2-runlevel module installed,
then autoyast does not know what to do with that section - it ignores it
then. Maybe an error popup would be nice in that case.

Yes please, that would be very helpful indeed (doesn't have to be an
error though, I would be fine with a warning, too). We have a lot
<remove-packages> because we don't agree with openSUSEs default
desktop'ish package selection, and so we often run into transitive
depencency problems where "Recommends:" (that's just an uninformed
guess) like yast* are not pulled in.

Autoyast reads that information from the desktop files in
/usr/share/applications/YaST2/

Looking into those files I don't quite understand how it works. (But
don't be bothered by that. I'm not sure if I *want* to know. ^^)


(Let me get back to you on 2.e etc. later this month.)

Post by 686f6c6d
    2. the order of the<*packages>  and<*patterns>  sections seems to
be nonrandom, but isn't nonalphabetic either.

same as 1 maybe. I'd have to take a closer look
[...]

Post by 686f6c6d
Does the order of these sections matter?

no, for users and patterns the order does not matter. But autoyast does not
know that, so it can not sort stuff like that by itself (well, for patterns
that's not true, that really in the autoyast core) but users must be sorted
by yast2-users

Post by 686f6c6d
If not, could the please be
sorted deterministically (alphabetically, or, f.e., in order of UIDs
for the users)?

that could be changed for sure in the yast2-users module
packages and patterns are handled in the autoyast core which is code that I
maintain by myself.

That's surely a matter of preference, but I think an alphabetic order
is much better suited to human debugging. (But it isn't too much of a
hassle. Right now I only have to do a ":<,>sort" on these sections in
vim).

Post by 686f6c6d
That all sounds so negative. Let me end with a big thank you to all

never mind. Feedback is always appreciated - I don't take anything personal
:)
I know how frustrating it can be to debug something for days

Thank you so much... Did I mention that I hate Asparagus? Incidently,
12.1 is appropriately named. <;