Building an RHQ client
by John Sanda
Last week I started building my own RHQ client. The docs say to get the
required libraries from the CLI distribution. If you are using maven or
another build tool that provides dependency management as I was, copying
the libraries from the CLI is not what you want. It took some effort to
get the dependencies that I needed sorted out. To alleviate this for
others, I pushed a new module into the master branch that takes care of
all the dependencies for you. The only dependency that you need to
declare is,
<dependency>
<groupId>org.rhq</groupId>
<artifactId>remote-client-deps</artifactId>
<version>4.0.0-SNAPSHOT</version>
<type>pom</type>
</dependency>
This will pull in all of the required RHQ dependencies. I wrote up a
blog post about this at
http://johnsanda.blogspot.com/2010/08/building-rhq-client.html that you
read if you want more details on what I ran into.
- John
13 years, 8 months
Resource Upgrade Attack Plan
by Lukas Krejci
So here are the results from the discussions about the resource upgrade and
how it should look in its first incarnation.
1) What we currently have in the resource-upgrade branch is mostly sufficient
for the most common (actually the only) use case we have right now - resource
key upgrade.
2) An upgrade error isn't considered fatal, it is assumed that plugin is
either programmed to handle multiple versions of resource data or that the
failure to upgrade isn't detrimental to the plugin functionality (too much).
3) An upgrade error is going to be merely reported using the resource errors
facility on the server side similarly to how
InvalidPluginConfigurationExceptions are/were reported (some kind of warning
icon and explanatory text).
4) Plugin versioning isn't crucial to get the useful version of resource
upgrade out because the need to upgrade should be usually determined from the
context (i.e. format of data, values of properties, etc.). If there are issues
found in the community that would require introducing this feature, we can
revisit it further down the line.
5) Configuration upgrade isn't crucial either (we have yet to find an issue
that wouldn't be solvable using our current features). Again if we find that
this feature would be needed, we can add it later.
6) Resource name and description upgrades are going to be switched off on the
server side with no GUI to enable this feature for now. Let's wait on the
feedback from community on the new resource names introduced in RHQ 3.0.0.
So in another words, we should be quite close to having resource upgrade
functionality in master :)
Thanks,
Lukas
13 years, 8 months
I18N for GWT
by Heiko W.Rupp
Hi Rafael,
Am 17.08.2010 um 01:30 schrieb Rafael Soares:
>> I brought the I18N work up once in
>> https://fedorahosted.org/pipermail/rhq-devel/2010-June/000172.html
>> Perhaps we need to re-visit that in the eye of GWT?
> Yes! Are you already using annotations on GWT branch for I18N? Or this issue still are in discussion?
To be honest I don't know - I've added the devel list on CC, so you could perhaps
discuss it there / get help from there.
Now is definitively a very good time to address this and also to supply some initial
I18N / translations on order to see how this turns out and to perhaps get more
people to help with translations.
Thanks
Heiko
--
Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei München
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera
13 years, 8 months
Configuration changes during resource upgrade
by Lukas Krejci
Hi,
this is another topic that I think might be useful for the resource upgrade
effort.
As it stands now (in the resource-upgrade branch), the resource upgrade
functionality can be used to change the resource key, name (and description)
of existing resources to conform with the new version of the plugin.
The code in the branch currently leaves the responsibility of determining what
version of the plugin to upgrade from and to up to the plugin developer and my
previous email tried to detail some of the complexities we might hit
implementing the support for such information.
Another area that I think would be useful for the plugin developers is the
support for configuration upgrades.
Currently we mandate the plugin and resource configurations to remain
backwards compatible. When a new version of a resource type is being
persisted, the structural changes to the configuration definitions are
reflected in the database. The values of new properties are initialized using
the values hardcoded in the plugin descriptor.
This is obviously not optimal because the plugin developer has no ability to
influence the values for individual resources (no way of initializing property
lists with runtime detected values, no "smart" initialization of property
values by actually looking at the managed resources, etc.), just the hardcoded
defaults from the plugin descriptor.
Another problem that needs to be considered is the display of the
configuration updates history. Currently we only ever store 1 "copy" of the
configuration definitions and use it to "parse" the individual configuration
updates. That is OK, because as mentioned earlier the configuration
definitions are assumed to be backwards compatible. If we allow the plugin to
perform more complicated structural changes, this might not be the case
anymore.
So here's a first draft of the approach we could take to lift the backwards-
compatibility restriction and to enable the plugins to take part in the
configuration upgrades.
1) When importing a plugin, we don't just merge in the changes to the
configuration definitions, but we actually create whole new versions of them
and make them the "current" ones by referencing the new config. def. versions
from the resource type.
2) Make configuration upgrades reference not only the configuration objects
but also the corresponding configuration definitions. With 1) this will make
the historical entries use the correct config. definitions at a cost of one
additional foreign key in RHQ_CONFIG_UPDATE table.
3) Allow plugins to upgrade the resource and plugin configurations during the
normal upgrade workflow (by simply adding them as properties of the
ResourceUpgradeRequest).
4) On merging the upgrade requests on the server side, create new entries in
the config update tables for each plugin-driven upgrade.
The problem that I can see with this is the following scenario:
1) Both server and agent are running
2) RHQ admin updates a plugin on the server => the new config defs are
persisted and referenced from the resource types
3) User edits a configuration of some resource (using the new config defs)
4) the update is sent to the agent
5) agent is still using the old plugins
This problem could be solved by somehow postponing the the "switch" to the new
config defs of the resource types on the server side to the post-upgrade time,
but that's quite hard, because different agents will upgrade at different
times and so we had to keep 2 versions of a resource type (or at least 2
versions of the config defs) "active" in the inventory until all the agents
upgraded to the latest version of the plugins.
Now the questions :)
- Do you consider configuration upgrades important / useful (I do because of
the above mentioned reasons)?
- What do you say about the approach and the problems outlined above?
Thanks,
Lukas
13 years, 8 months
Plugin versioning for resource upgrade
by Lukas Krejci
Hi team,
This is to reignite the discussions we had before RHQ 3.0.0 release about the
proposed resource upgrade functionality. To refresh your memory, please read
through http://www.rhq-project.org/display/RHQ/Design+-+Resource+Upgrade that
I updated to reflect the latest state of affairs.
If you remember the discussions we had before the 3.0.0 release, we agreed
that it would be good to provide version information to the upgrade methods
for individual resource types, so that it can be determined from what version
a resource is being upgraded to what version (a version being the plugin
version for simplicity). Now that the time pressure isn't that high, I think
it is a good time to start the discussion about this aspect of resource
upgrade so that it could be present in the next release.
Thinking about this today I found the implementation is going to be trickier
than I thought.
Originally I thought of this work-flow: When the agent receives the updated
plugins, it can determine what the two versions are and pass it down to the
plugin container so that it can then pass it down to the individual upgrade
methods. Done.
But what happens if the upgrade fails for some reason (bug in the upgrade()
method for example)?
Let me offer you some alternative ways of handling this on which I'll show
some of the problems that we'll have to deal with:
0) Just ignore the failure. If the plugin fails to upgrade a resource, tough
for it.
1) Upgrade failure = reject all the plugins and keep using the old versions.
This is obviously the easiest to implement but it just feels wrong. On upgrade
failure, we'd shutdown the PC without persisting the state and start it again
with the last known good state and old plugins. The server side would have to
be enhanced to tell the user what agent uses what version of the plugins and
why.
2) Upgrade failure = reject just the plugins from which the failing resources
come from.
Slightly better functionality wise, but this would mean that that we'd have to
perform some kind of partial revert of the resource contexts for the resources
that succeeded the upgrade but would come from the rogue plugins. Also, if
there are plugins dependent on the failed plugins we'd have to roll them back
(or rather their resources), too, because their new version might be
incompatible with the old version of the failed plugins. The server side would
like to know about this as well.
3) Upgrade failure = use the old plugins only for the failed resources, new
plugins for the upgraded resources.
The best functionality wise, but the bad points from above still apply.
Additionally, for this strategy we'd have to store the information on what
resource should use what plugin, but that's something we can't do on the agent
side because we have no authoritative store of information on the agent. The
info would have to be stored on the server side (we can store the plugin
version either at the resource, the resource type or create a new plugin
entity. I'm not sure about the effect of the latter two approaches because
because they would basically mean that we'd have more than one resource type
with the same name and plugin).
4) Demand that the plugins can handle resources of multiple versions.
That's fine, but then the plugins would need to know what version of the data
they are dealing with. Which brings us back to the problem of the server-side
storage.
5) Blacklist the resources that fail to upgrade. This is actually very similar
to 3 and 4, only rids the PC from running multiple version of the same plugin
or the plugin having to handle multiple versions of the resource data. The
server side storage might be slightly simpler than in the above 2 cases,
because we'd only need to store the "last known good plugin version" for the
blacklisted resources so that we can pass that info to the upgrade when the
plugins get updated next time.
I just can't make my mind up to pick one, the only ones I don't like from any
POV is (0,) 1 and 4.
What are your thoughts?
Thanks,
Lukas
13 years, 8 months
upgrading from postgresql 8.3 to 8.4
by John Sanda
I thought I'd pass this info along in case anyone else runs into this. I
had a fedora 11 box with postgresql 8.3 installed. I upgraded the
machine to fedora 12 which in turn upgraded to postgresql 8.4. I
discovered though that my postgresql 8.4 installation was more or less
broken. I could not start my database server. So I uninstalled and
reinstalled postgresql. Running service postgresql initdb failed though.
The postgres logs said reported
The program "postgres" is needed by initdb but was not found
When I logged in as my postgres user, I got this message,
-bash: /dev/null: Permission denied
Not sure how it happened but only root had write perms on /dev/null.
After I did chmod go+w /dev/null I was able to successfully run initdb.
- John
13 years, 8 months
Change in UI tech - GWT is now default
by Heiko W.Rupp
As you know we are migrating the whole UI over to GWT and will (try to) get rid of Struts/JSF :
Anfang der weitergeleiteten E-Mail:
> Von: Ian Springer <ian.springer(a)redhat.com>
>
> Fyi, as of today, if you go to http://localhost:7080/, you'll end up at coregui.war, rather than portal.war. If you need to get back to JSF land, manually go to the URL http://localhost:7080/Dashboard.do. This is also the case if you build master HEAD locally.
>
--
Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei München
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera
13 years, 8 months
Heads up: Git cleanup
by Heiko W.Rupp
Anfang der weitergeleiteten E-Mail:
> Von: Jay Shaughnessy <jshaughn(a)redhat.com>
> Datum: 6. August 2010 17:44:29 MESZ
>
>
> I've performed some git cleanup of unnecessary branches and tags generated during our 3.0/2.4 project/product pushes. To ensure your local environment is up to date with origin, from your Master tracking branch you can execute:
>
> > git remote prune origin
>
--
Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei München
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera
13 years, 8 months
The backend data source is unavailable
by kaoula ammar
hi, when i try to ""log in"" in the RHQSERVER it say The backend data source
is unavailable,
HOw can i solve that
________________________________
De : John Mazzitelli <mazz(a)redhat.com>
À : rhq-devel(a)lists.fedorahosted.org
Envoyé le : Ven 6 août 2010, 19h 45min 59s
Objet : getting rid of commons logging
We should consider doing this. commons-logging has those classloader
leaks problems that we've seen and tried to fix.
-------- Original Message --------
I would strongly recommend that you remove all JCL JARs from your project.
Instead of doing this:
slf4j -> commons-logging -> whatever
do this:
jcl-over-slf4j.jar -> slf4j -> whatever
This would pretty much eliminate your leaking issues. So far this
approach seems to work well for AS6.
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-devel
13 years, 8 months
getting rid of commons logging
by John Mazzitelli
We should consider doing this. commons-logging has those classloader
leaks problems that we've seen and tried to fix.
-------- Original Message --------
I would strongly recommend that you remove all JCL JARs from your project.
Instead of doing this:
slf4j -> commons-logging -> whatever
do this:
jcl-over-slf4j.jar -> slf4j -> whatever
This would pretty much eliminate your leaking issues. So far this
approach seems to work well for AS6.
13 years, 8 months