headers
Daniel Pittman | 1 Nov 2010 07:18
Gravatar

Re: [Puppet Users] RFC: Make file content specification methods consistent.

Nigel Kersten <nigel <at> puppetlabs.com> writes:

> ----------------------- Ticket description ---------------
>
> We have four main ways we can specify file content in a file resource.
>
> The source parameter
> The content parameter
> The file function
> The template function

[...]

> Here's a terrible suggestion that hopefully inspires a better one.  An array
> indicates multi-select logic, separation with a colon means concatenate.

That is terrible, not least because it makes use of a valid filename component
that some platforms (*cough* Macintosh *cough*) have used as a vital part of
their path descriptions, and others use routinely.

Hint: /etc/environment/default-path and content is now gonna suck. :)

> 1a. Use the first source that exists.

[...]

> Is this so unsatisfactory that we need to add more parameters?

I think it could be satisfactory with only a tiny change that will *also*
solve another end-user problem we recently saw on the list:
(Continue reading)

Permalink | Reply | 3 comments |
headers
Leonko | 1 Nov 2010 07:44
Picon
Gravatar

[Puppet Users] Re: require service started at another node

Hello, Bruce. At now we have hard dependence between file storage, db
server and appserver. If it chain broken at any phase we get the
message from zabbix. And we try it automatize this action.

On 29 окт, 21:53, Bruce Richardson <itsbr... <at> workshy.org> wrote:
> On Fri, Oct 29, 2010 at 04:56:34AM -0700, Leonko wrote:

> But can your application server really not cope with the database
> service not being available?  Can they not present a useful error
> message if the database is broken?  How will you cope if the database
> service dies once your appserver has started?
>
> --
> Bruce
>
> If the universe were simple enough to be understood, we would be too
> simple to understand it.

--

-- 
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 <at> googlegroups.com.
To unsubscribe from this group, send email to puppet-users+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Permalink | Reply | 8 comments |
headers
Leonko | 1 Nov 2010 07:58
Picon
Gravatar

[Puppet Users] Re: require service started at another node


Thanks, but  I didn't understand how it works. Maybe you know
documentation for this module?

On 29 окт, 22:09, Ohad Levy <ohadl... <at> gmail.com> wrote:
> You can try using something likehttp://github.com/puppetlabs/puppet-external-resource
>
> Ohad
>
> On Fri, Oct 29, 2010 at 1:56 PM, Leonko <the.leo... <at> gmail.com> wrote:
> > Hello,
> > Anybody now how make with puppet dependence on other service on
> > another node?
>
> > like :  require => Service[dbnode:postgresql]
> > I need ensure that the db is running on another node before start my
> > appserver.
>
> > Thank you.
>
> > --
> > 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 <at> googlegroups.com.
> > To unsubscribe from this group, send email to
> > puppet-users+unsubscribe <at> googlegroups.com<puppet-users%2Bunsubscribe <at> googlegroups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/puppet-users?hl=en.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bruce Richardson | 1 Nov 2010 08:43

Re: [Puppet Users] Re: require service started at another node

On Sun, Oct 31, 2010 at 11:44:51PM -0700, Leonko wrote:
> Hello, Bruce. At now we have hard dependence between file storage, db
> server and appserver. If it chain broken at any phase we get the
> message from zabbix.

But that's not a problem.  Zabbix is monitoring software: it *should*
tell you when important services are broken.

> And we try it automatize this action.

Fine.  But you can't use a single puppet run to make it all happen.  Use
puppet on the database server to make sure that postgresql is running
properly and use puppet on the application host to make sure that the
application server is running *if* the database server is available.
Puppet can automate that much for you.

If you want to have the minimum time between the database server coming
up and the application server starting, there are a number of ways you
could do that; the application host could be checking the db connection
on a regular basis, for instance, or the db server could signal the
application host once the app is up.  But really, your best plan is to

 1.  Make sure that your database service is up early, as resilient as
