Puppet users - Jun 2010 - Composed custom facts, request for opinions and ideas (somewhat related to setting up puppet)

This is somewhat related to an older thread. The topic was how to 
install some perquisite packages for puppet, like augeas, lsb-release, 
cron to name just a few. Puppet is required to reinstall this packages 
if they are accidentally uninstalled. Because of the nature of this 
packages some puppet code should not run in this state.

/For example/ if lsb-release isn''t installed, and clients are both 
ubuntu and debian, the apt package shouldn''t setup sources as it might 
end up switching the distro. (if lsb-release isn''t installed facter can
not distinguish debian from ubuntu)
Augeas resources if are included in the run end up failing the run, thus 
not allowing augeas to be installed.

My conclusion from the list was that facts should be used, so I started 
thinking on something extensible.

The scope is to create a set of facts and a centralizing fact. The 
centralizing fact is called, in my case, systemissane. Now how can I 
centralize these facts?

What I have tried (attached files) is to create a separte collection 
class, which is the bridge between facts. But the require in 
sane_debian_lsb is kind of hackish, not to mention that it limits these 
facts to a single module. So are there any better ideeas? Opinions? Is 
this code absolutely awful? Should I try using a common naming between 
the facts instead of this collection class?



Silviu

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On 6/16/2010 8:27 PM, Silviu Paragina wrote:
> This is somewhat related to an older thread. The topic was how to
> install some perquisite packages for puppet, like augeas, lsb-release,
> cron to name just a few. Puppet is required to reinstall this packages
> if they are accidentally uninstalled. Because of the nature of this
> packages some puppet code should not run in this state.
>
> /For example/ if lsb-release isn''t installed, and clients are both
> ubuntu and debian, the apt package shouldn''t setup sources as it
might
> end up switching the distro. (if lsb-release isn''t installed
facter can
> not distinguish debian from ubuntu)
> Augeas resources if are included in the run end up failing the run, thus
> not allowing augeas to be installed.
The following case will fail, is lsb-release is not installed:

case $lsbdistcodename {
	"lenny": {...}
         "lucid": {...}
}

Wouldn''t that be enough?

Best Regards, David
-- 
dasz.at OG              Tel: +43 (0)664 2602670     Web: http://dasz.at
Klosterneuburg                                         UID: ATU64260999

        FB-Nr.: FN 309285 g          FB-Gericht: LG Korneuburg

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On 17.06.2010 10:53, David Schmitt wrote:
> On 6/16/2010 8:27 PM, Silviu Paragina wrote:
>> This is somewhat related to an older thread. The topic was how to
>> install some perquisite packages for puppet, like augeas, lsb-release,
>> cron to name just a few. Puppet is required to reinstall this packages
>> if they are accidentally uninstalled. Because of the nature of this
>> packages some puppet code should not run in this state.
>>
>> /For example/ if lsb-release isn''t installed, and clients are
both
>> ubuntu and debian, the apt package shouldn''t setup sources as
it might
>> end up switching the distro. (if lsb-release isn''t installed
facter can
>> not distinguish debian from ubuntu)
>> Augeas resources if are included in the run end up failing the run,
thus
>> not allowing augeas to be installed.
>
> The following case will fail, is lsb-release is not installed:
>
> case $lsbdistcodename {
>     "lenny": {...}
>         "lucid": {...}
> }
>
> Wouldn''t that be enough?
>
> Best Regards, David
Interesting ideea. That should actually do for lsb-release, but how 
about for augeas/cron. (I have a similar fact for augeas)
My ideea was to disable any sensitive puppet code in case of some sanity 
checks failing.


Silviu

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On 6/17/2010 1:02 PM, Silviu Paragina wrote:
> On 17.06.2010 10:53, David Schmitt wrote:
>> On 6/16/2010 8:27 PM, Silviu Paragina wrote:
>>> This is somewhat related to an older thread. The topic was how to
>>> install some perquisite packages for puppet, like augeas,
lsb-release,
>>> cron to name just a few. Puppet is required to reinstall this
packages
>>> if they are accidentally uninstalled. Because of the nature of this
>>> packages some puppet code should not run in this state.
>>>
>>> /For example/ if lsb-release isn''t installed, and clients
are both
>>> ubuntu and debian, the apt package shouldn''t setup sources
as it might
>>> end up switching the distro. (if lsb-release isn''t
installed facter can
>>> not distinguish debian from ubuntu)
>>> Augeas resources if are included in the run end up failing the run,
thus
>>> not allowing augeas to be installed.
>>
>> The following case will fail, is lsb-release is not installed:
>>
>> case $lsbdistcodename {
>> "lenny": {...}
>> "lucid": {...}
>> }
>>
>> Wouldn''t that be enough?
>>
>> Best Regards, David
> Interesting ideea. That should actually do for lsb-release, but how
> about for augeas/cron. (I have a similar fact for augeas)
> My ideea was to disable any sensitive puppet code in case of some sanity
> checks failing.
The types should fail if no provider can be found. This in turn should 
fail all depending resources (e.g. require => Augeas[...] ). Can you 
provide a specific example?


