On Tuesday, February 5, 2013 10:48:38 AM UTC-6, David Kerr wrote:
>
>
>
> On Tuesday, February 5, 2013 6:27:26 AM UTC-8, jcbollinger wrote:
>>
>>
>>
>> On Monday, February 4, 2013 11:49:24 PM UTC-6, David Kerr wrote:
>>>
>>>
>>>
>>> On Monday, February 4, 2013 9:07:49 PM UTC-8, Aaron Russo wrote:
>>>>
>>>>
>>>> On Mon, Feb 4, 2013 at 7:37 PM, David Kerr <ker...@gmail.com> wrote:
>>>>
>>>>> <% @foo = 0 %>
>>>>> <% Array(bar).each do |flan| -%>
>>>>> value <%= @foo %>
>>>>> <% @foo += 1 %>
>>>>> <% end %>
>>>>>
>>>>
>>>> This code worked for me. I just used an inline template, but otherwise
>>>> I had exactly what you had:
>>>>
>>>> link: https://gist.github.com/arusso23/4712284
>>>>
>>>> (I'm on 3.0.1 btw)
>>>>
>>>>
>>>
>>> hmm, ok thanks, good to know it SHOULD work =)
>>>
>>> I believe my problem is that i'm using concat and my expectations of how
>>> that works are incorrect.
>>>
>>>
>>
>> You didn't say what those expectations were, but I'm guessing you hoped
>> the counter would retain its value across multiple evaluations of the
>> template. Perhaps that's why you used a member variable for your counter
>> instead of a local variable. You should expect, however, that every time
>> you invoke the template() or inline_template() function, a new ERB instance
>> will be created to evaluate the given template, so even if you worked
>> around the re-initialization of your counter, I would not expect a
>> continuous sequence across multiple template evaluations.
>>
>> Supposing that you have all the data you want to sequence in one place,
>> one possibility could be to generate your content all in one template. If
>> you don't have it all in one place, on the other hand, and you can't assign
>> sequence numbers manually, then I am skeptical about sequence numbers being
>> useful to you / doing what you want even if you could generate them.
>>
>> If you tell us more about the problem then maybe we'll have
>> better-targeted suggestions.
>>
>>
>> John
>>
>>
> Sorry about that, I usually try to keep my questions it simple and generic
> to avoid getting bogged down in details, but as you suggested it's the
> details that are killer here. So I'll go deeper into the problem.
>
> You guessed correct though, my assumption was that each concact::fragment
> would get a buffer containing every exported element and then i'd have to
> loop over it. And that's obviously not the case, each concat::fragment gets
> executed once per each element.
>
> So what I have is a PgPool config file, it's fairly large and there are a
> number of tunables in it. At the end of the file is the server section that
> looks
> basically needs to look like like:
>
> backend_hostname0 = 192.168.1.10
> backend_port0 = 5432
> backend_weight0 = 1
> backend_data_directory0 = '/db/pg'
> backend_flag0 = 'ALLOW_TO_FAILOVER'
>
> backend_hostname1 = 192.168.1.11
> backend_port1 = 5432
> backend_weight1 = 1
> backend_data_directory1 = '/db/pg'
> backend_flag1 = 'ALLOW_TO_FAILOVER'
>
>
> pgpool requires you start with 0 and go in sequence, i tried putting
> random #s in there and it doesn't work.
>
> Each postgres server will register the info via exported resources.
>
> This is fairly easy with concat (except for the sequence) but w/o it I'm
> not entirely sure how to make it happen.
>
>
So you were looking for different nodes to export fragments with different
sequence numbers embedded in the content? That was SO never going to
work. Every node's catalog is compiled independently of all the others'.
Even collecting exported resources isn't really an exception to that rule.
You could do what you wanted via exported resources if Puppet provided for
exporting data, but it does not. Only resources may be exported, and there
is no public API by which one resource implementation may interrogate
others.
If you want to generate a sequence of consecutive numbers then it will need
to be done either manually (outside Puppet, at least) or all on one node.
Either form will be easier to manage if you centralize your data in a class
variable, hiera store, or similar. Supposing that by some means you obtain
a data structure similar to this:
{
'192.168.1.10' => {
port => 5432,
weight = 1
data_directory = '/db/pg'
flag = 'ALLOW_TO_FAILOVER'
},
'192.168.1.11' => {
port => 5432,
weight = 1
data_directory = '/db/pg'
flag = 'ALLOW_TO_FAILOVER'
},
...
}
your pg server nodes can read their own, individual configuration
parameters from it (even to determining that they should *be* pg servers),
whereas the pool server can process the whole thing in one template to
produce the server section of the pool config file.
John
--
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 post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
