WF 9 upgrade
by Thomas Heute
We have to upgrade to WF9 to get more data out of WF9.
there are quite some changes to be made:
- Parent declares the version of WF to use and BOM:
here is my branch:
https://github.com/theute/hawkular-parent-pom/commits/HAWKULAR-244
- Accounts need to upgrade to KC 1.3 (to be released this week)
Juca will work on this
- Bus/Nest needs to adapt
here is my branch
https://github.com/theute/hawkular-bus/tree/HAWKULAR-232 (needs another
patch from Mazz)
- Agent also needs some changes.
WF 9 GA is supposed to go out at any point now, let's try to coordinate
around that, if you have a release pending, think of that.
BTW, I tried to reflect the dependencies between component, would have
been easier if everyone could respect our standards, in particular:
- declare all dependencies at the root pom
- use <version./groupid/> in pom properties.
So please fix this if you do not follow those basic rules.
PS: for the upstream project, it is ok if all dependencies don't fully
align, for instance 2 components could depend on 2 different versions of
the parent.
Thomas
9 years, 7 months
Fwd: [wildfly-dev] WildFly 10 Schedule
by Heiko W.Rupp
Forwarded message:
> From: Jason Greene <jason.greene(a)redhat.com>
> To: WildFly Developers <wildfly-dev(a)lists.jboss.org>
> Subject: [wildfly-dev] WildFly 10 Schedule
> Date: Wed, 17 Jun 2015 16:43:56 -0500
>
> In addition to the biweekly Alphas, the following are the key dates
> for the WildFly 10 schedule:
>
> WildFly 10 Beta1 - August, 6th
> WildFly 10 CR1 - September 9th
> WildFly 10 CR2 (if needed) - September 16th
> WildFly 10 Final - October 8th*
>
> All new feature development needs to be wrapped by August, and
> preferably most PRs already submitted in July.
>
> Happy Hacking!
>
> * As always, Final releases are contingent on the last CR being
> blocker-free. If we aren’t blocker free, we will introduce another
> CR
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
9 years, 7 months
Hawkular QA
by Heiko W.Rupp
Hey,
as I mentioned earlier today, QA is currently busy with "other things" :-)
and can't look after the Hawkular Jiras in Resolve state.
So in the best of Kanban we should chime in here and smoke
test items that are RESOLVED (QA Todo in the Kanban board),
so that they can be moved to the QA Done = Closed state
And as with Pull-Requests: Don't QA the things you implemented
yourself.
Heiko
9 years, 7 months
Tenant no longer in URL in the upcoming Inventory 0.1.0
by Lukas Krejci
Hi all,
I just wanted to let you know about the breaking change in the upcoming
Inventory 0.1.0.
Following the suite of metrics, inventory will no longer support the tenantID
in the URL and will solely rely on Hawkular accounts to hand it the tenantID
to use - i.e. it will be the tenant of the currently logged in user or of the
persona passed in using the "Hawkular-Persona" header.
Cheers,
Lukas
9 years, 7 months
Updated JIRA workflow for HAWKULAR
by Heiko W.Rupp
Hi,
the JIRA Workflow for HAWKULAR has been updated
to include UxD and also a "QA in Progress" state.
See attached screen shots.
For UxD there is now a nice "Start UxD" button to get going :->
Heiko
9 years, 7 months
Property passing into Hawkular(-metrics)
by Heiko W.Rupp
Hey,
currently one can pass properties/options like the C* to use
via -Dkey=value pairs to standalone.sh/bat
This is a bit cumbersome and also does not work in cases, where
the command line is set at "compile time" like in a Dockerfile,
but the property needs to be set at run time (when docker run
a pre-made image).
There would be the option to set JAVA_OPTS before starting
the script, but JAVA_OPTS is
a) something that may apply to multiple java programs on a machine
and is thus not specific
b) inside standalone.conf not additive, so one has to repeat all the
options from standalone.conf on JAVA_OPTS
So I propose hat we add (similar to RHQ) some HAWKULAR_OPTS
that are additive to JAVA_OPTS.
We need to modify standalone.sh/bat to source them (and keep the
modified versions in our git repo.
Alternatives could be
- create wrapper scripts that set JAVA_OPTS and call standalone.sh,
but that only indirectly solves [1]
- as the WildFly team to add some WF_LOCAL_OPTS in upcoming releases.
I fear that may take too long.
Opinions?
[1] https://issues.jboss.org/browse/HAWKULAR-288
9 years, 7 months
attribute names have a new rule in WF9
by John Mazzitelli
I didn't get any response in #wildfly, but I tested this and I found it to be true:
03:23:11 PM) mazz: I need a sanity check please. I'm trying to run unit tests on my module subsystem (via my subclass of org.jboss.as.subsystem.test.AbstractSubsystemBaseTest). My test DID work on WF8.2 but FAIL when I move to WF9 CR2.
(03:23:11 PM) mazz: The error is :
(03:23:11 PM) mazz: failure description: "WFLYCTL0201: Unknown attribute 'org'"
(03:23:11 PM) mazz: in my custom subsystem, I have several attributes of the form "org.abc.xyz" such as:
(03:23:11 PM) mazz: <element org.hawkular.package.name.foo="test1" org.hawkular.another.package.blah-blah="test2" />
(03:23:44 PM) mazz: could it be possible that attribute names can no longer have "." in their names?
(03:24:11 PM) mazz: I have no attributes called "org" but plenty that look like "org.some.name.here"
(03:47:24 PM) mazz: uh-oh. Yeah, I thikn that's a problem
(03:47:48 PM) mazz: in WildFly 9 CR2, it is no longer possible to have a dot (".") in attribute names.
(03:47:50 PM) mazz: This makes me sad
(03:48:06 PM) mazz: this was possible in WildFly 8.2.Final
(03:48:36 PM) mazz: I just changed all my "." to "-" in my custom module subsystem extension (in the java code and the .xml) and now my tests pass
(03:50:06 PM) mazz: I don't know if that is also true for element names.
(03:50:25 PM) mazz: I have "org.abc.xyz" element names as well. but the error message I got just mentioned attribute name
I suppose we could change these names so the "." is replaced with "-" (they are also sysprop names that are used to replace ${key} tokens in bus config files, so i used the standard "." notation for these names).
What should we do? Ask WF to fix this (it probably is a bug - I doubt they meant to make that change) or just deal with it and workaround by changing our attribute names?
9 years, 7 months