you can make it and rarely restarted.

 2.  Make your application server tolerant of database downtime (that
is, have the applications generate sensible errors while the db is down
and recover when it is up, rather than just crash and require an
application server restart).
(Continue reading)

Permalink | Reply | 7 comments |
headers
Leonko | 1 Nov 2010 08:57
Picon
Gravatar

[Puppet Users] Re: require service started at another node


>
>  1.  Make sure that your database service is up early, as resilient as
> you can make it and rarely restarted.
>

Thank you. Maybe you know method to validate what db is start early.
It's very important for me.

>  2.  Make your application server tolerant of database downtime (that
> is, have the applications generate sensible errors while the db is down
> and recover when it is up, rather than just crash and require an
> application server restart).

If appserver (java app server like jboss)  start and can't find db
it's crash and need to restart by hand.  We are unable to do anything
with it.

>
> --
> Bruce
>
> Bitterly it mathinketh me, that I spent mine wholle lyf in the lists
> against the ignorant.  -- Roger Bacon, "Doctor Mirabilis"

--

-- 
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 <at> googlegroups.com.
To unsubscribe from this group, send email to puppet-users+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Patrick | 1 Nov 2010 09:06
Picon

Re: [Puppet Users] Re: require service started at another node


On Nov 1, 2010, at 12:57 AM, Leonko wrote:

> 
>> 
>>  1.  Make sure that your database service is up early, as resilient as
>> you can make it and rarely restarted.
>> 
> 
> Thank you. Maybe you know method to validate what db is start early.
> It's very important for me.
> 
> 
>>  2.  Make your application server tolerant of database downtime (that
>> is, have the applications generate sensible errors while the db is down
>> and recover when it is up, rather than just crash and require an
>> application server restart).
> 
> If appserver (java app server like jboss)  start and can't find db
> it's crash and need to restart by hand.  We are unable to do anything
> with it.

Can you give your app a babysitter wrapper service?  This sounds like it might be useful just for uptime.

--

-- 
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 <at> googlegroups.com.
To unsubscribe from this group, send email to puppet-users+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Leonko | 1 Nov 2010 09:14
Picon
Gravatar

[Puppet Users] Re: require service started at another node

You can say more about it?  I do not understand what you say?

> Can you give your app a babysitter wrapper service?  This sounds like it might be useful just for uptime.

--

-- 
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 <at> googlegroups.com.
To unsubscribe from this group, send email to puppet-users+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Permalink | Reply | 1 comment |
headers
Patrick | 1 Nov 2010 09:21
Picon

Re: [Puppet Users] RFC: Make file content specification methods consistent.


On Oct 31, 2010, at 11:18 PM, Daniel Pittman wrote:
I think it could be satisfactory with only a tiny change that will *also*
solve another end-user problem we recently saw on the list:

 file { "/etc/environment/default-path":
   content => "/bin:/usr/bin:/usr/local/bin" + $more_path
 }

 source => "puppet:///foo/bar" + "http://example.com/data"

To me this says, add the strings together then use that as the source.  I would assume "add" means concatenate which means puppet would look for a file at:
protocol: puppet
path: "foo/barhttp://example.com/data"

So this doesn't work for me.

Also, this requires changing the grammar of he puppet parser which I think shouldn't be done to fix one resource.


