I have re-entered puppet dependancy hell. :(

[Douglas Garstang]

I have a rather complex puppet setup here that consists of multiple
instances of jboss running, with 3rd party software layered on top of
each jboss instance. I just realised that after all this effort that
each instance of jboss is starting well before all the various
portions have been deployed.

Looking over my configuration, I'm at a complete loss as to how to
ensure that jboss starts up last.

The various JBoss RPM's have to be deployed first, as well as all the
associated symlinks, permissions etc. However, I can't move onto doing
the same stuff for the various 3rd party software until all the jboss
files have been deployed. However, jboss can't start until the 3rd
party apps are completely done.

Since there are multiple instances of jboss running, I've used
definitions in most places instead of classes. I therefore can't just
put a require => Class['jboss'] in my 3rd party software module. What
the heck am I going to do?

Doug.

[Ohad Levy]

without reading your manifest, I cant tell for sure, but cant you just add before=>Service["jboss"] in your define?

Ohad

--

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.

[Douglas Garstang]

Ohad,

No, not really because for starters there are anywhere from 1 to 10
instances of jboss running, but not always 10. It depends on the node.
If it was always 10, I could say something like
before=>Service["jboss-inst0"], before=>Service["jboss-inst1"] etc.

PLUS the jboss service is controlled inside a definition, not a class.
I don't know if I can use before => in that case.

Doug.

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.g...@gmail.com
Cell: +1-805-340-5627

[R.I.Pienaar]

hello,

----- "Douglas Garstang" <doug.g...@gmail.com> wrote:

> Ohad,
>
> No, not really because for starters there are anywhere from 1 to 10
> instances of jboss running, but not always 10. It depends on the
> node.
> If it was always 10, I could say something like
> before=>Service["jboss-inst0"], before=>Service["jboss-inst1"] etc.
>
> PLUS the jboss service is controlled inside a definition, not a
> class.
> I don't know if I can use before => in that case.

maybe I am just not understanding you, but if you define a jboss instance with a define, let say jbossinst{"one": .. } and you want to do something *before* that, then just do:

before => Jbossinst["one"]

Isnt that what u are after? Really you need to show us code, you can write 5 pages of english blurp or show 5 lines of code.

[jcbollinger]

On Dec 13, 4:12 pm, Douglas Garstang <doug.garst...@gmail.com> wrote:
> No, not really because for starters there are anywhere from 1 to 10
> instances of jboss running, but not always 10. It depends on the node.
> If it was always 10, I could say something like
> before=>Service["jboss-inst0"], before=>Service["jboss-inst1"] etc.
>
> PLUS the jboss service is controlled inside a definition, not a class.
> I don't know if I can use before => in that case.

Well, "require" and "before" are the main tools you have to work
with. One of these or both together must do the job for you.

If you have n node-specific things dependant on m other, uncorrellated
things, such that it's hard to know on either side what all the
dependencies are, then you may need to perform a refactoring to get it
to work. For example, figuring out how to group either the third-
party stuff or the multiple Service resources or both into classes
might be helpful. That's not inherently incompatible with having the
resource declarations done via defined types.

You may also find that you can use the scoping rules for resource
defaults to set default values for Service/require or for
ThirdPartyThing/before that only affect the JBoss / third party
resources you're trying to manage.

[David Schmitt]

On 13.12.2009 23:12, Douglas Garstang wrote:
> Ohad,
>
> No, not really because for starters there are anywhere from 1 to 10
> instances of jboss running, but not always 10. It depends on the node.
> If it was always 10, I could say something like
> before=>Service["jboss-inst0"], before=>Service["jboss-inst1"] etc.
>
> PLUS the jboss service is controlled inside a definition, not a class.
> I don't know if I can use before => in that case.

What you want to do is introduce a well-known, if artificial,
"synchronization" resource. In the simplest case this can be a stupid
stamp file:

| package { jboss: ... }
|
| application {
| app1: ..
| require => Package[jboss],
| before => File[/tmp/stamp];
| app2: ..
| require => Package[jboss],
| before => File[/tmp/stamp];
| app3: ..
| require => Package[jboss],
| before => File[/tmp/stamp];
| }
|
| file {
| "/tmp/stamp":
| }
|
| service {
| jboss1:
| require => File[/tmp/stamp];
| jboss2:
| require => File[/tmp/stamp];
| jboss3:
| require => File[/tmp/stamp];
| }

You can put the stamp file in a class that you include everywhere you
need to reference it. That way you can avoid all corner cases (like zero
applications). The other resources can be placed into classes or defines
without prejudice.

The only thing I'm not sure about, is whether notifications
(notify/subscribe) would propagate through the stamp file. If you need
this, I'd start experimenting with using an Exec with refreshonly instead.

Regards, DavidS

[R.I.Pienaar]

hello,

> You can put the stamp file in a class that you include everywhere you
> need to reference it. That way you can avoid all corner cases (like
> zero applications). The other resources can be placed into classes or
> defines without prejudice.
>
> The only thing I'm not sure about, is whether notifications
> (notify/subscribe) would propagate through the stamp file. If you need

I am not sure I see the advantage of this over using a class with the actual resources in it? In that case you also would have no problem with notifications etc not working, you can just notify the class or subscribe to the class and all resources in it will be affected.

[David Schmitt]

Using the separate resource allows one to not care about the location of
the various other parts. Your solution, if I understand it correctly
would require to define all services (which are in this case probably
co-located in a define with the application deployment) within a common
class. This is sounds unpractical to me.

Regards, DavidS

[Eric Gerlach]

On Sun, Dec 13, 2009 at 02:12:09PM -0800, Douglas Garstang wrote:
> Ohad,
>
> No, not really because for starters there are anywhere from 1 to 10
> instances of jboss running, but not always 10. It depends on the node.
> If it was always 10, I could say something like
> before=>Service["jboss-inst0"], before=>Service["jboss-inst1"] etc.

Do you number your jboss instances like above? If so, why not have:

3rdparty-thing { "thingy":
before => "jboss-inst0"
}

service { "jboss-inst0":
before => "jboss-inst1"
}

service { "jboss-inst1":
before => "jboss-inst2"
}

...

service { "jboss-instn":
before => "jboss-inst(n+1)"
}

Then have a "terminator" of sorts (which could be in another define):

service { "jboss-inst(n+1)":
ensure => absent
}

You can do arithmetic with variables, so maybe there's a way to do this?

I don't know the details of your situation, but hopefully this either helps or
spurs another idea.

Cheers,

Eric

--
Eric Gerlach, Network Administrator
Federation of Students
University of Waterloo
p: (519) 888-4567 x36329
e: eger...@feds.uwaterloo.ca