About agent preferences handling (was Re: reverting commit)

Thomas Segismont tsegismo at redhat.com
Tue Mar 26 23:15:57 UTC 2013


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 :)

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?

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

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

Regards,
Thomas


Le 26/03/2013 18:28, Elias Ross a écrit :
> I do have a couple of problems with the current setup and the new setup.
>
> Current setup:
> * Settings file are in a user's home directory ('rhq') whereas
> typically they should go into /etc on Linux.
> * Settings are in XML which is hard to update using scripts.
> * Settings that are per host (agent key) and standard across all
> installs are in one file.
> * It is very difficult to change the server hostname in an automated
> way (i.e. using Puppet). I have had to change many agent hosts (> 50)
> to connect to a new server at a new address. I resorted to changing
> XML using Augeas which is non-trivial to do.
>
> New setup: (as proposed):
> * Unclear how updates are done. I use RPM to install the agent, since
> I am using Puppet.
> * Unclear what problems are being fixed. Bugzilla doesn't reveal the
> issues to me; I assume they are protected.
> * It's a bad idea to store these sorts of settings in an application's
> working directory.
>
> Things I'd like to see:
> * Agent key is stored in a separate file. The reason is that across
> all instances I want to use the same properties file, and this is the
> only setting that is unique per host.
> * Settings are kept in plain text, like a properties file. This makes
> it easy to update using scripts.
> * Settings are in /etc. On Windows, I don't know what to suggest.
> * RPM for the Agent. Okay, separate issue. But makes it easier using
> Puppet to do the initial install via RPM. RPM should have an option
> for 'rhq' user install.
>
> On Tue, Mar 26, 2013 at 9:28 AM, John Mazzitelli <mazz at redhat.com> wrote:
>> [Ian - feel free to commit this back in a branch (not master) and create a BZ for this. We'll cherry pick in master at the appropriate time.]
>>
>> Its been requested that we revert commit df18b71df2d5114d9edc8a26ad42e0d7a9036eb2:
>>
>>      "do not pass not-yet-fully-initialized "this" reference to GroupOperationHistory.addResourceOperationHistory() in ResourceOperationHistory's constructor, as the GWT compiler fails when it sees this (at least in my OS X 10.7.5, Oracle JDK 1.7.0_17 environment)"
>>
>> We are reverting for a couple reasons:
>>
>>      * This broke a jenkins build - an API change has been introduced and it therefore fails the API check job. (I think its due to a change in a public domain object's constructor). Keep in mind that for awhile now we have a jenkins job that runs to make sure there are no backward compatible changes to public APIs - if it detects one, the build will fail. In this case, it appears a public domain object's constructor was changed thus breaking that API check.
>>
>>      * Also, There is no BZ for this - we don't know what this addressed. Please make sure BZs are written before committing bug fixes so they can be tracked appropriately.
>> _______________________________________________
>> rhq-devel mailing list
>> rhq-devel at lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>



More information about the rhq-devel mailing list