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
11 years
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
>
11 years
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
11 years
[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...
11 years
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
11 years
Fwd: [wildfly-dev] Wildfly start-up as service script depends on console log to determinate start result
by Heiko W.Rupp
This sounds interesting as it would also be
something like our computed resource state
with some simple form of "alerting" behind it.
Forwarded message:
> From: David M. Lloyd <david.lloyd(a)redhat.com>
> To: wildfly-dev(a)lists.jboss.org
> Subject: Re: [wildfly-dev] Wildfly start-up as service script depends
> on console log to determinate start result
> Date: Fri, 12 Jun 2015 07:57:25 -0500
>
> This is yet another good use case for an idea I proposed at the last
> couple developer meeting: the idea of configurable "availability"
> services, where you add a configuration which says "when these
> components and/or configured services are available, perform this
> action" where the action might be to notify a load balancer, perform a
> notification to humans, or even drop a file to the filesystem (which
> would be directly useful to this use case).
>
> Note (in case someone thinks this is a great idea and runs out to
> implement it right away) that when I say "configured services" I do
> not
> mean MSC service names; more like management capabilities where you
> have
> a constrained namespace and each subsystem can contribute services to
> this category.
>
> Also note that Java 9 adds limited support for signalling unrelated
> processes, though at the moment on UNIX the signals are basically
> limited to TERM and KILL.
>
> On 06/12/2015 07:06 AM, Jason T. Greene wrote:
>>
>>> On Jun 10, 2015, at 11:46 AM, Brian Stansberry
>>> <brian.stansberry(a)redhat.com> wrote:
>>>
>>> So, what purpose is this fulfilling?
>>>
>>> 2) How does other software solve this problem? If it's solving a
>>> valid
>>> problem, it seems like there would be a typical solution.
>>
>> The classic UNIX solution is that the daemon forks and returns,
>> dropping a PID file of its child to disk, after it is done
>> initializing and exits with an error code when there is a problem.
>>
>> Systemd added other approaches, where a daemon can signal systemd
>> directly, or it can use dbus to send a message.
>>
>> The former can't be done efficiently in Java because it doesn't have
>> a pure fork(), only an exec. Although it would be possible to emulate
>> with an exec with an unacceptable hit to boot time. The latter
>> options are too Linux specific.
>>
>> I think the best solution would be for us to add a signaling
>> mechanism specifically for this purpose. We could use sun.misc.Signal
>> (potentially an issue on Java 9), or we could exec the kill command
>> to signal a process.
>>
>> We could also use a specially status file (e.g standalone.sh
>> --start-status-file=blah) for a script to monitor.
>>
>> Thoughts?
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
> --
> - DML
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
11 years
Cassandra changes
by John Sanda
Yesterday Stefan finished up the work to move the embedded Cassandra modules out of h-metrics and into h-commons. The version has also been upgraded to 2.1.5. This should not any affect any code. Lastly the driver is now in the parent pom and has also been upgraded to 2.1.6. My apologies for the late notice. In the future I will send out the info in advance of the changes.
Thanks
- John
11 years
i18n
by Thomas Heute
While we would like, we may not have full i18n by the time of the 1.0.0.GA.
That said, this needs to be taken into account now for some aspects as
we don't want to have to break API or even worse do some schema update
to enable i18n in a later version.
So please think of this when you deal with human-facing strings like
alert emails templates, some inventory or metrics metadata maybe ?
For the strings in the UI itself, I leave it to the developer, since we
do frequent changes in the UI it may be faster to deal with i18n at once
later.
For the strings that are directly taken from a component it would make
sense to raise a JIRA if that is not i18nized yet.
Thomas
11 years
