[augeas-devel] Narcissus, a go reflection for Augeas

[David Lutterkort]

On Thu, Aug 11, 2016 at 7:09 AM, Raphaël Pinson <
raphael.pinson at camptocamp.com> wrote:

> Hello,
>
> Most of you know the Augeasproviders project, which features Ruby-based
> providers for Puppet using the Augeas library. At the heart of the
> Augeasproviders project, the augeasproviders_core library provides methods
> to map between the Augeas tree and the Puppet type parameters and
> properties.
>
> In the same kind of idea, I have started playing with a project using go
> reflection to map the Augeas tree to go structures.
>
> The project can be found on GitHub[0]. It is still very fresh (I started
> it this morning), but it features a few built-in structures for basic files:
>
>   * Hosts
>   * Passwd
>   * Services
>
> For now, only parsing (Augeas -> Struct) is supported, but I plan to add
> writing (Struct -> Augeas) to reflect the structure to the Augeas tree and
> save the tree.
>
> Feedback, issues & PRs are welcome!
>

I've been meaning to comment on this for a long time - I think this is
really awesome. And I am wondering if this could be turned into something
that Augeas supports natively, i.e., a way to retrieve and write parts of
the tree in a data structure that's more convenient than the actual tree.
Let's say, the data structure should roughly be whatever can be described
with JSON (i.e., hashes, arrays, and a handful of scalar types).

One of the things I always get hung up on when I think about this: how do
you describe writing such data and cover both the case of updating existing
data and adding new data ? For example, if you read a host record as

"host": {
  "canonical": "host.example.com",
  "ipaddr": "192.168.0.1",
  "alias": [ "a1", "a2" ]
}

and then change that and write back

"host": {
  "canonical": "host.example.com",
  "ipaddr": "10.0.0.1",
  "alias": [ "a1_new", "a2", "a3" ]
}

How do you describe the tree <-> data transformation so that the above
roughly leads to the sequence of commands

set ipaddr 10.0.0.1
set alias[1] a1_new
set alias[3] a3

For something as simple as the hosts file, that's probably doable; but how
would you handle something like ssh_config where you can't just blindly
append new entries ?

This would be incredibly powerful as it would give you a desired-state API
to manipulate config rather than the current imperative model that Augeas
follows. Are there any lessons from Augeasproviders that could help ?

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/augeas-devel/attachments/20161007/045da7a3/attachment.htm>