[augeas-devel] put to inittab is order-dependent

[Matthew Booth]

On 22/10/12 19:25, Dominic Cleal wrote:
> On 22/10/12 09:37, Matthew Booth wrote:
>> I just created a bug for $SUBJECT here:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=868822
>>
>> Has anyone seen this before? Looks weird.
>
> Yes, it's quite normal.  People often notice it with when they come to
> add new nodes that belong in the middle of a "record", but using aug_set
> causes the new node to appear at the end (e.g. setting an fstab option
> causes the node to appear after passno).  Use of aug_ins is needed to
> specify the node position.
>
> The order of nodes is set by the lens, which is governed by the file
> format and parsing of that format.  If an inittab entry could be
> represented (unambiguously) as process, then action, then runlevels,
> then you could also process that tree in the put direction.  Since it
> can't be read in that format, it can't be written that way either.
> Augeas can't reorder nodes in the tree to fit the lens, so the nodes
> have to be created that way.
>
> The error message, when you add some whitespace shows the format it
> expects the tree to be in, based on the lens:
>
> /augeas/files/etc/inittab/error/message =
>    "Failed to match
>      { /runlevels/ = /[^\\001-\\004\\n#:]*/ }
>      { /action/ = /[^\\001-\\004\\n#:]*/ }
>      { /process/ = /[^\\001-\\004\\n#]*/ }
>      { /#comment/ = <snipped> }?
>    with tree
>      { \"process\" = \"/sbin/mingetty tty\" }
>      { \"action\" = \"respawn\" }
>      { \"runlevels\" = \"2345\" }"

Thanks for the detailed explanation, Dominic.

Augeas's strictness is both its strength and its curse, and this is 
another example. The problem is that augeas's domain is right there in 
the name: shovelling sh*t. Sh*t isn't that strict ;) I *want* augeas to 
be more DWIM, which I feel is more appropriate for the domain. I wonder 
how far we can push it in that direction without completely giving up 
the power of its strictness.

Take this case. Rather than fail immediately a node can't be reconciled 
with the lens, we could re-order. How about this naïve algorithm 
matching lens nodes to tree nodes:

If tree node fits lens
   Consume both and continue
Else
   If tree node is last sibling
     If tree node is marked as retried
       FAIL
     Else
       Re-order node to be first sibling
       Mark node as retried
       Roll back state to processing of first sibling
       Retry
   Else
     Swap node with next sibling and retry

It's harder to reason about this behaviour, but it would eventually find 
an order that fits, trying the given order first.

Too untidy?

Matt
-- 
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team

GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490