FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora/Linux Management Tools

 
 
LinkBack Thread Tools
 
Old 04-20-2008, 11:26 PM
Mike MacCana
 
Default ANNOUNCE: Augeas - a configuration API

On Fri, 2008-04-18 at 15:01 +0100, Daniel P. Berrange wrote:


On Fri, Apr 18, 2008 at 01:39:06PM +1000, Mike MacCana wrote:
> On Thu, 2008-04-17 at 21:17 -0600, Stephen John Smoogen wrote:
>
> > On Thu, Apr 17, 2008 at 8:02 PM, Mike MacCana <mmaccana@au1.ibm.com> wrote:
> > >
> > > On Thu, 2008-04-17 at 13:07 -0700, David Lutterkort wrote:
> > > I am pleased to announce a new configuration management project: Augeas,
> > > a low-level configuration API and editing tool.
> > >
> > > Augeas' main goal is to make programmatic changes of configuration data
> > > on Linux/Unix systems simple and safe. The main stumbling stone for this
> > > is that configuration data is stored in numerous files in widely varying
> > > formats. This is both next to impossible to change and is valuable in
> > > many situations.
> > >
> > > ???The amount of effort spent creating and re-creating tools to parse, edit
> > > and transform a variety of unnecessary, unstructured data formats over the
> > > last 30 years, and to continue doing this for the next 10 years, is less
> > > than that required to:
> > >
>
> (create a standard format, proactively patch apps to support a standard
> format, make an editor for that format, and start shipping packages)

Back in the real world people also want to be able to manage existing deployed
production applications today. Even if you convince upstream to adopt your
grand unified configuration scheme


I'm not proposing to get upstream acceptance of anything. You can't fix these things without pissing a few people off - luckily, upstream doesn't ship operating systems - distributions do.



Not saying tools like cfengine, puppet, augeas aren't useful solutions, but let's recognise them for what they are - bandaid solutions.






Cheers,



Mike



________________________________________________

Mike MacCana

Technical Specialist

Linux Services



IBM Global Services

Level 14, 60 City Rd

Southgate Vic 3000



Phone: +61-3-8656-2138

Fax: +61-4-8656-2423

Email: mmaccana@au1.ibm.com





_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
 
Old 04-20-2008, 11:42 PM
Mike MacCana
 
Default ANNOUNCE: Augeas - a configuration API

On Fri, 2008-04-18 at 17:17 +0000, David Lutterkort wrote:
> On Fri, 2008-04-18 at 12:02 +1000, Mike MacCana wrote:
> > * create an editor for that format (which handles data - settings,
> > values, parents and children, rather than presentation related info
> > like lines and paragraph)
>
> At its heart, Augeas is a tool to make writing such editors easy, easier
> than starting from scratch for every format. Of course, there's also
> benefit for users if they can edit many config files with the same tool
> instead of having a separate tool for each config file.

Excellent.

Is there a possibility that Augeas could encourage, or actively patch,
applications to read their configuration directly from Augeas format
files?

Some of the responses to me original comment agreed that a standardized
config file format was incredibly useful, but hard to achieve.

Distros have some real power here, and Red Hat has used this power for
good in the past:

* Red Hat patched KDE to support a bunch of freedesktop.org
specifications (for example, notification area support) back in the day,
and while a few people got their nose out of joint, the changes were
ultimately accepted into upstream KDE. Red Hat just pushed for the
standard first.

* Ditto ISO C - some apps had to be changed for Red Hat's more standards
compliant GCC 2.96, but all those apps - including the Linux kernel and
mplayer - required patching to be compilable on GCC 3 anyway, and after
some grumbling, the third party apps were fixed. Red Hat just pushed
for the standard first.

A distribution has never encouraged apps to standardize on a config file
format. There's a real opportunity here.

Mike

>
> > Using 'widely varying formats' is not 'valuable'.
>
> I was a little oblique .. I meant 'that config data is stored in text
> files is valuable', mostly to contrast that with some other approaches
> that have been proposed in the past.
OK, and agreed.

> > It's an unfortunate accident that wastes everyone's time with various
> > horrible bandaid solutions
>
> I think we're all in agreement that the situation is far from the best
> imaginable. That's why I chose "Augeas"[1] as the name for this


>
> David
>
> [1] http://en.wikipedia.org/wiki/Augeas
>
> "In Greek mythology, Augeas ... was King of Elis ... He is best known for his
> stables, which housed the single greatest number of cattle in the country and
> had never been cleaned"
>
> _______________________________________________
> et-mgmt-tools mailing list
> et-mgmt-tools@redhat.com
> https://www.redhat.com/mailman/listinfo/et-mgmt-tools

Cheers,

Mike

