March 2015 - hawkular-dev - Jboss List Archives

by Lukas Krejci

Hey, this is just to inform you that we finally merged the "future" branch of inventory into the master. This doesn't actually change anything for people that used to depend on the old 1.0.0-SNAPSHOT builds of inventory. Those are still available in repositories and will not change. The merged code changed version to 0.0.1-SNAPSHOT. What this means is that once the integration with the "new" inventory is ready, you can just swap the version of inventory from 1.0.0-SNAPSHOT to 0.0.1-SNAPSHOT (or whatever version it will at the time) and you will be using the new stuff. Why we rolled the version back? Because we want to follow the semantic versioning and starting at 1.0.0- SNAPSHOT didn't give us much room to "breathe". Having a 0.y.z versioning scheme enables us to introduce incompatible changes yet allow people to still depend on the older versions if they are not ready to move. We also didn't want to release "timed snapshots" of 1.0.0. This is more a matter of personal taste, but I'd rather depend on 0.2.3 than on 1.0.0-20150314-5. While timed snapshots would give us the same benefits as 0.y.z versioning, we chose the subjectively better readability of 0.y.z over timed snapshots. If you ever wanted to look at the code as it existed prior to the big merge, the github repo has the "mvp-poc" tag that points to the last version of the "old" inventory code. Thanks, Lukas

10 years, 10 months

1
0
0 / 0

Changes in upcoming Hawkular Parent v10

by Peter Palaga

Ladies and Gentlemen, * Jirka added swagger plugin https://github.com/hawkular/hawkular-parent-pom/blob/master/pom.xml#L261 * Jirka also added two artifacts to dependencyManagement that are supposed to be used together with swagger plugin: https://github.com/hawkular/hawkular-parent-pom/blob/master/pom.xml#L185-... * My PRs https://github.com/hawkular/hawkular-build-tools/pull/13 and https://github.com/hawkular/hawkular-parent-pom/pull/19 are waiting for review. They upgrade license plugin to the last version 2.10. The most important change for all of you is <license.failIfUnknown>true</license.failIfUnknown> [1] which causes the license verification to fail if the plugin sees a file that is neither ignored or has a license style definition. The motivation for this is, clearly, that we want to have 100% certainty that all files have proper headers. See here how to ignore files in your project: https://github.com/ppalaga/hawkular-alerts/commit/afa2b9e4839a64150c3449d... The style definitions are done per file extension. Many file types are supported out of the box by the plugin (see [2]) and such a definition can be made ad hoc, too. We had such ones for .ts and .mustache in build tools [3], but they were recently accepted in upstream. Feel free to ask me if you need to cover some new file type. I'd release Parent v10 just after merging the above two PRs unless anybody has some urgent topic for the next Parent. Best, Peter [1] https://github.com/hawkular/hawkular-parent-pom/commit/4f16fc75bd8105858a... [2] https://github.com/mycila/license-maven-plugin/blob/master/license-maven-... [3] https://github.com/hawkular/hawkular-build-tools/commit/510aebe891fdfedb1...

10 years, 10 months

1
1
0 / 0

Breaking (REST-) api changes

by Heiko W.Rupp

Hello, please if you can't resist making breaking changes in (REST) apis, at least announce them here. There are clients / consumers out there that may need to change. There may be easy cases like the consumer is in one of our repos. Or it may be somewhere totally different.

10 years, 10 months

1
0
0 / 0

generation of message POJOs via JSON schema

by John Mazzitelli

