[Puppet Users] Re: Patterns for building configs using hashes & arrays

2014-05-25 Thread William Leese
I've always found that when creating modules I'd focus on creating class 
parameters out of the most important configuration options of whatever I'm 
managing. After that I'd add a similar approach as yours for "everything 
else". This is a good approach because your module becomes usable for all 
the use cases you're not applying but other people might want. 

Nothing is more frustrating than finding a great module, but not being able 
to use it straight away because it is missing that vital configuration 
parameter!

So in this light, I'd say your approach is good. It might be better if you 
single out the most commonly used parameters and expose them directly just 
for clarity, but it might not always provide usability/readability benefits.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1445a47a-2619-4672-9572-ee02e208e13a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[Puppet Users] Re: Puppet Dashboard installation on Debian Wheezy

2014-05-25 Thread Ghaith
Hi ,

After installing the script and while starting the service i obtain the 
error message bellow

/etc/init.d/puppet-dashboard start
[] Starting Puppet Dashboard:/usr/bin/ruby: No such file or directory 
-- /usr/share/puppet-dashboard/script/server (LoadError)
[FAIL] Puppet Dashboard is not running ... failed!
 failed!


Any idea please.
Thanks

Le mercredi 8 août 2012 12:10:37 UTC+2, Pierre Mavro a écrit :
>
> Hi,
>
> I've got an issue on installing Puppet Dashboard on Debian wheezy. When I 
> launch the db:migrate, I've got an error :
>
>> > rake RAILS_ENV=production db:migrate --trace  
>> NOTE: Gem.source_index is deprecated, use Specification. It will be 
>> removed on or after 2011-11-01.
>> Gem.source_index called from 
>> /usr/share/puppet-dashboard/vendor/rails/railties/lib/rails/gem_dependency.rb:21.
>> NOTE: Gem::SourceIndex#initialize is deprecated with no replacement. It 
>> will be removed on or after 2011-11-01.
>> Gem::SourceIndex#initialize called from 
>> /usr/share/puppet-dashboard/vendor/rails/railties/lib/rails/vendor_gem_source_index.rb:100.
>> NOTE: Gem::SourceIndex#add_spec is deprecated, use 
>> Specification.add_spec. It will be removed on or after 2011-11-01.
>> Gem::SourceIndex#add_spec called from 
>> /usr/lib/ruby/1.9.1/rubygems/source_index.rb:91.
>> NOTE: Gem::SourceIndex#add_spec is deprecated, use 
>> Specification.add_spec. It will be removed on or after 2011-11-01.
>> Gem::SourceIndex#add_spec called from 
>> /usr/lib/ruby/1.9.1/rubygems/source_index.rb:91.
>> NOTE: Gem::SourceIndex#add_spec is deprecated, use 
>> Specification.add_spec. It will be removed on or after 2011-11-01.
>> Gem::SourceIndex#add_spec called from 
>> /usr/lib/ruby/1.9.1/rubygems/source_index.rb:91.
>> NOTE: Gem::SourceIndex#add_spec is deprecated, use 
>> Specification.add_spec. It will be removed on or after 2011-11-01.
>> Gem::SourceIndex#add_spec called from 
>> /usr/lib/ruby/1.9.1/rubygems/source_index.rb:91.
>> NOTE: Gem::SourceIndex#add_spec is deprecated, use 
>> Specification.add_spec. It will be removed on or after 2011-11-01.
>> Gem::SourceIndex#add_spec called from 
>> /usr/lib/ruby/1.9.1/rubygems/source_index.rb:91.
>> NOTE: Gem::SourceIndex#add_spec is deprecated, use 
>> Specification.add_spec. It will be removed on or after 2011-11-01.
>> Gem::SourceIndex#add_spec called from 
>> /usr/lib/ruby/1.9.1/rubygems/source_index.rb:91.
>> NOTE: Gem::SourceIndex#add_spec is deprecated, use 
>> Specification.add_spec. It will be removed on or after 2011-11-01.
>> Gem::SourceIndex#add_spec called from 
>> /usr/lib/ruby/1.9.1/rubygems/source_index.rb:91.
>> NOTE: Gem::SourceIndex#add_spec is deprecated, use 
>> Specification.add_spec. It will be removed on or after 2011-11-01.
>> Gem::SourceIndex#add_spec called from 
>> /usr/lib/ruby/1.9.1/rubygems/source_index.rb:91.
>> NOTE: Gem::SourceIndex#add_spec is deprecated, use 
>> Specification.add_spec. It will be removed on or after 2011-11-01.
>> Gem::SourceIndex#add_spec called from 
>> /usr/lib/ruby/1.9.1/rubygems/source_index.rb:91.
>> NOTE: Gem::SourceIndex#add_spec is deprecated, use 
>> Specification.add_spec. It will be removed on or after 2011-11-01.
>> Gem::SourceIndex#add_spec called from 
>> /usr/lib/ruby/1.9.1/rubygems/source_index.rb:91.
>> NOTE: Gem::SourceIndex#add_spec is deprecated, use 
>> Specification.add_spec. It will be removed on or after 2011-11-01.
>> Gem::SourceIndex#add_spec called from 
>> /usr/lib/ruby/1.9.1/rubygems/source_index.rb:91.
>> NOTE: Gem::SourceIndex#add_spec is deprecated, use 
>> Specification.add_spec. It will be removed on or after 2011-11-01.
>> Gem::SourceIndex#add_spec called from 
>> /usr/lib/ruby/1.9.1/rubygems/source_index.rb:91.
>> NOTE: Gem::SourceIndex#add_spec is deprecated, use 
>> Specification.add_spec. It will be removed on or after 2011-11-01.
>> Gem::SourceIndex#add_spec called from 
>> /usr/lib/ruby/1.9.1/rubygems/source_index.rb:91.
>> NOTE: Gem::SourceIndex#add_spec is deprecated, use 
>> Specification.add_spec. It will be removed on or after 2011-11-01.
>> Gem::SourceIndex#add_spec called from 
>> /usr/lib/ruby/1.9.1/rubygems/source_index.rb:91.
>> NOTE: Gem::SourceIndex#add_spec is deprecated, use 
>> Specification.add_spec. It will be removed on or after 2011-11-01.
>> Gem::SourceIndex#add_spec called from 
>> /usr/lib/ruby/1.9.1/rubygems/source_index.rb:91.
>> NOTE: Gem::SourceIndex#add_spec is deprecated, use 
>> Specification.add_spec. It will be removed on or after 2011-11-01.
>> Gem::SourceIndex#add_spec called from 
>> /usr/lib/ruby/1.9.1/rubygems/source_index.rb:91.
>> NOTE: Gem::SourceIndex#add_spec is deprecated, use 
>> Specification.add_spec. It will be removed on or after 2011-11-01.
>> Gem::SourceIndex#add_spec called from 
>> /usr/lib/ruby/1.9.1/rubygems/source_index.rb:91.
>> NOTE: Gem::SourceIndex#add_spec is deprecated, use 
>> Specification.add_spec. It will be removed on or after 2011-11-01.
>> Gem::SourceIndex#add_spec called from 
>> /usr/li