Oh, and this just works(tm):

 source => ["puppet:///foo/bar.${fqdn}", "puppet:///foo/bar"] +
           # OK, now I am just makin' stuff up at random. ;)
           ["erb:///foo/bar.$fqdn.erb", "template"///foo/bar.erb"] +
           # ...or is that actually nicer than this API change?
           # (selection, not concatenation)
           template("foo/bar.$fqdn.erb", "foo/bar.erb")

The erb protocol stuff in here sounds to me like http://projects.puppetlabs.com/issues/4920 which is very hard to do for technical reasons.  It's mostly because the variables used in the erb file are not sent to the file server.

Note: The template() function is executed on the server when the manifest is compiled.

On 10/30/2010 11:45 AM, Nigel Kersten wrote:
http://projects.puppetlabs.com/issues/5158

>The source parameter, file function and template function all can take an array. For source/file, the first file that exists will be used. For the template function, we concatenate the templates instead.

>The file function takes fully qualified paths only. The template function takes fully qualified paths, or dereferences relative paths as follows. ‘foo/bar.erb’ –> modules/foo/templates/bar.erb

>The latter problem is relatively easily solved, particularly if we implement #4885

>We are going to have to break backwards compatibility to solve the first problem however.


But you don't with my earlier suggestion quoted here:

On Oct 30, 2010, at 9:46 AM, Patrick wrote:
The best solution I can come up with is this.

source - Unchanged because this is used so much.  Tries each source in turn and uses the first one that works.  Fails if none work.
content - Deprecated but kept for backwards compatibility
source_concat - Concatenates all the given sources and causes the resource to fail if any are missing.
content_concat - behaves the same way as content does now and takes precedence over content.

Throw an error if two or more are used at the same time, except allow content and content_concat to exist at the same time for backwards compatibility.


I also think the inconsistencies between "file()" and "template()" should be addressed, but this would simplify it.


This only changes the provider.  Most of the suggestions I've heard change the server and the language.  I think this also keeps full backward compatibility.  (If it doesn't, please tell me)  You say you don't want to add another parameter, but adding another parameter is better than hacking the whole language for one resource.
Also, having the provider parse very complicated input causes a lot of confusion and bugs.  (If you don't believe this, look at the Augeas provider and it's quoting nightmare.)  This way also doesn't reserve any characters in the source string.  Instead it uses the existing parser to handle (almost) all the parsing.

--
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 <at> googlegroups.com.
To unsubscribe from this group, send email to puppet-users+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Permalink | Reply | 2 comments |
headers
Patrick | 1 Nov 2010 09:20
Picon

Re: [Puppet Users] Re: require service started at another node


On Nov 1, 2010, at 1:14 AM, Leonko wrote:

> You can say more about it?  I do not understand what you say?
> 
> 
>> Can you give your app a babysitter wrapper service?  This sounds like it might be useful just for uptime.

The idea is that you wrap this app in a service.  The wrapper is started, stopped, and restarted like a normal service.

When the wrapper is running, ensures that your application is running.  If your application is not running,
the wrapper waits a set time and then starts your app.  The wait time is because you don't want to load the
server by instantly restarting.  This is because if you app crashes during startup every time, you don't
want your server to be excessively loaded by the restart attempts.

Stopping the wrapper stops your app.

Starting the wrapper starts your app.  (then makes sure it keeps running)

Sending a restart to the wrapper, stops the wrapper and then starts the wrapper.

--

-- 
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 <at> googlegroups.com.
To unsubscribe from this group, send email to puppet-users+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Permalink | Reply | 0 comments |
headers
Thomas Bendler | 1 Nov 2010 09:12
Picon
Favicon

Re: [Puppet Users] Re: require service started at another node

2010/11/1 Leonko <the.leonko <at> gmail.com>
[...]
>  2.  Make your application server tolerant of database downtime (that
> is, have the applications generate sensible errors while the db is down
> and recover when it is up, rather than just crash and require an
> application server restart).

If appserver (java app server like jboss)  start and can't find db
it's crash and need to restart by hand.  We are unable to do anything
with it.

Make a start script for the Appserver which do the steps for you:

#! /bin/sh

checkdb () {
  [... code to check if DB is up ...]
}

startdb () {
  [... code to start DB if down ...]
}

startApp () {
  [... code to start App if down ...]
}

if [ ! $(checkdb) ]; then
  startdb
  sleep 60
  if [ ! $(checkdb) ]; then
    echo "Failed, couldn't start DB!"; exit
  else
    startApp
  fi
fi

You can also implement it as a watchdog if you put your code in a construct like this:

while true; do
  [... start logic with checks ...]
  sleep 30
done

Kind regards, Thomas

--
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 <at> googlegroups.com.
To unsubscribe from this group, send email to puppet-users+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Permalink | Reply | 1 comment |

Gmane