Hmm, in that specific situation, sure. I can see how some of these would be an odd fit for the language as currently implemented, I sure would like:
* transactional builds ( so an error does not leave a box in an inconsistent, half configured state ) * more of an ability to specify error states * some sort of standardized testing framework On Sat, Aug 20, 2011 at 8:08 PM, Denmat <[email protected]> wrote: > Well you can on some resources types, like an exec, but not on file > resources - which is annoying sometimes. With file resources it's different > but it would be great to have an 'onlyif' parameter. > > So, you can turn your package install definition into an exec that has a > pre-condition. > exec {aptpackage: > command => apt install thing, > onlyif => sometest cond > } > > That may work better for you. > > Den > > On 21/08/2011, at 9:30, Brian Troutwine <[email protected]> wrote: > > I wouldn't wish Puppet to play guess the quantum cat but, rather, to have > the agent's application of its catalog error in a predictable fashion. I'd > like to express the pre-condition that if /etc/apt/apt.conf.d/01proxy exists > in the filesystem then the installation of package apt-cacher should error. > > Puppet, I believe, does not have this capability, and so the catalog build > fails in an obscure manner. Do you suggest that it be a poor idea to include > such pre-conditions in the language? > > On Sat, Aug 20, 2011 at 7:23 PM, Denmat < <[email protected]> > [email protected]> wrote: > >> Hi, >> >> No, you can only declare the state of a resource once. It can't be present >> and absent at the same time. >> >> Den >> >> >> On 21/08/2011, at 8:50, Brian Troutwine < <[email protected]> >> [email protected]> wrote: >> >> PEBKAC, all. >> >> My images were already tainted with 01proxy, so it existed before the >> installation of the apt-cacher. Question: is it possible to set a >> precondition on a resource, say to ensure that a file _doesn't_ exist before >> installation of a package? >> >> On Sat, Aug 20, 2011 at 5:38 PM, Brian Troutwine < >> <[email protected]><[email protected]> >> [email protected]> wrote: >> >>> I also note that the following fails to order as I expect: >>> >>> class base { >>> >>> if $hostname == 'apt' { >>> file { '/etc/apt/apt.conf.d/01proxy': >>> ... >>> require=> Package['apt-cacher'], >>> notify => Service['apt-cacher'], >>> } >>> ... >>> } >>> } >>> >>> node ' <http://apt.example.com> <http://apt.example.com>apt.example.com' >>> { >>> include base, aptcacher >>> } >>> >>> >>> 01proxy is placed in the filesystem before the Package apt-cacher is >>> installed or the Service apt-cacher started. >>> >>> On Sat, Aug 20, 2011 at 3:34 PM, Brian Troutwine < >>> <[email protected]><[email protected]> >>> [email protected]> wrote: >>> >>>> I meant to include more material and have inserted it inline below. My >>>> apologies. >>>> >>>> On Sat, Aug 20, 2011 at 3:31 PM, Brian Troutwine < >>>> <[email protected]><[email protected]> >>>> [email protected]> wrote: >>>> >>>>> Hello, all. >>>>> >>>>> I have a module for apt-cacher and a node definition something like >>>>> this: >>>>> >>>>> class base { >>>>> file { '/etc/apt/apt.conf.d/01proxy': >>>>> ... >>>>> } >>>>> } >>>>> >>>>> node ' <http://apt.example.com> <http://apt.example.com> >>>>> apt.example.com' { >>>>> include base, aptcacher >>>>> >>>>> Class['aptcacher'] -> File['/etc/apt/apt.conf.d/01proxy'] >>>>> } >>>>> >>>>> >>>>> I'm attempting, on the apt server, to ensure that the apt proxy is >>>>> installed _before_ the reference to it being a proxy is made, else I can't >>>>> install the silly thing. However, this dependency forcing fails and the >>>>> proxy reference file is _sometimes_ installed before the proxy itself. >>>>> >>>> >>>> Moreover, if I rewrite the dependency as: >>>> >>>> Service['apt-cacher'] -> File['/etc/apt/apt.conf.d/01proxy'] >>>> >>>> >>>> there is no change. >>>> >>>> >>>>> Why? >>>>> >>>>> -- >>>>> Brian L. Troutwine >>>>> >>>>> >>>> >>>> >>>> -- >>>> Brian L. Troutwine >>>> >>>> >>> >>> >>> -- >>> Brian L. Troutwine >>> >>> >> >> >> -- >> Brian L. Troutwine >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Users" group. >> To post to this group, send email to <[email protected]> >> [email protected]. >> To unsubscribe from this group, send email to >> <[email protected]> >> [email protected]. >> For more options, visit this group at >> <http://groups.google.com/group/puppet-users?hl=en> >> http://groups.google.com/group/puppet-users?hl=en. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Users" group. >> To post to this group, send email to <[email protected]> >> [email protected]. >> To unsubscribe from this group, send email to >> <puppet-users%[email protected]> >> [email protected]. >> For more options, visit this group at >> <http://groups.google.com/group/puppet-users?hl=en> >> http://groups.google.com/group/puppet-users?hl=en. >> > > > > -- > Brian L. Troutwine > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > -- Brian L. Troutwine -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