Re: [Puppet Users] Error starting PuppetDB

2014-05-25 Thread Ken Barber
No problem, the error messages as exceptions are - somewhat not helpful.
The trick for a user to reading JVM stack traces is to ignore the stack
trace, and focus on the errors only - its the noise that makes it hard.

Just thank your stars you aren't forced to read an erlang stack trace
*wink*.

ken.


On Sat, May 24, 2014 at 3:48 PM, Miguel Angel Coa M.
wrote:

> Hi Ken,
> in fact i had duplicate entry "jetty port" in file database.ini and
> jetty.ini . I delete entry of database.ini and restart my puppetdb service
> and this run ok.
>
> Thanks for you help.
>
>
> 2014-05-24 8:48 GMT-04:00 Ken Barber :
>
>>  > 2014-05-24 02:07:01,260 ERROR [p.t.logging] Uncaught exception
>> > java.lang.IllegalArgumentException: Duplicate configuration entry:
>> [:jetty
>> > :port]
>>
>> So this is caused by, well a duplicate entry in your configuration (in
>> this case /etc/puppetdb/conf.d).
>>
>> One good trick to find this kind of thing:
>>
>> cd /etc/puppetdb/conf.d
>> grep '' *.ini | grep port
>>
>> There should be only 1 'port' declaration in the [jetty] block
>> (usually in jetty.ini).
>>
>> Here are my results:
>>
>> root@puppetdb1:/etc/puppetdb/conf.d# grep '' *.ini | grep port
>> database.ini:# For PostgreSQL: //host:port/databaseName
>> jetty.ini:port = 8080
>> jetty.ini:# The port to listen on for HTTPS connections
>> jetty.ini:ssl-port = 8081
>> repl.ini:# What port the REPL should listen on
>> repl.ini:port = 8082
>>
>> So 1 port entry in the [jetty] block and 1 port entry in the [repl] block.
>>
>> ken.
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Puppet Users" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/puppet-users/bOdQJX0UAoU/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> puppet-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/puppet-users/CAE4bNTnkkRwoKA9y_O8RUtCyuH54Kz1_5UWh1kBFEKn_-Wd3DA%40mail.gmail.com
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/CALkCwJC9AKzZRBaXu9iUV9fHYNMo2BdMNUio3mGepE6Z1y4MRA%40mail.gmail.com
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAE4bNTmiLnvnXAaPTAwKzDf1-zdysFtR_u6mTdnfvzwhjemAEw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


