About agent preferences handling (was Re: reverting commit)

Elias Ross genman at noderunner.net
Wed Mar 27 07:20:21 UTC 2013


On Tue, Mar 26, 2013 at 4:15 PM, Thomas Segismont <tsegismo at redhat.com> wrote:
> Hi Elias,
>
> I changed the thread's subject as you are talking about agent preferences
> storage while Mazz is talking about reverting a commit which has nothing to
> do with this :)

Sorry.

>
> Agent key is not the only property that might change from one managed host
> to another. If in your RHQ deployment you only need to change this property,
> why just not write a templated preference file in your puppet module and get
> rid of your Augeas lens?

The problem is the agent key varies from host to host. If I could
export it for every host, then I suppose I could just do that. But
it's sort of a chicken-and-egg problem. The key is generated when the
installer runs. So that doesn't work.

> Using Puppet does not force you to use RPM to install the agent (while
> obviously this must simplify your Puppet module development)

I've done it using calls to Java. It's just too complicated this way
and error prone. RPMs are nicer, since you can customize a lot of the
config files that get installed without having to rebuild the install
package. For example, if you want to customize the memory use, or run
as 'rhq' user, how can your average user customize the package? How do
you uninstall the agent? How do you roll out customization changes
without reinstalling the whole agent? The current system works okay
for a few installs but not 100+.

You guys are RedHat so I'm not sure what the deal is with not using RPM here.

> I agree, Java preferences default back-end may be great for keeping state or
> *user* preferences for desktop applications, but not for holding
> configuration; especially daemon configuration. Jay's work on this BZ is a
> good step (keeping the preferences API which is better than using the
> Property class and change the back-end storage).

The files need to be in a better place, first of all. But even still
there needs to be some more thought.

For your curiosity, here's more or less how you update a preference
file in Puppet, say if the server alias changes:

    augeas { "agent" :
        lens    => "Xml.lns",
        incl    => "$h/.java/.userPrefs/rhq-agent/default/prefs.xml",
        changes => [
            "set
map/entry[#attribute/key='rhq.agent.server.alias']/#attribute/key
rhq.agent.server.alias",
            "set
map/entry[#attribute/key='rhq.agent.server.alias']/#attribute/value
${rhq::agent::server}",
            "set
map/entry[#attribute/key='rhq.agent.server.bind-address']/#attribute/key
rhq.agent.server.bind-address",
            "set
map/entry[#attribute/key='rhq.agent.server.bind-address']/#attribute/value
${rhq::agent::bind_address}",
        ],
        require => [ Package[$rhq::agent::p], File[$prefs] ],
        notify => Service[$rhq::agent::service],
    }

This is, well, not ideal. I'm 100% against XML and 100% against
putting in per-host configuration in one file. If you want a separate
XML file for just the agent key then I'm okay since I can use
templates for this file instead.


More information about the rhq-devel mailing list