Best Regards, David

-- 
dasz.at OG              Tel: +43 (0)664 2602670     Web: http://dasz.at
Klosterneuburg                                         UID: ATU64260999

        FB-Nr.: FN 309285 g          FB-Gericht: LG Korneuburg

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On 17.06.2010 14:30, David Schmitt wrote:
> On 6/17/2010 1:02 PM, Silviu Paragina wrote:
>> On 17.06.2010 10:53, David Schmitt wrote:
>>> On 6/16/2010 8:27 PM, Silviu Paragina wrote:
>>>> This is somewhat related to an older thread. The topic was how
to
>>>> install some perquisite packages for puppet, like augeas,
lsb-release,
>>>> cron to name just a few. Puppet is required to reinstall this
packages
>>>> if they are accidentally uninstalled. Because of the nature of
this
>>>> packages some puppet code should not run in this state.
>>>>
>>>> /For example/ if lsb-release isn''t installed, and
clients are both
>>>> ubuntu and debian, the apt package shouldn''t setup
sources as it might
>>>> end up switching the distro. (if lsb-release isn''t
installed facter
>>>> can
>>>> not distinguish debian from ubuntu)
>>>> Augeas resources if are included in the run end up failing the
run,
>>>> thus
>>>> not allowing augeas to be installed.
>>>
>>> The following case will fail, is lsb-release is not installed:
>>>
>>> case $lsbdistcodename {
>>> "lenny": {...}
>>> "lucid": {...}
>>> }
>>>
>>> Wouldn''t that be enough?
>>>
>>> Best Regards, David
>> Interesting ideea. That should actually do for lsb-release, but how
>> about for augeas/cron. (I have a similar fact for augeas)
>> My ideea was to disable any sensitive puppet code in case of some
sanity
>> checks failing.
>
> The types should fail if no provider can be found. This in turn should 
> fail all depending resources (e.g. require => Augeas[...] ). Can you 
> provide a specific example?
>
>
> Best Regards, David
>
I''ve been left with the impression that if augeas fails for provider 
reasons it fails the whole run.

My test case would imply the same thing.

silviu@puppet-test:/etc/puppet/repo/development/modules/puppet$ cat test.pp
augeas
{ "puppet settings":
         context => "/files/etc/puppet/puppet.conf",
         changes => [  "set main/report true",
                 "set main/server puppet.paragina.ro",],
}


exec
{ "/test.sh":
}
silviu@puppet-test:/etc/puppet/repo/development/modules/puppet$ cat /test.sh
#!/bin/sh

date >> /touchme
exit 1
silviu@puppet-test:/etc/puppet/repo/development/modules/puppet$ sudo 
puppet test.pp \
 >
warning: Could not retrieve fact fqdn
Could not find a default provider for augeas
silviu@puppet-test:/etc/puppet/repo/development/modules/puppet$ ls /touchme
ls: cannot access /touchme: No such file or directory

There is no dependency between them yet the exec resource wasn''t 
applied. If I remember right, the issue with this was that the run 
failed without installing augeas and the machine would be left in a ever 
failing state.


Silviu




-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Wed, Jun 16, 2010 at 21:27 +0300, Silviu Paragina wrote:
> So are there any better ideeas?
Not a better idea, just another idea:

We simply repackaged facter with lsb-release as extra dependency. As we
already have our own package repository to install software released by
our developers, this hardly cost any effort.


Regards,

Robert Scheer
XS4ALL System Administration

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

----- "Silviu Paragina" <silviu@paragina.ro> wrote:

> >
> I''ve been left with the impression that if augeas fails for
provider
> reasons it fails the whole run.
> 
> My test case would imply the same thing.
> 
> silviu@puppet-test:/etc/puppet/repo/development/modules/puppet$ cat
> test.pp
> augeas
> { "puppet settings":
>          context => "/files/etc/puppet/puppet.conf",
>          changes => [  "set main/report true",
>                  "set main/server puppet.paragina.ro",],
> }
> 
> 
> exec
> { "/test.sh":
> }
> silviu@puppet-test:/etc/puppet/repo/development/modules/puppet$ cat
> /test.sh
> #!/bin/sh
> 
> date >> /touchme
> exit 1
> silviu@puppet-test:/etc/puppet/repo/development/modules/puppet$ sudo 
> puppet test.pp \
>  >
> warning: Could not retrieve fact fqdn
> Could not find a default provider for augeas
> silviu@puppet-test:/etc/puppet/repo/development/modules/puppet$ ls
> /touchme
> ls: cannot access /touchme: No such file or directory
> 
> There is no dependency between them yet the exec resource wasn''t 
> applied. If I remember right, the issue with this was that the run 
> failed without installing augeas and the machine would be left in a
> ever 
> failing state.
> 
At puppetcamp Luke said the cron issue is a bug and if someone files it,
they''ll fix it.

You should be able to install package{"cron":} in a run and later in
the same run make crontabs if those resources require =>
Package["cron"]

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.