<div dir="ltr"><br><br><div class="gmail_quote">On Wed, Aug 13, 2008 at 4:22 PM, Bryan Kearney <span dir="ltr"><<a href="mailto:bkearney@redhat.com">bkearney@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
Raphaël Pinson wrote:<div class="Ih2E3d"><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
On Wed, Aug 13, 2008 at 6:23 AM, David Lutterkort <<a href="mailto:dlutter@redhat.com" target="_blank">dlutter@redhat.com</a> <mailto:<a href="mailto:dlutter@redhat.com" target="_blank">dlutter@redhat.com</a>>> wrote:<br>

<br>
    On Tue, 2008-08-12 at 10:11 +0200, Raphaël Pinson wrote:<br>
<br>
<br>
     > I see an issue with this approach somehow. Puppet is<br>
    "state-centered",<br>
     > while Augeas is "change-centered". If you write a module that will<br>
     > apply changes using Augeas, it will apply these changes at every run<br>
     > of Puppet... Now Puppet resources usually have a state checker so<br>
    that<br>
     > the changes are only applied if a condition is met.<br>
<br>
    At some point somebody has to turn a state description into actions -<br>
    the question is whether that should happen in Puppet or in Augeas.<br>
<br>
     > I think it would be suitable for the augeas module to work this way,<br>
     > too :<br>
     ><br>
     ><br>
     > augeas { "some-random-name":<br>
     >     context => "/files/etc/yum.repos.d",<br>
     >     changes => [<br>
     >       "set fedora.repo/fedora/enabled 1",<br>
     >       "set fedora.repo/fedora/gpgcheck 1",<br>
     >       "set fedora-updates.repo/fedora-updates/enabled 1",<br>
     >       "set fedora-updates.repo/fedora-updates/gpgcheck 1"<br>
     >       ],<br>
     >     onlyif => "get fedora.repo/fedora/enable != '1'"<br>
     ><br>
     > }<br>
     ><br>
     ><br>
     > onlyif could take conditions based on "get" or "match" requests.<br>
</blockquote>
<br>
<br></div>
Just to check. I assume get would support = != > < assuming strings. What would you expect for match? Would it be array cmparisons such as includes, isEmpty, length?<br><font color="#888888">
</font></blockquote><div><br><br>For get, I'd expect to test the value of the node. For match, I'd expect to test the array of nodes returned, for example testing how many nodes matched the expression.<br><br>e.g.<br>
If get returns no value, it means the value of the node is empty.<br>If match returns no value, it means there is no such node.<br><br><br><br>Raphaël<br></div></div><br><br></div>