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
8 years, 9 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
8 years, 9 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
8 years, 9 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?
8 years, 9 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
8 years, 9 months
Fwd: Streamlined "Start Progress" action in jboss.org JIRA
by Heiko W.Rupp
FYI ..
tl;dr : when starting to work on a JIRA, just click on the "Start
progress" button.
Forwarded message:
> From: Vlastimil Elias <velias(a)redhat.com>
> To: jboss-dev-all R&D <jboss-dev-all(a)redhat.com>
> Subject: Streamlined "Start Progress" action in jboss.org JIRA
> Date: Mon, 15 Jun 2015 12:51:38 +0200
>
> Hi,
>
> jboss.org JIRA server running at https://issues.jboss.orgprovides
> streamlined functionality of "Start Progress" action now, which is in
> align with latest JIRA default workflow.
>
> You had to manually assign issue to yourself to be able to perform
> "Start Progress" action before this change. Now, the "Start Progress"
> action is available to all Assignable users (potential developers).
> Status of the issue is changed and you are made issue's Assignee once
> you use it, so one less click is necessary and workflow is more user
> friendly.
>
> - See more at:
> https://developer.jboss.org/en/website/blog/2015/06/15/streamlined-start-...
> jboss.org JIRA server provides streamlined functionality of "Start
> Progress" action now, which is in align with latest JIRA default
> workflow.
>
> You had to manually assign issue to yourself to be able to perform
> "Start Progress" action before this change. Now, the "Start Progress"
> action is available to all Assignable users (potential developers).
> Status of the issue is changed and you are made issue's Assignee once
> you use it, so one less click is necessary and workflow is more user
> friendly.
>
> See more and discuss at
> https://developer.jboss.org/en/website/blog/2015/06/15/streamlined-start-...
>
> Enjoy
>
> Vlastimil
>
> --
> Vlastimil Elias
> Principal Software Engineer
> jboss.org Development Team
>
8 years, 9 months
Release Process - Hawkular Metrics + Components
by Stefan Negrea
Hello Everybody,
Had some great conversations and feedback this week about the release process for Hawkular Metrics. A few ideas emerged and this email is a summary of the process Hawkular Metrics will implement starting next release (expected as soon as next week).
Release Process:
1) Use semver as the versioning standard (http://semver.org/)
2) A scheduled release:
a) is a planned release, with a set of significant changes
b) is the next increment on MAJOR.MINOR version (eg: from 0.4.0 to 0.5.0)
c) gets a dedicated branch from master
d) gets tagged on the branch
e) gets full release notes, JIRA, email communication, blog
f) bits are published to JBoss Nexus and Github
3) A patch release
a) needed to address urgent bugs or regression between scheduled releases
b) is an increment in the PATCH version (eg. 0.4.2)
c) no dedicated branch, patches are applied to the branch of a 'scheduled release'
d) gets tagged on the working branch
e) no release notes, blog posts, or similar communication; the only official communication will be a list of JIRAs fixed
f) bits published to JBoss Nexus and Github
g) all the code fixes will be applied retroactively to master
Hawkular Metrics will keep 'scheduled releases' at roughly one a month. The 'patch releases' will be created on a need basis and only if there are JIRAs reported against the 'scheduled release' or 'patch release' that need to be addressed before the next 'scheduled release'. One goal with the patch releases is to avoid publish a huge number of them in a short amount of time (eg. 2 per day). This does not impact at all the release for SNAPSHOTS; they will continue to get published from the code in the master branch.
It would be great if all the projects converge on a similar process. I recognize that due to different maturity levels that might not be practical now for everybody, but it would be huge win for the entire Hawkular to make even small steps in the same direction.
Thank you,
Stefan Negrea
Software Engineer
8 years, 9 months
[GSoC] Hawkular Android Client: Weekly Report #3
by Artur Dryomov
Hi everyone,
This year I am working on the Hawkular Android application as part of the
Google Summer of Code 2015 program.
I’ve spent the last week mostly on the Inventory-related expansion.
The application [1] was able to list only resource types a week ago. Today
it can list resources, metrics and metric data chart is coming soon [2].
The chart itself is not very universal at this point — there is no range
selection and it is pretty useless for HTTP status codes for example. But
hopefully with upcoming Metrics version it will change for the best. With
the help of Peter Palaga we got a proper Checkstyle and License checks
hooked up to Travis, which is very useful [3]. We also moved the GitHub
project from “hawkular/android-client” to
“hawkular/hawkular-android-client” for consistency.
This week I would like to work on Alerts. This will include a simple
listing with resolve ability and push notifications as well. Some work was
already done regarding the push area [4]. I haven’t found the source code
for the Hawkugear experimental application. Is it possible to get it
somewhere? Probably I’m looking for Thomas Segismont who is the author of
the original post. Anyway — ping me if you have it :-)
Have a nice week!
Artur.
[1]: https://github.com/hawkular/hawkular-android-client
[2]: https://github.com/hawkular/hawkular-android-client/pull/12
[3]: https://github.com/hawkular/hawkular-android-client/pull/8
[4]:
http://www.hawkular.org/blog/2015/04/09/alert-notifiers-for-mobile-device...
8 years, 9 months
Alert email templates
by Lucas Ponce
Hello,
In hawkular-alerts, the "plugins" are responsible to "deliver" the alert information into different ways, for example, an email, mobile, snmp or whatever plugable architecture.
The email is the main plugin configured in hawkular and today is very simple, it just have the basic architecture to receive the message and send a simple message.
We are working to improve this architecture so the plugins will receive the full alert content and it will process it to writte a formatted message.
The requeriments would be that a plugin can have a "default" template that can combine alert data to process a final email before to send.
But the plugin can be configure to have several templates, for example, by tenant, localization (i18n), or even destination (for example, the email for technical recipients would be more verbose than for a CTO).
So, the requeriments where I'm working on are the following:
- Default template (if no one exists).
- Add new templates dynamically to be used by tenant, localization (i18n) or destination.
- Plain / HTML formats.
I'm working for these requeriments for M2, but I would like to share these ideas to see if we are not missing anything important and we are in the same page.
Also it can be interesting if we can have some idea for the template (plain text and html - if needed- ).
Thanks,
Lucas
8 years, 9 months