you can do all of this stuff already today (maybe not naively).
a lot of people use functions to query or set values on some external data,
output from the function can define which resources get evaluated etc.
another option some people use is to set facter_xxx environment variables
instead of external puppet functions.
i do agree, that at the end of the day, the 30 minutes default time is
insufficient, if you want to make a lot of changes - e.g. at the end you
must wait 30 minutes between each state change (assuming you have many
clients and a few states).
so in this case, I have a gut feeling which says - use the best tool for the
job, maybe puppet is not the right choice on such cases.
Ohad
On Fri, Feb 5, 2010 at 6:34 PM, Trevor Vaughan <tvaug...@onyxpoint.com>wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> This hits close to home with something that I would love to see added to
> the puppetmaster but haven't quite figured out how to describe until
> recently.
>
> I recently realized that, for a given environment, what you actually
> have is a massive parallel program running across various nodes.
> Therefore, what I would like in the puppetmaster is a set of
> stored-state named semaphores.
>
> They would work as follows:
>
> Semaphore: DB=0 on the puppetmaster
>
> node web_server {
> if semaphore('semaphore_db') > 0 {
> include "foo"
> include "bar"
> }
> }
>
> node db_server {
> include "db"
> }
>
> class db {
> service { "some_db":
> ensure => 'running',
> require => Exec['set_me_up']
> }
>
> exec { 'set_me_up':
> command => 'do stuff',
> notify => semaphore('semaphore_db', '>=', '1')
> }
> }
>
> So, what this would do, is to set the semaphore $semaphore_db to 1 only
> if the exec properly executes (which means that the DB got set up
> correctly) and then would only set it to 1 if it was not already >= 1 so
> that multi-state processes can be handled.
>
> Then, once the semaphore has been set, web_server would include what it
> needed to properly function.
>
> Note that this is not a locking process, the normal run of puppet would
> ensue and the state change would only be noticed on the next run.
>
> This does lag things out over a few runs of puppet, but also (I think)
> keeps the entire thing running the 'puppet way' by essentially setting a
> cross-system state fact.
>
> I figured that the semaphore call would be an TLS REST call back to the
> master, or a separate lookup process if you wanted to offload the work
> to a different system.
>
> Thanks,
>
> Trevor
>
> On 02/04/2010 03:42 PM, Michael DeHaan wrote:
> > On Thu, Feb 4, 2010 at 9:58 AM, jcbollinger <john.bollin...@stjude.org>
> wrote:
> >>
> >>
> >> On Feb 3, 3:08 pm, Michael DeHaan <mich...@reductivelabs.com> wrote:
> >>> Actually I think it can be done by leveraging an improved storeconfigs
> and
> >>> the existing language.
> >>
> >> I was wondering whether storeconfigs would come up. The problem I see
> >> with that is storeconfigs, as I understand them, record the managed
> >> resource states each host *should* have, not necessarily those each
> >> one *does* have. What happens to my multinode deployment if at some
> >> point in the middle, Puppet fails to apply a necessary resource state?
> >
> > If Puppet fails applying a state, it should record the current state,
> > not the once and future state.
> >
> > I'll dig into the schema of what it does now, but don't limit your
> > thinking based on what storeconfigs currently does or is,
> > think about what it can be.
> >
> >
> >
> >> Absolutely so, and that connects back to your earlier comments about
> >> message buses. Messaging is the lifeblood of any kind of
> >> orchestration technology, but there are a variety of message exchange
> >> patterns, message implementations, and messaging options, many
> >> combinations of which are viable. Some could reasonably be
> >> characterized as "push", but many others couldn't.
> >
> >
> > This is an software architecture statement, and architecture is
> > independent of execution and concepts.
> >
> > Long term, I expect to see messaging will happen and can then play a
> > much wider role mainly for offline delivery implications
> > and routing. Though much can be hinged on present workings, whether
> > RESTful or RPCy (which, aren't all that different regardless).
> >
> > However, first, small steps.
> >
> >>
> >> Any way around, there is a class of messages needed for this that
> >> Puppet does not currently have: messages from clients advertising the
> >> individual or collective state of their managed resources. The
> >> absolute simplest form would be a reply to the Puppetmaster indicating
> >> whether a catalog was successfully applied, but finer-grained state
> >> messages would be much more flexible. These would address the problem
> >> of discrepancy between supposed and actual state.
> >
> > Eventing and reporting, and an evolved storeconfigs concept are
> > something we're looking at, for sure.
> >
> > Stay tuned, and of course, if you have time, patches are very much
> welcome.
> >
>
> - --
> Trevor Vaughan
> Vice President, Onyx Point, Inc.
> email: tvaug...@onyxpoint.com
> phone: 410-541-ONYX (6699)
>
> - -- This account not approved for unencrypted sensitive information --
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAktr9CYACgkQyWMIJmxwHpR1kwCgvsOCN3x30q/INfSn2yQ0DTSR
> aOwAnjztorRfAVsdCGk9UdyCxDZy3Ok6
> =9cF1
> -----END PGP SIGNATURE-----
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com<puppet-users%2bunsubscr...@googlegroups.com>
> .
> 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 puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
