Applying Catalogs

13 views
Skip to first unread message

Yushu Yao

unread,
May 24, 2011, 1:03:02 PM5/24/11
to puppet-users
Hi Experts,

I need to use puppet to define multiple service sets (e.g. a proxy server, a web server and a gmond). And don't know which of the following two approaches is better.

(For dependency reason I have to apply the above 3 service sets in 3 separate steps, and webserver need proxy, and gmond need webserver, for example)

approach 1).  I can generate compiled catalog for separate service sets, i.e. use different nodes.pp with "puppet master --compile" and generate proxy.yaml, webserver.yaml and gmond.yaml. Then on the client I do puppet apply --apply proxy.yaml, then webserver.yaml, then gmond.yaml in three steps.

approach 2). I can generate compiled catalog for proxy.yaml, then proxy+webserver.yaml, then proxy+webserver+gmond.yaml. Then apply these three catalogs in three steps.


Which way do you suggest?

(Hope I was clear enough in the question :-)

Thanks

-Yushu

+-------------------------------------------------+
| Yushu Yao
| Ph:1-510-486-4690 
|
| Lawrence Berkeley National Lab
| 1 Cyclotron Road
| Berkeley CA 94720 - USA
+-------------------------------------------------+


Patrick

unread,
May 24, 2011, 1:28:16 PM5/24/11
to puppet...@googlegroups.com

On May 24, 2011, at 10:03 AM, Yushu Yao wrote:

> (For dependency reason I have to apply the above 3 service sets in 3 separate steps, and webserver need proxy, and gmond need webserver, for example)

So, why can't you just create three classes, one for each service. Then have each class require the one before it so the dependencies happen in the right order?

Yushu Yao

unread,
May 24, 2011, 1:56:14 PM5/24/11
to puppet...@googlegroups.com
Thanks Patrick!


Because I have inter-node dependency. I.e. webserver might depend on mysql server that's on another node (puppet client), while mysql server at the same time need proxy server. 

Sorry if I'm being too confusing :-)

 

--
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.


jcbollinger

unread,
May 24, 2011, 6:09:55 PM5/24/11
to Puppet Users


On May 24, 12:56 pm, Yushu Yao <y...@lbl.gov> wrote:
> Thanks Patrick!
>
> On Tue, May 24, 2011 at 10:28 AM, Patrick <kc7...@gmail.com> wrote:
>
> > On May 24, 2011, at 10:03 AM, Yushu Yao wrote:
>
> > > (For dependency reason I have to apply the above 3 service sets in 3
> > separate steps, and webserver need proxy, and gmond need webserver, for
> > example)
>
> > So, why can't you just create three classes, one for each service.  Then
> > have each class require the one before it so the dependencies happen in the
> > right order?
>
> Because I have inter-node dependency. I.e. webserver might depend on mysql
> server that's on another node (puppet client), while mysql server at the
> same time need proxy server.
>
> Sorry if I'm being too confusing :-)


Do not confuse functional dependency with configuration dependency.
Only the latter need affect your Puppet manifests.

For example, although your webserver may not function correctly until
your mysql server is configured and running, you can probably apply
the configuration it's going to need whether the mysql server is up
and configured or not. Dependencies matter to Puppet exactly to the
extent that they affect whether and how configurations can be applied
to particular nodes. More often than not, your manifests don't need
to do anything special about inter-node dependencies (beyond
specifying each node's individual configuration).


John

Yushu Yao

unread,
May 24, 2011, 6:18:48 PM5/24/11
to puppet...@googlegroups.com
Thanks John,

My case is a little bit different. Because my webserver might need the IP address of the mysql node, and before mysql node is deployed and configured, it's IP address is not known.


-Yushu

+-------------------------------------------------+
| Yushu Yao
| Ph:1-510-486-4690 
|
| Lawrence Berkeley National Lab
| 1 Cyclotron Road
| Berkeley CA 94720 - USA
+-------------------------------------------------+





--

Peter Meier

unread,
May 24, 2011, 6:26:14 PM5/24/11
to puppet...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Yushu,

> My case is a little bit different. Because my webserver might need the IP
> address of the mysql node, and before mysql node is deployed and configured,
> it's IP address is not known.

you should probably look into exported resources and export the IP of
the mysql server to all your webnodes. If that's a feasible approach.

Otherwise it is still unclear why you want different catalogs for each
service.

~pete
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk3cMIEACgkQbwltcAfKi39YEwCcDfBNZ3ZIFrq1qSrwicTd8u0u
xa8AnR8+EqQkndo8cue+qwTWgUiP7TM/
=4tiU
-----END PGP SIGNATURE-----

jcbollinger

unread,
May 25, 2011, 9:00:06 AM5/25/11
to Puppet Users


On May 24, 5:18 pm, Yushu Yao <y...@lbl.gov> wrote:
> Thanks John,
>
> My case is a little bit different. Because my webserver might need the IP
> address of the mysql node, and before mysql node is deployed and configured,
> it's IP address is not known.

As Peter wrote, you can probably use an exported resource to feed
configuration details of one server into the configuration of
another. That has the added advantage of automatically updating the
second server if the first's configuration should ever change.

Even if you don't want to set up storeconfigs (to support exported
resources), I still don't see the problem. If you need configuration
details from the mysql server to configure the webserver, then just
configure the mysql server first. You can still write all the
manifests together, in advance, and just plug in the appropriate data
when you know them. You can even use extlookup() to feed in the data
at runtime, so that you don't need to modify the manifests themselves.

Really, it seems like you're making this a lot harder than it needs to
be.


John
Reply all
Reply to author
Forward
0 new messages