On Fri, Feb 5, 2010 at 11:04 AM, Ohad Levy <ohadl...@gmail.com> wrote:
> 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.
>> 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.
>
Ohad, while hacks may be possible today, what I want to achieve here
are core language and out-of-the-box working system features.
I'd prefer to not perpetuate the painful workarounds if possible.
--Michael
--
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.