[Puppet Users] Patterns for building configs using hashes & arrays

2014-05-25 Thread Jesse Cotton
I am new to puppet and decided to really get my feet wet by writing a 
duplicity module (https://github.com/JCotton1123/puppet-duplicity.git). I 
am struggling to deal with the fact that variables are immutable and cannot 
be reassigned (within the same scope). This has become a real issue while 
trying to dynamically build hashes and arrays that reflect the options and 
flags that are passed to duplicity. I opted for this approach b/c it makes 
composition easier and it results in a very clean template definition. For 
example,

```

  <%- @_flags.each do |flag| -%>
  <%= flag -%> \
  <%- end -%>
  <%- @_options.each do |key,val| -%>
  <%= key -%> <%= val -%> \
  <%- end -%>
```


As opposed to checking for the existence of a dozen different variables and 
outputting their values if they have a "good" value.

How do others work around this issue? I am looking at this the wrong way?

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/fcca193a-8ceb-4dd3-a7bc-c653c38a7734%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] initial_token for cassandra module

2014-05-25 Thread Tim Dunphy
>
> Generate the number of tokens that's the maximum number of nodes you
> expect in your cassandra clusters (for example 15), put them into array,
> and let the module use them, for example:
> $tokens = [ '-9223372036854775808', '-6148914691236517206',
> '-3074457345618258604', '-2' , '3074457345618258600', '6148914691236517202'
> ]
> Then in your erb use something like:
> <%= @token[@node_number] %>
>
> So, basically, either you write puppet function that generates tokes or
> you generate static tokens yourself.


That's a really great idea! I'll give it a shot. Thank you!

Tim


On Sun, May 25, 2014 at 1:44 PM, Jakov Sosic  wrote:

> On 05/25/2014 05:38 AM, Tim Dunphy wrote:
>
>> Hey all,
>>
>> I'm trying to write a puppet module to deploy the cassandra database
>> automatically. I'm using puppet templates to provide the IP address to
>> the listen_address parameter of the cassandra.yaml file like so:
>>
>> listen_address: <%= ipaddress %>
>>
>> So far that part's working beautifully! However in cassandra there is
>> the concept of the 'initial_token' which is based on another concept
>> called 'partition type' which is used to dictate what data goes where in
>> a cassandra cluster.
>>
>> Now in determining the 'inital_token' you generally use a mathematical
>> formula which you can read some more about here if I've managed to pique
>> anyone's curiosity:
>>
>> http://www.datastax.com/documentation/cassandra/1.2/
>> cassandra/configuration/configGenTokens_c.html
>>
>> The type of data partition I'm using is called 'murmur3' and it uses
>> this algorithm to determine a nodes' initial_token it uses to join a
>> cassandra cluster.
>>
>> The murmur3 token generation process is described like this:
>>
>> Use this method for generating tokens when you are *not* using virtual
>>
>> nodes (vnodes) and using the Murmur3Partitioner
>> > cassandra/architecture/architecturePartitionerM3P_c.
>> html#concept_ds_ns5_spf_fk> (default).
>>
>> This partitioner uses a maximum possible range of hash values from -2
>> 63 to +2 63 -1. To calculate tokens for this partitioner:
>>
>> python -c 'print [str(((2**64 / number_of_tokens) * i) - 2**63) for i in
>> range(number_of_tokens)]'
>>
>> For example, to generate tokens for 6 nodes:
>>
>> python -c 'print [str(((2**64 / 6) * i) - 2**63) for i in range(6)]'
>>
>> The command displays the token for each node:
>>
>> [ '-9223372036854775808', '-6148914691236517206', '-3074457345618258604',
>>'-2' , '3074457345618258600', '6148914691236517202' ]
>>
>>
>> What I'm struggling to do is to come up with a way to express this idea
>> in puppet terms that I can use in a puppet template so that I can have the
>> template automatically generate an answer to the initial_token question
>> such that it will turn up the the cassandra.yaml file like so:
>>
>> intial_token:-9223372036854775808
>>
>>
>> I am definitely up for any suggestions anyone may have for this rather
>> fascinating problem!
>>
>
> If I understand it correctly, initial_tokens are always the same - meaning
> consecutive runs of the same function will generate same tokens.
>
> You can then write function that will be run on puppet master and will
> generate tokens.
>
>
> If the function is always the same - meaning it doesn't have some
> randomizing parameter like cluster name or something that would generate
> different tokens for different clusters, you can even generate the numbers
> beforehand and put them in an array:
> '-9223372036854775808'
> '-6148914691236517206'
> '-3074457345618258604'
> '-2'
> '3074457345618258600'
> '6148914691236517202'
>
> Generate the number of tokens that's the maximum number of nodes you
> expect in your cassandra clusters (for example 15), put them into array,
> and let the module use them, for example:
>
> $tokens = [ '-9223372036854775808', '-6148914691236517206',
> '-3074457345618258604', '-2' , '3074457345618258600', '6148914691236517202'
> ]
>
> Then in your erb use something like:
>
> <%= @token[@node_number] %>
>
>
> So, basically, either you write puppet function that generates tokes or
> you generate static tokens yourself.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/puppet-users/53822C08.5020700%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
GPG me!!

gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-us

Re: [Puppet Users] Puppet and Dpkg Locks ...

2014-05-25 Thread Jakov Sosic

On 05/24/2014 04:01 AM, Matt Wise wrote:

When you have hundreds of hosts and run Puppet every 30 mins (splayed
across the hour), it seems that you end up running into various 'dpkg'
locks fairly randomly and at a surprisingly high occurrence (once or
twice a day at least). This happens if you do something simple like a
cron-based 'apt-get update' or 'apt-get autoclean'. It happens even more
often, oddly, when you tell Puppet to always install Package-Foo, and
you manually run jobs across the farms occasionally to upgrade Package-Foo.

Is there any way to tell Puppet to wait and then re-try when theres a
dpkg lock in place, rather than outright failing? Overall its just a
nuisance, but we must get 3-5 of these reports a day..


Maybe hack the dpkg package provider?

BTW, how did you set up monitoring/reporting of your puppet agents and 
agent runs?


--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/53826EBB.7020905%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] Re: Puppet 3.6.0... and scaling?

2014-05-25 Thread Tristan Smith
I've been using the default (which if I read correctly is 5s?); seems
likely that a good answer here for me would be to push it out to
$something_long and use restart.txt or somesuch to uptake changes. I may
try that this week.

My MaxRequests was already 10k. I'm guessing that 5 seconds of cache was
approximately equivalent to jack and squat. I'm not sure if my attempt to
tune by granting more workers would've done me any good.


On Fri, May 23, 2014 at 5:25 PM, Chuck  wrote:

> I had it set to 3 minutes for this test.
>
> I am going to work on trying some different settings.
>
> So far the best result has been with the following settings
>
> PassengerMaxRequests 5000
> environment_timeout 15 minutes
> "service httpd graceful" whenever my svn update script detects a change.
>
> I will be working on getting more information.
>
>
>
>
> On Friday, May 23, 2014 3:24:43 PM UTC-5, Josh Partlow wrote:
>>
>> Hi Tristan, Chuck,
>>
>> What environment_timeout do you have set currently?
>>
>> On Friday, May 23, 2014 12:20:33 PM UTC-7, Tristan Smith wrote:
>>>
>>> Whuf.   I'm already at 1, so that's not it for me.
>>>
>>> Seems like the doubled run time was just murdering me in the face.
>>> Trying to run 1000 clients in 30m was just too much. Guess I could make it
>>> an hour splay, but the overall resource requirement change is sufficiently
>>> large I'm probably just going to see about opting out of directory
>>> environments for a couple revisions, wait for them to tune up a bit.
>>>
>>>
>>>
>>>
>>> On Fri, May 23, 2014 at 10:23 AM, Chuck  wrote:
>>>
 I am noticing increase CPU and Memory requirements from Puppet 3.4.3

 I had to set the following passenger config so that my server would not
 run out of memory:
 PassengerMaxRequets 1

 CPU idle 3.4.3 = 70% - 80%
 Memory utilization = 52%

 CPU idle 3.6.1 =  60% - 73%
 Memory utilization = 85%

 --
 You received this message because you are subscribed to a topic in the
 Google Groups "Puppet Users" group.
 To unsubscribe from this topic, visit https://groups.google.com/d/
 topic/puppet-users/arLckU-mPhw/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to
 puppet-users...@googlegroups.com.
 To view this discussion on the web visit https://groups.google.com/d/
 msgid/puppet-users/2c9172e1-6129-46d1-94f1-38c078d72226%
 40googlegroups.com
 .

 For more options, visit https://groups.google.com/d/optout.