________________________________________________
Mike MacCana
Technical Specialist
Linux Services

IBM Global Services
Level 14, 60 City Rd
Southgate Vic 3000

Phone: +61-3-8656-2138
Fax: +61-4-8656-2423
Email: mmaccana@au1.ibm.com

_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
 
Old 04-20-2008, 11:46 PM
Mike MacCana
 
Default ANNOUNCE: Augeas - a configuration API

On Fri, 2008-04-18 at 17:22 +0000, David Lutterkort wrote:


On Fri, 2008-04-18 at 15:01 +0100, Daniel P. Berrange wrote:
> Even if you convince upstream to adopt your grand unified configuration scheme

And therein lies the rub. I've been very careful to make sure that
Augeas' usability does not depend on any upstream adopting it - they
have perfectly valid reasons not to do that, starting with that they
can't tell which proposed scheme will actually work out (and therefore
deserve their support)

Augeas (or any similar config scheme) _has_ to be workable without
upstream support - it would be great if we get some eventually [1], but
we first need to prove that Augeas is worth their effort.

David

[1] And for now, it would really only require them shipping a schema
with their software, i.e. plonking one text file
into /usr/share/augeas/lenses




Cool. It would be really useful to see some doco online about how an upstream could support the forma - and see some sample schemas for, say, Samba / BIND / Apache HTTPD.







Cheers,



Mike



________________________________________________

Mike MacCana

Technical Specialist

Linux Services



IBM Global Services

Level 14, 60 City Rd

Southgate Vic 3000



Phone: +61-3-8656-2138

Fax: +61-4-8656-2423

Email: mmaccana@au1.ibm.com





_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
 
Old 04-20-2008, 11:51 PM
Mike MacCana
 
Default ANNOUNCE: Augeas - a configuration API

On Sun, 2008-04-20 at 10:04 +0100, Richard W.M. Jones wrote:


On Fri, Apr 18, 2008 at 12:02:15PM +1000, Mike MacCana wrote:
> Using 'widely varying formats' is not 'valuable'. It's an unfortunate
> accident that wastes everyone's time with various horrible bandaid
> solutions, and occasionally makes destroying user data an 'accepted
> limitation' of tools like system-config-named.

Different formats suit different uses, and in any case I wouldn't
trust the people who would develop this new "super-format" not to do
something stupid like using XML.

Rich.



Admins don't like XML because vi isn't an XML editor. It's the equivalent of Microsoft Word, treating presentation and content like they're the same thing.



Config files aren't logically combinations of characters, lines, and paragraphs, They're item / value pairs, sections, and subsections.



This is why I mentioned creating an editor earlier. There's no reason why you need to see XML when you edit it. shouldn't be able to say 'jump to next subsection, copy this object, paste it three times' in the same way we do with lines and paragraphs in vi.



I'd call it vix.






Cheers,



Mike



________________________________________________

Mike MacCana

Technical Specialist

Linux Services



IBM Global Services

Level 14, 60 City Rd

Southgate Vic 3000



Phone: +61-3-8656-2138

Fax: +61-4-8656-2423

Email: mmaccana@au1.ibm.com





_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
 
Old 04-21-2008, 12:30 AM
David Lutterkort
 
Default ANNOUNCE: Augeas - a configuration API

On Mon, 2008-04-21 at 09:42 +1000, Mike MacCana wrote:
> Is there a possibility that Augeas could encourage, or actively patch,
> applications to read their configuration directly from Augeas format
> files?

As I said before, there's little point in making apps use the same
mechanism to just read a config file as the one used by a config editor
to read and write it.

> A distribution has never encouraged apps to standardize on a config file
> format. There's a real opportunity here.

The road is littered with config projects that got run over by their own
ambition. In sys mgmt, premature modeling is the root of all evil.

For Augeas, my ambition is to make it a tool that is useful for
modifying configuration data as it exists today, and be applicable in as
many situations as possible. Once we get it there, we can think about
grander things; until then, being able to use Augeas with unmodified
applications is imperative.

David


_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
 
Old 04-21-2008, 12:33 AM
David Lutterkort
 
Default ANNOUNCE: Augeas - a configuration API

On Mon, 2008-04-21 at 09:46 +1000, Mike MacCana wrote:
> Cool. It would be really useful to see some doco online about how an
> upstream could support the forma

There's really no need for upstream support; if anybody wants that, all
they need to do is ship an appropriate schema description
in /usr/share/augeas/lenses[1]

> - and see some sample schemas for, say, Samba / BIND / Apache HTTPD.

Writing these is dearly needed. Barring that, feedback on the existing
docs[2] would also be much appreciated.

David

