[netcf-devel] Suggestions (renaming drv_initscripts, changing the internal xml format, displaying augeas errors)

Jonas Eriksson jonas.j.eriksson at ericsson.com
Thu Jul 30 07:35:41 UTC 2009


On Wed, Jul 29, 2009 at 07:13:12PM +0200 David Lutterkort wrote:
> On Thu, 2009-07-23 at 15:06 +0200, Jonas Eriksson wrote:
> > I thought that I should sum up some suggestions I would like to
> > discuss and if possible implement or wake up one day and see them
> > implemented (which happened today :) ).
> 
> You're a lucky man ;)

:)

> > How about renaming the initscripts driver to redhat or something
> > similar? The SuSE driver will also target the initscript network
> > configuration layer, and hopefully more drivers in the future as
> > well.
> 
> Frankly, I assumed that SuSe's scripts were called something else[1]. I
> am completely open to renaming the initscripts driver; it's not going to
> be fun, but not a big issue either.

It never struck me that this is the package name on RH/Fedora,
actully. I assumed it referred to the fact that it in general
were handled through initscripts.

For the SuSE scripts, they are included in the package sysconfig,
but I do not think that it's a good name for the driver, as it
sounds very general. Something in the lines of suse_sysconfig
would perhaps fly, but as there are not competing suse-only
configuration alternatives that I know of, suse should suffice.

> > I suggest that we change the xml format that data/xml/augeas.rng
> > reflect, by changing the path attribute to an interface name
> > attribute. The reason for this is that the path is quite
> > irrelevant inside the XSLT, and only leads to duplication of data
> > (i.e. the ifcfg_path as it is called in drv_initscripts.c).
> 
> The reason the XML contains all the duplication is that I wanted a dirt
> simple format that can be turned into an Augeas tree in the most
> braindead manner possible. That makes the tests that do nothing more
> than XML transforms much more meaningful, since there's less danger of a
> bug outside the transforms.
> 
> In an ideal world, there would be a tool to directly transform the netcf
> XML into an Augeas tree; but there isn't, so I am using the augeas XML
> as a very simple standin.
> 
> IOW, I don't want to put more smarts into the augeas XML <-> augeas tree
> transform.

The problem I'm having when looking at it that way is that the
only smarts I get away from is writing (.. "%s/%s", path, label)
instead of (.. "%s/ifcfg-%s/%s", ifcfg_path, name, label). The
only way to avoid this is to use paths in the node-labels as
well, and I believe that neither of us want this. I should note
that in SuSE, the interface name is collected from the name of
the ifcfg-file, which is why ifcfg_path =
"/files/etc/sysconfig/network" instead of as in the
initscripts-driver's ifcfg_path =
"/files/etc/sysconfig/network-scripts/*".

Also, as it struck me recently, there is the problem of non-ifcfg
drivers (debians /etc/network/interfaces), which does not at all
correspond to augeas.rng. Perhaps augeas.rng should be named
ifcfg.rng? Or initscripts.rng/suse.rng?

My suggestion would be to name it ifcfg.rng, and adding something
in the lines of:
<choice>
  <attribute name="path"><ref name="path-pattern"/></attribute>
  <attribute name="name"><ref name="label-pattern"/></attribute>
</choice>
We would then only have to trust our respective XSLT.

> > When I was debugging a problem with aug_save, I noticed that it
> > was quite hard to get exact error messages from augeas. I of
> > added temporary debuging code that gave me this information,
> > although augeas information ought to be more easily accessible
> > than this. I therefore suggest adding the error state EAUGEAS (or
> > similar) that would trigger a dump of /augeas//error and
> > /augeas//error/message from the ERR_* macros. If this would be to
> > much information, it could be enabled through the planned debug
> > mode.

I actually implemented a variation of this as a test, with these
macros:
ERR_AUG_ERR_DETAILS(ncf, aug)
  If ncf->errcode == NETCF_EAUGEAS:
    Fetch (and clear) all augeas errors to ncf->errdetails
    (append if ncf->errdetails != NULL)

DBG_AUG_ERR_DETAILS(ncf, aug)
  Same as ERR_AUG_ERR_DETAILS, but only enabled when configured
  with --enable-debug-augeas

DBG_AUG_ERR_PRINT(aug)
  Print augeas error messages

> I would approach that slightly differently: we should just have another
> ERR_ macro that we use to check for Augeas errors. That macro can
> conditionally turn on aug_print(aug, stderr, "/augeas//error")

This is simple to implement, but I'm a bit sceptical towards a
lib that print things. The strict details-approach implemented
above would avoid this, but would not be perfect either. An
example of this would be the failure of get_augeas, the failure
of which is treated as a mere warning today.

> One of the things I want to add to Augeas is an error reporting
> mechanism that makes it easier for programs to figure out what went
> wrong. Once that's in place, we can hopefully produce nicer errors than
> EOTHER when something goes wrong inside Augeas.

A API call that returns this as a malloced string would be nice,
IMHO. In my currently implementation, I had to implement my own
aug_sprint to handle the errors that could happen when using
aug_get, for example.

/Jonas

--
Jonas Eriksson
Consultant at AS/EAB/FLJ/IL
Combitech AB
Älvsjö, Sweden


More information about the netcf-devel mailing list