5 ms·

It provides a consistent interface for changing all kinds of configuration files, making Ansible-style automation easier and more robust. "Changing" goes beyon

It provides a consistent interface for changing all kinds of configuration files, making Ansible-style automation easier and more robust. "Changing" goes beyond "parsing and generating"; e.g. ordering, comments and formatting are retained. The alternative would be search-and-replace style edits (not robust), custom implementations for every format (hard work to get right, especially without Augeas' infrastructure in place), or being limited to templating entire files. The list of supported file formats is quite extensive: http://augeas.net/stock_lenses.html http://augeas.net/stock_lenses.html (note on naming: lens is a well-known theoretical concept) It's sad that Augeas is necessary though -- in an ideal world, developers wouldn't come up with custom ad-hoc file formats or abuse 'sh' and /etc would be empty by default.

PaulHoule 10y ago
Yeah, one of the problems in the computer industry now is that people are generating config (and other) files with template systems that don't understand anything about the underlying syntax. If you can turn the files into parse trees, manipulate them semantically, and then turn them back into files, that rocks. For instance, right now I am working with a database that has to have a lot of things configured -- one of them is how big the buffers should be, which is a function of how much RAM you have, which in turn depends on the kind of AWS instance my product runs on. With a smart configuration API I could take a configuration file supplied by the user and set the buffers to the right size really easily.
- dozzie 10y ago
  > [...] I am working with a database that has to have a lot of things configured -- one of them is how big the buffers should be, which is a function of how much RAM you have, which in turn depends on the kind of AWS instance my product runs on. Which has nothing to do with the configuration format itself, it only needs some knowledge when building config files. It can be achieved as easily with a simple template (that doesn't understand the config it produces!), only supplied with information local to the system the config is going to work under. The easiest way is to build the config from a template on the system it's going to run, but masterful Puppet with its facts database can do it on the side of commanding server as well.
  - PaulHoule 10y ago
    If the template system doesn't understand the semantics of the configuration file, templates just work because you are lucky. In the case of blending configuration changes with a user-supplied file, the user can supply a configuration file instead of a template. If the system does understand the configuration file, then you can get the full value out of having a "fact database" that describes the system.
    - dozzie 10y ago
      > If the template system doesn't understand the semantics of the configuration file, templates just work because you are lucky. Or because I put appropriate constraints on data filling the template. Integer fields are the easiest format to handle. Generating configs with template systems is surprisingly strudy in real world scenarios, where at least half-competent programmer provides templates for at least half-competent sysadmin to fill. > If the system does understand the configuration file, then you can get the full value out of having a "fact database" that describes the system. The problem is that this "full value" is not that much bigger, but the effort in understanding config file formats is quite large.
      - PaulHoule 10y ago
        The work is large because parser generators are designed for systems programmers and not for application programmers. They haven't advanced much in terms of usability, thus parsing seems like a much harder problem than it really is.
dozzie 10y ago
> The alternative [to Augeas] would be search-and-replace style edits (not robust), custom implementations for every format (hard work to get right, especially without Augeas' infrastructure in place), or being limited to templating entire files. Precisely. CFEngine (3.x, but also venerable 2.x) does it the former way, but there are templating engines (Template::Toolkit for Perl, on which I have built my cfgen, and, less convenient to control, Jinja2 for Python, which is the base for my current work with configs) that make it easy to do the latter way. CFEngine 3.x adopted also templating at some point, I believe (I remember second-hand communication with CFE engineers that said our (my) templating gave them some ideas, but it was long ago and may be invalid anyway), but since I haven't used CFE 3.x, I can't tell much. Apart from Augeas, I haven't seen the idea of working with configs that had such a solid foundation. It's such a shame the gains from having a semantically-valid configuration editing are so small against the cost of developing and understanding the grammar of config syntax compared to generating the said config from a template (at least that's what I think, that the gains are so small). I certainly would love to use Augeas-like tool in my daily work.
deleted 10y ago
[deleted]

PaulHoule 10y ago

Yeah, one of the problems in the computer industry now is that people are generating config (and other) files with template systems that don't understand anything about the underlying syntax. If you can turn the files into parse trees, manipulate them semantically, and then turn them back into files, that rocks. For instance, right now I am working with a database that has to have a lot of things configured -- one of them is how big the buffers should be, which is a function of how much RAM you have, which in turn depends on the kind of AWS instance my product runs on. With a smart configuration API I could take a configuration file supplied by the user and set the buffers to the right size really easily.

dozzie 10y ago
> [...] I am working with a database that has to have a lot of things configured -- one of them is how big the buffers should be, which is a function of how much RAM you have, which in turn depends on the kind of AWS instance my product runs on. Which has nothing to do with the configuration format itself, it only needs some knowledge when building config files. It can be achieved as easily with a simple template (that doesn't understand the config it produces!), only supplied with information local to the system the config is going to work under. The easiest way is to build the config from a template on the system it's going to run, but masterful Puppet with its facts database can do it on the side of commanding server as well.
- PaulHoule 10y ago
  If the template system doesn't understand the semantics of the configuration file, templates just work because you are lucky. In the case of blending configuration changes with a user-supplied file, the user can supply a configuration file instead of a template. If the system does understand the configuration file, then you can get the full value out of having a "fact database" that describes the system.
  - dozzie 10y ago
    > If the template system doesn't understand the semantics of the configuration file, templates just work because you are lucky. Or because I put appropriate constraints on data filling the template. Integer fields are the easiest format to handle. Generating configs with template systems is surprisingly strudy in real world scenarios, where at least half-competent programmer provides templates for at least half-competent sysadmin to fill. > If the system does understand the configuration file, then you can get the full value out of having a "fact database" that describes the system. The problem is that this "full value" is not that much bigger, but the effort in understanding config file formats is quite large.
    - PaulHoule 10y ago
      The work is large because parser generators are designed for systems programmers and not for application programmers. They haven't advanced much in terms of usability, thus parsing seems like a much harder problem than it really is.

dozzie 10y ago

> The alternative [to Augeas] would be search-and-replace style edits (not robust), custom implementations for every format (hard work to get right, especially without Augeas' infrastructure in place), or being limited to templating entire files. Precisely. CFEngine (3.x, but also venerable 2.x) does it the former way, but there are templating engines (Template::Toolkit for Perl, on which I have built my cfgen, and, less convenient to control, Jinja2 for Python, which is the base for my current work with configs) that make it easy to do the latter way. CFEngine 3.x adopted also templating at some point, I believe (I remember second-hand communication with CFE engineers that said our (my) templating gave them some ideas, but it was long ago and may be invalid anyway), but since I haven't used CFE 3.x, I can't tell much. Apart from Augeas, I haven't seen the idea of working with configs that had such a solid foundation. It's such a shame the gains from having a semantically-valid configuration editing are so small against the cost of developing and understanding the grammar of config syntax compared to generating the said config from a template (at least that's what I think, that the gains are so small). I certainly would love to use Augeas-like tool in my daily work.

deleted 10y ago

[deleted]