Puppet users - Jan 2010 - Is anyone managing Glassfish configuration with puppet?

Has anyone found a clean way to manage Glassfish configuration with puppet?

Glassfish was designed to be managed through a WebUI or a CLI tool known as
asadmin.  Making changes using these tools modifies a domain.xml file.
 Glassfish reads and writes this file every time it restarts, even if the
contents are the same, which changes the timestamp.  I believe this can be
addressed by setting puppet to use a different checksum.

However, the real question is should the domain.xml be managed directly?  It
is a messy file and some configuration updates made through the asadmin tool
change the file in several places.  I thought I might make things simpler by
using templates and creating a domain.xml.erb and this is working but
porting changes I make from a local development Glassfish instance back to
that file is tedious and error prone.

One approach could be to create a mechanism to manage incremental changes
(asadmin commands) which modify the underlying structure (domain.xml) like
RoR''s migrations or Java''s bering do with SQL statements to
modify a schema.
 But I don''t see an easy way to use the current abstractions in puppet
to do
this.

Another approach would be to have puppet really understand Glassfish as a
resource similar to users in puppet currently.  You manage them at a high
level using tools like adduser to make modifications and getent to verify a
configuration as opposed to managing the /etc/passwd and /etc/group files
directly.  My fear with this approach is I''m not sure asadmin is robust
enough to query and return current settings and that I''ll end up
writing a
lot of code to parse and search for nasty XML fragments and this will be
brittle as the Glassfish team changes the format of the domain.xml as
development progresses.

I''d like to know if others have found a good way of approaching this
kind of
problem?  I expect to encounter the same type of issues with OpenMQ and I
imagine many of the other appservers could pose similar challenges.

thanks,
chuck

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

On Thu, Jan 28, 2010 at 5:26 AM, chuck clark <cclark@ziclix.com>
wrote:
> Has anyone found a clean way to manage Glassfish configuration with puppet?
> Glassfish was designed to be managed through a WebUI or a CLI tool known as
> asadmin.  Making changes using these tools modifies a domain.xml file.
>  Glassfish reads and writes this file every time it restarts, even if the
> contents are the same, which changes the timestamp.  I believe this can be
> addressed by setting puppet to use a different checksum.
> However, the real question is should the domain.xml be managed directly?
 It
> is a messy file and some configuration updates made through the asadmin
tool
> change the file in several places.  I thought I might make things simpler
by
> using templates and creating a domain.xml.erb and this is working but
> porting changes I make from a local development Glassfish instance back to
> that file is tedious and error prone.
> One approach could be to create a mechanism to manage incremental changes
> (asadmin commands) which modify the underlying structure (domain.xml) like
> RoR''s migrations or Java''s bering do with SQL statements
to modify a schema.
>  But I don''t see an easy way to use the current abstractions in
puppet to do
> this.
> Another approach would be to have puppet really understand Glassfish as a
> resource similar to users in puppet currently.  You manage them at a high
> level using tools like adduser to make modifications and getent to verify a
> configuration as opposed to managing the /etc/passwd and /etc/group files
> directly.  My fear with this approach is I''m not sure asadmin is
robust
> enough to query and return current settings and that I''ll end up
writing a
> lot of code to parse and search for nasty XML fragments and this will be
> brittle as the Glassfish team changes the format of the domain.xml as
> development progresses.
I think a custom resource to drive asadmin is probably the right way to go.
What version are you using?
As of Glassfish v3 there''s a good REST API ( v3asadmin is essentially
a http client).
See the article here:

http://blogs.sun.com/aquatic/entry/glassfish_rest_interface_for_management

(there are links to the dev. api there too).

Out of interest, how do you install glassfish? I had a look round a while back
and couldn''t find any RPMs at all.

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

>
> I think a custom resource to drive asadmin is probably the right way to go.
> What version are you using?
> As of Glassfish v3 there''s a good REST API ( v3asadmin is
essentially
> a http client).
> See the article here:
>
> http://blogs.sun.com/aquatic/entry/glassfish_rest_interface_for_management
>
> (there are links to the dev. api there too).
>
That would make everything so much simpler.  Unfortunately we''re still
on
v2.1 so we can''t leverage this yet.
>
> Out of interest, how do you install glassfish? I had a look round a while
> back
> and couldn''t find any RPMs at all.
>
>
It isn''t pretty but it seems to work.  The core parts of our manifest
are
below:

  exec { "DownloadGlassfish":
    cwd     => "$download_dir",
    command => "wget $download_url",
    creates => "$download_dir/$prg_tarball",
  }

  exec { "InstallGlassfish":
    cwd     => "$download_dir",
    command => "echo ''A'' | java -Xmx256m -jar
$prg_tarball; mv glassfish
$installed; chmod -R +x $installed/lib/ant/bin; rm $installed/setup.xml",
    user    => pulse,
    creates => "$installed",
    require => [Exec["DownloadGlassfish"],
File["/etc/init.d/glassfish"]],
  }

  exec { "ConfigureGlassfish":
    cwd       => "$installed",
    command   => "$installed/lib/ant/bin/ant -f setup.xml;
$installed/setup_glassfish_for_pulse.sh",
    user      => pulse,
    group     => pulse,
    creates   => "$installed/domains",
    require   => [File["/opt/glassfish/setup.xml"],
File["/opt/glassfish/setup_glassfish.sh"]],
    logoutput => true,
  }

Essentially we''ve scripted the standard install and then have a script
full
of asadmin commands to configure Glassfish specific to our
needs/environment.  Really this should all be done by managing the
domain.xml which we''ve templatized now that we''re getting more
comfortable
with Puppet.  But even managing the domain.xml is proving to be difficult
because of how Glassfish reads and writes the domain.xml file on start and
stop.

I''m beginning to feel a custom resource is the way to go as well but
there
are enough things about Glassfish which we find annoying that we might move
away from it rather than do that work.  If anyone else is starting to delve
into it though I''d be up for sharing our experiences and do what we can
to
help it come into being.

thanks,
chuck

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