[1] like the ones I have so far:
http://hg.et.redhat.com/misc/augeas?cmd=manifest;manifest=ed2827402b6a7d7b623a6 4778a4d3292eb3b66c2;path=/lenses/

[2] The docs linked from http://augeas.net/docs/index.html under "Writing Schemas"

_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
 
Old 04-21-2008, 09:39 AM
"Richard W.M. Jones"
 
Default ANNOUNCE: Augeas - a configuration API

On Mon, Apr 21, 2008 at 09:51:47AM +1000, Mike MacCana wrote:
> On Sun, 2008-04-20 at 10:04 +0100, Richard W.M. Jones wrote:
> > On Fri, Apr 18, 2008 at 12:02:15PM +1000, Mike MacCana wrote:
> > > Using 'widely varying formats' is not 'valuable'. It's an unfortunate
> > > accident that wastes everyone's time with various horrible bandaid
> > > solutions, and occasionally makes destroying user data an 'accepted
> > > limitation' of tools like system-config-named.
> >
> > Different formats suit different uses, and in any case I wouldn't
> > trust the people who would develop this new "super-format" not to do
> > something stupid like using XML.
> >
> > Rich.
> >
>
> Admins don't like XML because vi isn't an XML editor. It's the
> equivalent of Microsoft Word, treating presentation and content like
> they're the same thing.

No, it because different formats suit different uses. XML is fine for
people who never learned how to use lex & yacc. Two large
anti-patterns in this area are XSLT (a programming language) and Ant
(a Makefile-type tool). Compare XSLT to CDuce (XSLT done right) and
Ant to plain Makefiles. Also, try converting a short example from
your favorite programming language into XML to see how parsing is
important.

<for var="f">
<for-values>
<value>programming languages</value>
<value>config files</value>
<value>specialist DSLs</value>
</for-values>
<progn>
<print format="XML isn't suitable for %s">
<arg n="0"><subst var="f"/></arg>
</print>
</progn>
</if>

> Config files aren't logically combinations of characters, lines, and
> paragraphs, They're item / value pairs, sections, and subsections.
>
> This is why I mentioned creating an editor earlier. There's no reason
> why you need to see XML when you edit it. shouldn't be able to say 'jump
> to next subsection, copy this object, paste it three times' in the same
> way we do with lines and paragraphs in vi.

It's plainly ridiculous to create a whole new editor just for editing
a particular form of file. This editor you're going to write is going
to be better than vi & emacs? Maybe after thousands of programmers
have worked on it for > 20 years. In the meantime admins will need to
switch between using your editor for one particular sort of file (a
small subset of configuration files on the system) versus all the
other files on the system.

Rich.

--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top

_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
 
Old 04-23-2008, 04:58 AM
Mike MacCana
 
Default ANNOUNCE: Augeas - a configuration API

On Mon, 2008-04-21 at 10:39 +0100, Richard W.M. Jones wrote:


On Mon, Apr 21, 2008 at 09:51:47AM +1000, Mike MacCana wrote:
> Admins don't like XML because vi isn't an XML editor. It's the
> equivalent of Microsoft Word, treating presentation and content like
> they're the same thing.

Also, try converting a short example from
your favorite programming language into XML to see how parsing is
important.


We're not talking about programming language, we're talking about configuration.


> This is why I mentioned creating an editor earlier. There's no reason
> why you need to see XML when you edit it. shouldn't be able to say 'jump
> to next subsection, copy this object, paste it three times' in the same
> way we do with lines and paragraphs in vi.

It's plainly ridiculous to create a whole new editor just for editing
a particular form of file.*


You haven't stated why.


This editor you're going to write is going
to be better than vi & emacs?


vi already does a terrible job of editing config files, as I've previously mentioned. It's designed for words and paragraphs, mean mean nothing in config files (unless you happen to practively edit your config files so they can be edited neatly in vi, which itself is ridiculous, although common).



A command line version of gconfig-editor with keybindings would already crap all over presentation-based editors like vi.



A simple test:



'Delete 3 (shares|virtualhosts|domains'



In vi this data would either be treated as a series of lines, or re-arranged, if the format allows, so that presentation matches content and that these items are sorted into paragraphs.



In vix, you'd type a key for delete, the number 3, and a third key to tell it section (defined as an object of the level where the cursor is).



> Maybe after thousands of programmers have worked on it for > 20 years.



I think you're too blinded by the last 20 years to see what's wrong with presentation-based tools.






Cheers,



Mike



________________________________________________

Mike MacCana

Technical Specialist

Linux Services



IBM Global Services

Level 14, 60 City Rd

Southgate Vic 3000



Phone: +61-3-8656-2138

Fax: +61-3-8656-2423

Email: mmaccana@au1.ibm.com





_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
 

Thread Tools




All times are GMT. The time now is 04:49 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org