>>>
>>>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "Puppet Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/puppet-users/arLckU-mPhw/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/490ad0ec-a35a-4ab3-a0a9-88e52e752083%40googlegroups.com
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAKdO7cc%2BYe1-LSSk5_DBrMdD5YaqCdcRwuGKL6VqJ3AwGNE4Zg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] EC2 autoscaling reusing hostnames

2014-05-25 Thread Jakov Sosic

On 05/24/2014 07:54 AM, Bad Tux wrote:


Am I missing a configuration option in the manual to somehow disable SSL
certificate validation? Does everybody add a cron job to their puppet
master to stop the puppetmaster daemon and blow away its SSL directory
then restart it at exactly 12:00AM every day, and the same on the
instances at exactly 12:02AM every day? Or are we the only people on the
planet who actually use Amazon's auto-scaling feature *plus* use Puppet
at the same time? Curious penguins are... curious!


Can you somehow get list of active nodes from balancer? You could use 
that list in a daily cron to do a 'puppet cert clean' and remove all 
other certificates?


Another, and maybe even better solution would be to add a script that 
will signal puppet to remove cert of an instance once the instance goes 
into spindown? Don't know if thats possible, didn't use amazon so much...


--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/538234A6.80302%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] initial_token for cassandra module

2014-05-25 Thread Jakov Sosic

On 05/25/2014 05:38 AM, Tim Dunphy wrote:

Hey all,

I'm trying to write a puppet module to deploy the cassandra database
automatically. I'm using puppet templates to provide the IP address to
the listen_address parameter of the cassandra.yaml file like so:

listen_address: <%= ipaddress %>

So far that part's working beautifully! However in cassandra there is
the concept of the 'initial_token' which is based on another concept
called 'partition type' which is used to dictate what data goes where in
a cassandra cluster.

Now in determining the 'inital_token' you generally use a mathematical
formula which you can read some more about here if I've managed to pique
anyone's curiosity:

http://www.datastax.com/documentation/cassandra/1.2/cassandra/configuration/configGenTokens_c.html

The type of data partition I'm using is called 'murmur3' and it uses
this algorithm to determine a nodes' initial_token it uses to join a
cassandra cluster.

The murmur3 token generation process is described like this:

Use this method for generating tokens when you are *not* using virtual
nodes (vnodes) and using the Murmur3Partitioner

 (default).
This partitioner uses a maximum possible range of hash values from -2
63 to +2 63 -1. To calculate tokens for this partitioner:

python -c 'print [str(((2**64 / number_of_tokens) * i) - 2**63) for i in 
range(number_of_tokens)]'

For example, to generate tokens for 6 nodes:

python -c 'print [str(((2**64 / 6) * i) - 2**63) for i in range(6)]'

The command displays the token for each node:

[ '-9223372036854775808', '-6148914691236517206', '-3074457345618258604',
   '-2' , '3074457345618258600', '6148914691236517202' ]


What I'm struggling to do is to come up with a way to express this idea in 
puppet terms that I can use in a puppet template so that I can have the 
template automatically generate an answer to the initial_token question such 
that it will turn up the the cassandra.yaml file like so:

intial_token:-9223372036854775808


I am definitely up for any suggestions anyone may have for this rather 
fascinating problem!


If I understand it correctly, initial_tokens are always the same - 
meaning consecutive runs of the same function will generate same tokens.


You can then write function that will be run on puppet master and will 
generate tokens.



If the function is always the same - meaning it doesn't have some 
randomizing parameter like cluster name or something that would generate 
different tokens for different clusters, you can even generate the 
numbers beforehand and put them in an array:

'-9223372036854775808'
'-6148914691236517206'
'-3074457345618258604'
'-2'
'3074457345618258600'
'6148914691236517202'

Generate the number of tokens that's the maximum number of nodes you 
expect in your cassandra clusters (for example 15), put them into array, 
and let the module use them, for example:


$tokens = [ '-9223372036854775808', '-6148914691236517206', 
'-3074457345618258604', '-2' , '3074457345618258600', 
'6148914691236517202' ]


Then in your erb use something like:

<%= @token[@node_number] %>


So, basically, either you write puppet function that generates tokes or 
you generate static tokens yourself.


--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/53822C08.5020700%40gmail.com.
For more options, visit https://groups.google.com/d/optout.