Re: RHQ 4.6 released
by John Mazzitelli
The installer page you should read is this one:
https://docs.jboss.org/author/display/RHQ/Running+The+Installer
The one linked below is the design page - probably not the one users will want to refer to.
----- Original Message -----
> I am happy to announce the immediate availability of RHQ 4.6
>
> Features of this release are:
>
> • The internal app server is now JBossAS 7.1
> • GWT has been upgraded to version 2.5
> • There is a new installer (this has also changed since the 4.6
> alpha release)
> • The REST-Api has been enhanced
> • Korean translations have been added (contributed by SungUk Jeon)
> • Webservices have been removed
> • Building RHQ now requires Java7, but it will still run on Java6
>
> You can download the release from source forge [1].
>
> As mentioned above, the old installer is gone, so make sure to read
> the wiki document describing how to use the new installer [2].
>
> Maven artifacts are available from the JBoss Nexus repository and
> should soon also be available from Central.
>
> We also like to say thank you to our contributors for this release:
>
> • Jürgen Hoffmann
> • Richard Hensman
> • SungUk Jeon
>
> Heiko on behalf of the RHQ team
>
> 1] https://sourceforge.net/projects/rhq/files/rhq/rhq-4.6.0/
> 2]
> https://docs.jboss.org/author/display/RHQ/Installing+RHQ+on+JBossAS+7
>
>
> --
> Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,
> Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
> Handelsregister: Amtsgericht München HRB 153243
> Geschaeftsführer: Mark Hegarty, Charlie Peters, Michael Cunningham,
> Charles Cachera
>
>
11 years, 2 months
RHQ 4.6 released
by Heiko W.Rupp
I am happy to announce the immediate availability of RHQ 4.6
Features of this release are:
• The internal app server is now JBossAS 7.1
• GWT has been upgraded to version 2.5
• There is a new installer (this has also changed since the 4.6 alpha release)
• The REST-Api has been enhanced
• Korean translations have been added (contributed by SungUk Jeon)
• Webservices have been removed
• Building RHQ now requires Java7, but it will still run on Java6
You can download the release from source forge [1].
As mentioned above, the old installer is gone, so make sure to read the wiki document describing how to use the new installer [2].
Maven artifacts are available from the JBoss Nexus repository and should soon also be available from Central.
We also like to say thank you to our contributors for this release:
• Jürgen Hoffmann
• Richard Hensman
• SungUk Jeon
Heiko on behalf of the RHQ team
1] https://sourceforge.net/projects/rhq/files/rhq/rhq-4.6.0/
2] https://docs.jboss.org/author/display/RHQ/Installing+RHQ+on+JBossAS+7
--
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Mark Hegarty, Charlie Peters, Michael Cunningham, Charles Cachera
11 years, 2 months
RHQ on MySQL - Help needed
by Heiko W.Rupp
Hi all,
Changchung Hu and his team has developed support for RHQ on MySQL and needs your help going forward.
Please have a look at his post
https://community.jboss.org/message/799321#799321
There have been numerous requests for this in the past and it looks like together we could build on top of his
work and finally add MySQL to the RHQ backend databases.
Heiko
--
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Mark Hegarty, Charlie Peters, Michael Cunningham, Charles Cachera
11 years, 2 months
Avail runner not started?
by Heiko W.Rupp
Hi,
I've just started the agent for the rhq-master build from yesterday afternoon (~ 4pm my time)
It finds some resources, but stands there - it looks like the avail runner may never run, so that the children will
never be scanned for
> inventory
+ Resource[id=14041, uuid=8cbdd2ed-601a-4bbc-8bee-649abff6e5d7, type={Platforms}Mac OS X, key=snert, name=snert, parent=<null>, version=MacOSX 10.7.5] (sync=SYNCHRONIZED, state=STARTED, avail=UNKNOWN, sched=0/0)
+ Resource[id=14044, uuid=f31a653d-1b7a-4ef3-9558-018e53e199ea, type={Cron}Cron, key=Cron, name=Cron, parent=snert] (sync=SYNCHRONIZED, state=STOPPED, avail=UNKNOWN, sched=0/0)
+ Resource[id=14042, uuid=48c97db1-3205-41f9-a18b-1fa18b81ceed, type={JBossAS7}JBossAS7 Standalone Server, key=/tmp/rhq-server-4.6.0-SNAPSHOT/jbossas/standalone, name=AS (127.0.0.1:6990) RHQ Server, parent=snert] (sync=SYNCHRONIZED, state=STOPPED, avail=UNKNOWN, sched=0/0)
+ Resource[id=14045, uuid=396c773e-019e-4f4f-9e3f-6531a11ca3a0, type={Postfix}Postfix Server, key=/etc/postfix/main.cf, name=snert, parent=snert] (sync=SYNCHRONIZED, state=STOPPED, avail=UNKNOWN, sched=0/0)
+ Resource[id=14043, uuid=28bc1335-abc0-40d2-807f-97c278271a58, type={RHQAgent}RHQ Agent, key=snert RHQ Agent, name=RHQ Agent, parent=snert, version=4.6.0-SNAPSHOT] (sync=SYNCHRONIZED, state=STOPPED, avail=UNKNOWN, sched=0/0)
+ Resource[id=14046, uuid=745e0d68-d92c-4382-ba64-c38f12b3b59e, type={Samba}Samba Server, key=/etc/samba/smb.conf, name=snert, parent=snert] (sync=SYNCHRONIZED, state=STOPPED, avail=UNKNOWN, sched=0/0)
Total Resources: 6 (1 Platforms, 5 Servers, 0 Services)
Can someone else please test the latest master build for this?
Heiko
11 years, 2 months
Paging in the REST-api
by Heiko W.Rupp
Hi,
as I am implementing paging through (large) collections - e.g. lists of resources,
I am investigating options. For this I have written a blog post at
http://pilhuhn.blogspot.com/2013/02/best-practice-for-paging-in-restful-a...
My current tendency is to support the "Link: header" style and possibly
with the multiple Link: headers style
--
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Mark Hegarty, Charlie Peters, Michael Cunningham, Charles Cachera
11 years, 2 months
github migration
by John Sanda
Where do we stand with respect to the github migration? What outstanding tasks are left before we can pull the trigger? Given that we have various RHQ and JON releases in flight, when is the best time to make the move?
- John
11 years, 2 months
Bundles V2
by Jay Shaughnessy
Lukas,
(note: I wrote most of this before the presentation last Friday, so some
of it is answered or dated. Just posting it to get the thread moving...
-Jay)
Looking at the latest revision of the wiki. The design is progressing
well. I'm definitely liking the emphasis on migrating to a
Bundle-centric approach and the drive for simplifying the deployment and
storage models while also making things more robust. A couple of
questions/comments:
* The move to Repo-based content authz seems like a good idea that will
map well to the current Group-based resource authz. And therefore
should be easily adapted/understood by users (and us).
* I'm a little confused by the unique constraint on (Package.name,Repo)
where Package-Repo is ManyToMany. That would mean I could have
different distinct Packages with the same name, in different repos. But
I could also have the same Package in different Repos. How will I be
able to identify a test.war in different repos as being the same app, or
different apps with the same name? This does prevent two different
test.war apps in the same repo, which may make sense, but actually maybe
it's too restrictive.
Keeping this ManyToMany is probably a good idea as it is analogous to
the Resource-Group relationship wrt Repo-based authz. But then you may
need to keep and re-purpose Package.classification as something that can
further identify a Package. Name may not be enough. The same is true
of resources, to identify a resource you can't go by name, the
"classifier" is ancestry.
* +1 to removal of ContentSource, we'll need to work out the details of
the CSP feature
* +1 to removal of PackageCategory
* +1 to deprecation/removal of PackageType
* With respect to the PackageVersion changes:
** +1 to removing architecture. Does this mean we can also kill off
the rhq_architecture table?
** I get why you don't want displayName. But you may want to make this
a redundant, immutable field, set to the package name. Not sure, but it
may be helpful to not have to join with Package to get the name.
** +1 to removing displayVersion, not sure I see a reason for this, either.
** +1 to removing MD5 if we can. Maybe it was the only digest we could
get for certain remote content? I don't know.
** license_name, license_version? These aren't mentioned, can we get
rid of them?
* Mime types:
** +1 to the approach, I think this will be very good as the underlying
mechanism for moving the model forward.
** I'm not sure the mime-type determination approach can work like it
does for bundle types. It can only work if only one server plugin can
determine a mime-type, right? Is this going to be true? Maybe it is ,
I'm just asking.
* With respect to Content discovery, you say: "...The latter point is
useful for content discovered in the plugins using the Content API (that
don't end up in any repo), because it will allow for two
"mywebapp.war:1.0" to coexist in the database, each coming from
different resource". This content without a Repo, what is it "attached"
to? How is it tracked/removed/accessed?
* Bundle Consequences:
* We need better terminology for "normal bundle" and "content bundle".
I don't know what it should be but it should likely reflect that some
bundles are
file-system/generic/bundle-distribution-file-zip/bundle-plugin-deployed
and others are [mime-]typed/resource-type-plugin-deployed.
** I think I prefer just adding to the Configuration wrapped by the
existing ResourceTypeBundleConfiguration to absorb the <content> stuff.
As opposed to introducing BundleDestinationDefinition. It already
exists and Configuration is super-flexible for making additions. Or,
perhaps introduce a BundleDestinationDefinition pojo that can be
retrieved via ResourceTypeBundleConfiguration (like
getDestinationDefinitions()).
** The diagram indicated that the Bundle name is derived from package,
is that right?
** Overall I'm still absorbing the proposed changes here. The loss of
BundleType for a Bundle is something that makes sense given that the
Bundle will already have a mime-type.
* Can we simplify Repo stuff? Do we really need a Repo-Resource
relationship?
* Can we also eliminate all of the Advisory stuff?
11 years, 2 months