Appending to Variables in a global context

[Spenser Gilliland]

I've come into a use case where I need a list of all the instances of
a definition. I'd like the syntax to be

class test {
$instances = []
}

define test::instance() {
$instance += ["$name"]
}

I'm not sure if this will work as anticipated. I believe that this
will only update $instance in the test::instance scope not the test
scope. The only documentation I have been able to find is here.

http://docs.puppetlabs.com/guides/language_tutorial.html#variables

Can anyone help me figure this out? It seems like this would be a
fairly common thing to do.

Spenser

--
Spenser Gilliland
Computer Engineer
Illinois Institute of Technology

[Daniel Pittman]

On Sun, Dec 19, 2010 at 08:24, Spenser Gilliland <spens...@gmail.com> wrote:

> I've come into a use case where I need a list of all the instances of
> a definition.  I'd like the syntax to be

[...]

> I'm not sure if this will work as anticipated.  I believe that this
> will only update $instance in the test::instance scope not the test
> scope.

That would be about the shape of it.

[...]

> Can anyone help me figure this out?  It seems like this would be a
> fairly common thing to do.

I strongly suspect it is actually kind of "not the puppet way", at
least at the moment. Can you tell us what the problem you are trying
to solve is? That would make it easier to help identify the more
canonical puppet way of doing whatever it is.

My guess is that there isn't a nice way of doing it and that answer is
going to be the "concat" module to build a file from little fragments,
or use the Ruby DSL, or something: I guess you need to reference all
those items in some other configuration file, and it doesn't provide a
"include this glob" operation, right?

Regards,
Daniel
--
✣ Daniel Pittman            ✉ dan...@rimspace.net            ☎ +61 401 155 707
              ♽ made with 100 percent post-consumer electrons

[Spenser Gilliland]

> --
> You received this message because you are subscribed to the Google Groups "Puppet Users" group.
> To post to this group, send email to puppet...@googlegroups.com.
> To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
>
>

Yeap, I'm seeing that it doesn't exist yet either. I'm thinking maybe
I can use exported resources or maybe just an exec that increments a
counter on the host. Either way it's not very pretty. My use case is
as follows:

In Debian, Redmine has the option of being installed as several
instances controlled by a single debconf variable. In order to
utilize this feature, I need to supply debconf with the name of all
instances of Redmine on the server. I've split this out into the
following way: A class called Redmine which installs the Redmine
package and should hold an array of all the instances of Redmine to
feed to debconf using the "responsefile" parameter.

So I think I've come up with a solution in my head but it involves me
guaranteeing that the redmine class is instantiated before any of the
redmine::instances are defined. Essentially, I'll use an
environmental variable or file and clear it with the Redmine class and
append to it for each redmine::instance. Maybe like below?

class redmine {
exec{"rm /tmp/instances && touch /tmp/instances"}
}

define redmine::instance
exec{"echo $name >> /tmp/instances"}
}

I guess the next question is can i guarantee that my class will be
instantiated prior to my instances and there is no possibility of the
class being re-instantiated during the course of the puppet run?

Thanks,

[Matthias Saou]

Spenser Gilliland <spens...@gmail.com> wrote:

> Yeap, I'm seeing that it doesn't exist yet either. I'm thinking maybe
> I can use exported resources or maybe just an exec that increments a
> counter on the host. Either way it's not very pretty. My use case is
> as follows:
>
> In Debian, Redmine has the option of being installed as several
> instances controlled by a single debconf variable. In order to
> utilize this feature, I need to supply debconf with the name of all
> instances of Redmine on the server. I've split this out into the
> following way: A class called Redmine which installs the Redmine
> package and should hold an array of all the instances of Redmine to
> feed to debconf using the "responsefile" parameter.
>
> So I think I've come up with a solution in my head but it involves me
> guaranteeing that the redmine class is instantiated before any of the
> redmine::instances are defined. Essentially, I'll use an
> environmental variable or file and clear it with the Redmine class and
> append to it for each redmine::instance. Maybe like below?
>
> class redmine {
> exec{"rm /tmp/instances && touch /tmp/instances"}
> }
>
> define redmine::instance
> exec{"echo $name >> /tmp/instances"}
> }
>
> I guess the next question is can i guarantee that my class will be
> instantiated prior to my instances and there is no possibility of the
> class being re-instantiated during the course of the puppet run?

The approach you're suggesting seems very ugly :-)

I'd suggest trying one of two different approaches :
* Create a definition to which you'll pass an array of all instances,
which will then call the redminde::instance for each. This only
works of course if you're not trying to add new instances from
various puppet classes/definitions.
* Create a fact which returns all of the redmine instances of the
puppet client. This has quite a few limitations, but might work
depending on what you need exactly.

HTH,
Matthias

[Matthew Macdonald-Wallace]