There is this really nice maven plugin that takes JSON schema and generates Java POJOs annotated with GSON annotations. I took this stuff and created a sample module in the bus repo and see how it works. It works very nicely and I think we can use this very easily in our stuff. First, here is a site that discusses JSON schema if you aren't familiar (its essentially like XML Schema only for JSON): http://json-schema.org/documentation.html We can use this maven plugin to generate an API that our Java components can use to talk to each other. To see what the generated code looks like with any JSON schema, here's a play area where you can see it in realtime: http://www.jsonschema2pojo.org/ Here's what my sample JSON schema looks like (you'll see it uses primitives as well as sets/lists and embedded types (see address type) and a set of embedded types (see phoneNumbers): https://github.com/hawkular/hawkular-bus/blob/master/hawkular-bus-samples... Here is where my test code creates the message via the POJO API that was generated by the maven plugin: https://github.com/hawkular/hawkular-bus/blob/master/hawkular-bus-samples... If we use this stuff, we write the JSON schema which automatically provides documentation that non-Java clients can use to know what the clients need to send/consume, or they can use the schema themselves to generate their own client code. We use the schema internally to generate Java POJOs that we then use in our Java components (like what my sample code demonstrates). Here is what the maven plugin usage looks like - its pretty simple: https://github.com/hawkular/hawkular-bus/blob/master/hawkular-bus-samples...

10 years, 10 months

7
9
0 / 0

[metrics] aggregate metrics

by John Sanda

I have written up a short document[1] on initial support for aggregate metrics. Thanks in advance for any feedback. [1] http://bit.ly/1BAfF8d <http://bit.ly/1BAfF8d> - John

10 years, 10 months

1
0
0 / 0

Inventory browsing UXD

by Thomas Heute

We want to shift focus away from the "infrastructure focused" view to "application focused" view. In that sense we'd rather traverse resources by relationships rather than plain parent/child like in RHQ. The starting point should be an "application" a logical piece for the user. His Intranet, his e-commerce website, his b2b backend... (In fact I think we should let the user pinpoint the resource of his choice as starting points but if we can do for an "Application" we can easily do for a host or a server) (We'll fine-tune the notion of "application", OpenShift also has a related notion) IMO an application is just a "virtual" resource with a collection of resources and some metadata, for instance a load balancer + EAP domain (and its EAP servers) + Database. That resource will have a KPI associated with it and other information. It could also just be an "ear" file. In terms of visualization, we would certainly like to see those 3 pieces (in that simple example) and be able to "zoom in" into one of them (to configure the load balancer), to see database metrics or to see the EAP servers and domain controller that forms the EAP domain. The user should also be able to "zoom out", from a deployed ear to the EAP domain it's deployed on... The user should also be able to look at the infrastructure (is EAP in some docker container ? how is the CPU/memory ?) We'll also want to reflect health in those relationship, if my database is down, my "application" should reflect this. It's going to be a challenge to get this right, with the right level of granularity/detail, but the user experience should be much better in most common situations. For this we also need a good understanding of the relationship between all the resources, it should be mostly automated. Thomas

10 years, 10 months

1
0
0 / 0

Default user is (almost) there!

by Juraci Paixão Kröhling

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All, Once the PR #50 [1] is merged, there will be a new Keycloak realm available for dev builds, shipping with an user and without passwords restrictions. The username is "jdoe" and the password is "password". This will automatically be available if you build Kettle with the "dev" maven profile (hint: check your settings.xml). For production builds (ie: without the "dev" profile active), there's no such user and there are password restrictions inline with the rules from Wildfly. 1 - https://github.com/hawkular/hawkular/pull/50 - - Juca. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVCF5LAAoJECKM1e+fkPrXsjgH/joCvprBiyx3CYdH9aR2WdA2 kAvi8KL+qn+fJYyhC0jKv6cVph85rffe3upu1LsqI07o/8ltxCGbPQofbYyKrOGS mz6EtbZ8o1L6m3W+39SPBXJv0AYgeVuZq0f1zHVNIR0WwHny5+aos39G9At0R/eN OykDKwocufK/O3NMxtLfS9Ra+WXtEzZX5DrhuWjQ2JCtbi1KVfZ8IQD4uG9jm9pD QVRpVlPC/Ps9ZiH0CBKWFgBvBvFq4sftNB8Ix0XbYpp+2EHWCf/loqhyEJuWZLmL TvpyLbcsPCiMeJY0yTVIcuErz2/i33+HvgFPGBq+9if44OmFBs7YIpsaAXWlXXM= =SjPg -----END PGP SIGNATURE-----

10 years, 10 months

1
0
0 / 0

Fwd: Introducing 'osc login'

