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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 months
Container Tests
by Matt Wringe
Currently we are not doing any tests for the Hawkular Metrics docker
images and kubernetes configurations. This is something we really need
to address.
We are currently using Travis which doesn't provide a nice solution for
this space. Fabric8 has a good setup for testing kubernetes components
with their Continuous Delivery suite (which uses Jenkins), but requires
a machine to be setup running docker (+ OpenShift) to deploy its suite
of docker images.
With a fabric8 continuous delivery setup, we can also remove the docker
hub automated builds and build them as part of maven build. This would
allow us to:
1) only publish docker images if the test suites pass on them (with
docker hub we would have to publish the images first and then run tests).
2) to manage all the code in one spot without having to modify it in
multiple locations (currently its managed in 3 different github repos
which need to be synced together).
3) have a lot more control over images and how they are tagged.
Currently docker hub is restrictive in how we handle this.
[Note: we would still be publishing out images to docker hub for others
to consume, we would just be pushing the images that our test suite
builds rather than ones build in docker hub itself. It also means we can
publish to other repositories if we wish]
Anyone know if we have any machines available to setup an environment
for these types of tests?
We could move the container stuff out of Hawkular Metrics and into its
own git repository (which might make sense, since the Cassandra stuff is
not necessarily metrics specific). This would mean that we don't need to
move all the tests over to Jenkins and we could keep the current Metrics
tests in the same CI.
Or it could be configured to only build the docker images and not all of
Metrics (via profiles).
Anyone have any thoughts on this?
Thanks,
Matt
9 years, 6 months