On Sun, 2010-12-19 at 01:51 -0600, Spenser Gilliland wrote:
> Yeap, I'm seeing that it doesn't exist yet either. I'm thinking maybe
> I can use exported resources or maybe just an exec that increments a
> counter on the host. Either way it's not very pretty. My use case is
> as follows:
>
> In Debian, Redmine has the option of being installed as several
> instances controlled by a single debconf variable. In order to
> utilize this feature, I need to supply debconf with the name of all
> instances of Redmine on the server. I've split this out into the
> following way: A class called Redmine which installs the Redmine
> package and should hold an array of all the instances of Redmine to
> feed to debconf using the "responsefile" parameter.
>
> So I think I've come up with a solution in my head but it involves me
> guaranteeing that the redmine class is instantiated before any of the
> redmine::instances are defined. Essentially, I'll use an
> environmental variable or file and clear it with the Redmine class and
> append to it for each redmine::instance. Maybe like below?
>
> class redmine {
> exec{"rm /tmp/instances && touch /tmp/instances"}
> }
>
> define redmine::instance
> exec{"echo $name >> /tmp/instances"}
> }

Can you "read" (from the file system or list the redmine databases in
mysql/postgresql server?) a list of installed instances?

If so, why not setup a custom fact which has all the instances listed as
a csv string:

========== PSEUDO CODE!!! ==========
instances = read_instances() # a class which connects to the db/file
# system to read in the instances and converts them to CSV format #

Facter.add redmine_instances do
setcode do
instances
end
end
===================================

and then template the /tmp/instances file using erb:

========== PSEUDO CODE!!! ============
<% redmine_instances.each do |instance| -%>
instance
<% end -%>
======================================

Your manifest could then source this template onto the file system and
feed the file to debconf.

It's a bit more long winded, however it means that if you want to add
instances, you just add an extra value to the fact.

We use this technique to manage MySQL replication and it works really
well!

Cheers,

M.

[Spenser Gilliland]

> --
> You received this message because you are subscribed to the Google Groups "Puppet Users" group.
> To post to this group, send email to puppet...@googlegroups.com.
> To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
>
>

Matthew,

I'm a bit confused on your code, how does an instance get added to the db?

Matthias

Approach one won't work, I am doing this from multiple different
locations in the code. Also because this is eventually something I
want to hide I would probably just set it up using a variable in the
node definition and have it read by the redmine class.

node redmine {
$instances = ["john", "ted", "nancy"]
include redmine
redmine::instance{"john", "ted", "nancy"}
}

Approach two is similar to Matthews, so I have the same question how
do I add an instance to the db?

[Spenser Gilliland]

Also, just out of interest. Would it make sense to create a feature
request for this? I can think of quite a few instances where this
would be useful.

[Matthew Macdonald-Wallace]

On Sun, 2010-12-19 at 04:40 -0600, Spenser Gilliland wrote:
> Matthew,
>
> I'm a bit confused on your code, how does an instance get added to the db?

Yeah, that's probably my fault... :D

My thought was that if you have a known path to the redmine instances
you could create a ruby class which iterates over the filesystem and
pulls each directory/installation name into a CSV string.

If you prefix your redmine database names with something obvious when
you install them, then you should be able to connect to the database
server and extract the table names that are relevant using "use
mysql;SELECT tableName from tables where tableName LIKE '%redmine_prefix
%';" or similar.

So the "db" which I spoke of is more of a datastore/list which contains
the currently installed redmine instances - how you retrieve this data
is left as an exercise for the reader... ;)

Cheers,

M.

[Spenser Gilliland]

That's still ugly but I see how it works. I think I'll give it a shot
that way see how it goes

I still need to do something to make sure that the class is
instantiated after the tables are instantited.

Run stages maybe? Uhh, still ugly. I wish there was just some kind of
syntactical element for this.

Spenser

> --
> You received this message because you are subscribed to the Google Groups "Puppet Users" group.
> To post to this group, send email to puppet...@googlegroups.com.
> To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
>
>

--

[Daniel Pittman]

On Mon, Dec 20, 2010 at 01:34, Spenser Gilliland <spens...@gmail.com> wrote:

> That's still ugly but I see how it works.  I think I'll give it a shot
> that way see how it goes
>
> I still need to do something to make sure that the class is
> instantiated after the tables are instantited.
>
> Run stages maybe? Uhh, still ugly.  I wish there was just some kind of
> syntactical element for this.

For that, file a feature request bug report. :) FWIW, I think this
overlaps with a similar problem that I faced, and which we used the
'concat' system to work around. Having a standard puppet solution
would be good.

[Spenser Gilliland]

> --
> You received this message because you are subscribed to the Google Groups "Puppet Users" group.
> To post to this group, send email to puppet...@googlegroups.com.
> To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
>
>

I added feature #5416 for this. I suggested two possible syntax
styles. If anyone can think of any others I think we should add them
to the bug.

Spenser