by Heiko W.Rupp

Could this "osc login" flow serve as a blueprint for us when configuring external feeds? Like providing such a tool and then some "base classes" (*) that the feed can use to read the data? *) This of course depends on programming language etc. Forwarded message: > From: Luke Meyer <lmeyer(a)redhat.com> > To: Fabiano Franz <ffranz(a)redhat.com> > Cc: Openshift Dev <dev(a)lists.openshift.redhat.com> > Subject: Re: Introducing 'osc login' > Date: Tue, 17 Mar 2015 00:14:44 -0400 (EDT) > > *cheers* \o/ > > The users (and their administrators) will thank you! > > ----- Original Message ----- > From: "Fabiano Franz" <ffranz(a)redhat.com> > To: "Openshift Dev" <dev(a)lists.openshift.redhat.com> > Sent: Monday, March 16, 2015 6:07:14 PM > Subject: Introducing 'osc login' > > The 'osc login' command were merged[1] earlier today featuring a lot > of improvements in terms of usability for users of the OpenShift v3 > command line tools. > > This new command is intended to be the "entry point" for first-time > users, featuring not only the negotiation of a session token with the > OpenShift server, but also an interactive setup flow for configuring > the command line tools. Basically when running 'osc login', users will > be presented to an interactive process that will ask a few questions > (server URL, credentials, etc) and in the end will *automatically > save* a config file compliant with .kubeconfig that will later be used > by every subsequent command. > > Were also added OpenShift-specific ways for providing a config file: > the path to a config can now be provided by either the --config flag, > OPENSHIFTCONFIG env var, ~/.config/openshift/.config file or > .openshiftconfig file in the current directory (some of these path > names are still under discussion). > > Notice that a couple things that were originally part of this pull > request, like user-friendly messages with colors, were not merged and > will be in forthcoming improvements. > > Finally, the package also introduces the 'osc project' command that > can be used to either display the project currently in use or switch > to another project, through 'osc project <project-name>'. > > End-user docs will follow. Please let us know if you have comments or > suggestions. > > Fabiano Franz > > [1] https://github.com/openshift/origin/pull/992 > > _______________________________________________ > dev mailing list > dev(a)lists.openshift.redhat.com > http://lists.openshift.redhat.com/openshiftmm/listinfo/dev > > _______________________________________________ > dev mailing list > dev(a)lists.openshift.redhat.com > http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

10 years, 10 months

2
1
0 / 0

Stuff to share? Blog about it

by Heiko W.Rupp

Hey, if you have stuff to share like - a new release of metrics - a new subsystem / component - some cool way of doing stuff - clever way to test the combination of collected, ptrans and hawkular-metrics? Then please write a blog entry for hawkular.org You do that by adding a new adoc file with your blog content to https://github.com/hawkular/hawkular.github.io/tree/pages/src/main/jbake/... After this is merged in master, it will become live on http://www.hawkular.org/blog.html The blog post itself should have headers like this: = The Kettle starts boiling (1) Heiko W. Rupp (2) 2015-02-24 (3) :jbake-type: post (4) :jbake-status: published (5) :jbake-tags: blog, kettle, integration (6) 1) subject line 2) author name 3) post date 4) type post - should be fixed 5) status - could be draft (I think) or published as seen There are already existing posts that can serve a example.

10 years, 10 months

1
0
0 / 0

Inventory to break its REST API

by Lukas Krejci

Hi, the time has come to merge the "future" branch of inventory to its master so that we don't prolong the schizophrenic situation of the component. Because that merge will break the REST API, we need to sort out the recent discussion about how to handle the breaking changes in the builds. There were 2 proposals: [ ] adopt 0.x.y versioning or some such so that we can actually increase a version with breaking changes *, or [ ] release timed snapshots and depend on them rather then simple -SNAPSHOT. Please vote or propose other solutions so that we can move forward and not piss off whole nations.. Cheers, Lukas * semver allows 0.x to do breaking changes without increasing the major version, because leading zero means "before the first stable release"

10 years, 10 months

5
7
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

hawkular-dev March 2015