System requirement for hawkular server
by Austin Kuo
Hi all,
When I was trying to running the server on my VM (2G memory), it shows
```
…
java.lang.OutOfMemoryError
Java HotSpot(TM) 64-Bit Server VM warning: INFO:
os::commit_memory(0x00007f4d913cc000, 12288, 0) failed; error='Cannot
allocate memory' (errno=12)
```
Wondering how much memory & CPU is sufficient for it?
Thanks!
8 years, 7 months
How to gradually remove unfitting old REST APIs?
by Lukas Krejci
This stems from the mention of deprecating the REST API of inventory and
making the new API the default one, forcing the existing clients to change.
I think this is a generic problem with the "emergent design" of iterative
development - sometimes the stuff you come up with turns out to be wrong and
you need to toss it away. At the same time, we need to minimize the "damage"
we do to the existing clients.
Let me just copy the relevant parts from the other thread and answer them
inline:
> > In 0.17.0.Final we will introduce a new REST API and will deprecate the
> > current one (most probably by moving it to
> > /hawkular/inventory/deprecated).
>
> This way you break all existing clients !
>
I know... At the same time Inventory is still not stable, it's 0.x.y, and the
current REST API really is broken in some ways.
I'd rather encourage clients to move away from it than keep it forever.
> You may either move the new api to a new prefix
I want the new API to be the default when inventory goes stable.
> Or use content negotiation where the new api gets a content of e.g.
> application/hawkular-inventory+json;v2
Again, I don't want to keep the old stuff around when inventory goes stable.
So having the new stuff as a v2 doesn't really make sense when v1 is going
away and will not be available in the future.
> A request without that content type gets the old endpoints and
> semantics.
> A request with that content type in the request will access the
> new endpoints (which may be separate or overlay the old ones)
> with potentially new data formats.
>
> This way clients can upgrade as they want
Content negotiation or new root context for the new API is certainly the clean
solution here, I can't argue that. It requires no change on the clients that
want to keep using the old API.
But I really want to prod the clients to upgrade, because I don't intend to
maintain the old API moving forward. So the "solution" is to actually MOVE the
old API to a new context root "/deprecated" (and I don't say it is the ideal
one and I am open to be persuaded to use another).
This will have 2 consequences:
* if you want to keep using the old API, update your client to use the new
context root. This usually should be as simple as changing a constant in the
client with the new context root. After this change, the clients are free to
upgrade as they want.
* the new REST API remains "clean" - no need to specifically ask for it.
There are other options:
* When the old API is called, "compute" the new URI (if possible) and return
301. According to the spec, the clients should "relink" and use the new URI in
the future. The drawback here is that IMHO this is messy for the clients -
they don't have an idea WHY is this being done, nor are they explicitly told
about the new capabilities of the new API. Additionally, this can only work if
the old and new URIs are "mappable" and the actual content format doesn't
change.
* Add a Warning: 299 - "Deprecated. Consider upgrading to new API." header
(https://tools.ietf.org/html/rfc7234#section-5.5). If the clients look at the
response headers, this gives them the information about the deprecation. Con -
this might be missed by the clients.
--
Lukas Krejci
8 years, 7 months
the new hawkular services distro
by John Mazzitelli
I am playing with the new hawkular services distro to see if it can get me moving again with the "no more accounts, need to pass tenant header" stuff:
https://github.com/hawkular/hawkular-services/pull/1
Has anyone played with this? It appears there is no default user created so that means this isn't a fully working distro yet - at least you can't unzip, run, and expect things to work.
There doesn't exist a -Pdev profile that you can use to build a distro for demo and developer purposes (like our old kettle builds, -Pdev would give you a jdoe:password user to play with).
Am I missing something or is this just not fully cooked yet?
8 years, 7 months
Hawkular Inventory 0.16.0.Final Released
by Lukas Krejci
Hi all,
I'm happy to announce the release of Hawkular Inventory 0.16.0.Final.
The most important change in this release is the alignment of authorization
and tenant selection with the rest of the Hawkular components.
>From now on, Inventory no longer depends on Keycloak for authentication and
instead is using JAAS. Any authenticated user is allowed to do anything by
default.
The tenant is no longer deduced from the authenticated user but is selected
using the Hawkular-Tenant header (which is therefore required in every request
to inventory).
This moves inventory more into a role of a "backend service" which delegates
more granular authentication and authorization to the application layer above
inventory.
That said, the authorization logic has been factored out and made pluggable
and a mechanism to check per-entity CRUD privileges is still in place. We just
swapped the default implementation for a "permissive" one and changed the way
we figure out the tenant.
Apart from this big change, the following enhancements and fixes have been
included in the release:
* all internal properties, stored as "__foo" in the backend, are now available
for filtering as "foo".
* SwitchElementType filter has been "promoted" to the API so that it is usable
by the API clients.
* Hawkular Commons dependency has been updated to 0.7.2.Final
In 0.17.0.Final we will introduce a new REST API and will deprecate the
current one (most probably by moving it to /hawkular/inventory/deprecated).
This work is well underway but unfortunately didn't make it for 0.16.0.Final.
Huge thanks go out to Peter Palaga who did all the security related changes in
this release and Jirka Kremser who provided the generic mapping of internal
properties.
--
Lukas Krejci
8 years, 7 months
Building hawkular failed
by Austin Kuo
Hi guys,
I was trying to build the latest repo on master.
It complained that
```
[ERROR] import yargs from ‘yargs';
[ERROR] ^^^^^^
[ERROR]
[ERROR] SyntaxError: Unexpected reserved word
[ERROR] at exports.runInThisContext (vm.js:53:16)
[ERROR] at Module._compile (module.js:414:25)
[ERROR] at Object.Module._extensions..js (module.js:442:10)
[ERROR] at Module.load (module.js:356:32)
[ERROR] at Function.Module._load (module.js:311:12)
[ERROR] at Module.require (module.js:366:17)
[ERROR] at require (module.js:385:17)
[ERROR] at Liftoff.handleArguments
(/Users/akuo/Developer/hawkular/hawkular/console/target/gulp-build/node_modules/gulp/bin/gulp.js:116:3)
[ERROR] at Liftoff.<anonymous>
(/Users/akuo/Developer/hawkular/hawkular/console/target/gulp-build/node_modules/gulp/node_modules/liftoff/index.js:192:16)
[ERROR] at module.exports
(/Users/akuo/Developer/hawkular/hawkular/console/target/gulp-build/node_modules/gulp/node_modules/liftoff/node_modules/flagged-respawn/index.js:17:3)
```
…
[ERROR] Failed to execute goal
com.github.eirslett:frontend-maven-plugin:0.0.26:gulp (gulp build) on
project hawkular-console: Failed to run task: ‘gulp.js build --production
--no-color' failed. (error code 1) -> [Help 1]
Anyone knows how to fix this?
Thanks
8 years, 7 months
Do we still need the nest? Or: do we still need Wildfly Patching?
by Juraci Paixão Kröhling
Bringing a discussion from IRC to the mailing list: do we still need the
Nest? It seems that the only reason we need the Nest at this point is
that it provides Wildfly Patching support.
Considering that we'll ship an appliance and RPMs, do we still have the
requirement of supporting Wildfly Patching?
- Juca.
8 years, 7 months
documentation on new services stuff
by John Mazzitelli
I know juca and peter are working on getting the new hawkualr services distro repo built and working. It would be nice if, after its all done, that a brief email can be sent to explain how it is built and how it works. The feature pack stuff that is now all over the place could use a bit of explanation - its a mystery to most folks right now.
8 years, 7 months
Hawkular Alerting 1.1.0.Final Released
by Jay Shaughnessy
We're happy to announce version 1.1.0.Final of Hawkular Alerting!
Hawkular Alerting is an open source, scalable alerting and eventing tool
for monitoring your Data Center or anything else. Out of the box you get:
* A robust REST API
* Complex Alerting
* Powerful Event Handling
* Pluggable Action Handlers with many built-in (e-mail, SMS, etc)
* Alert Lifecycle (Ack, Resolved, etc)
* Flexible Deployment, either standalone or as part of Hawkular
* And Much More
What's new:
* Update Cassandra Support
o [HWKALERTS-142] - Upgrade to Cassandra 3.x
* Use Hawkular-Tenant HTTP Header in both Hawkular and Standalone
deployments
o [HWKALERTS-145] - Make hawkular profile independent of
Hawkular Accounts
* Improve Action validation
o [HWKALERTS-139] - Action creation should warn/fail on unknown
properties
o [HWKALERTS-140] - Validate actions definitions against plugins
deployed
o [HWKALERTS-141] - NPE when plugin is not present
o [HWKALERTS-137] - Get action plugin for unknown plugin should
return 404
o [HWKALERTS-138] - Action creation for unknown plugin should not
return 200
* Group Trigger Fixes
o [HWKALERTS-147] - Unable to delete member trigger
* Documentation Generation Fixes
o [HWKALERTS-143] - Swagger annotations broken
o [HWKALERTS-144] - REST API doc not properly rendered
Links:
* Jira release-notes
o https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12315924&versi...
* Hawkular
o http://www.hawkular.org/
* Hawkular Alerting
o http://www.hawkular.org/docs/dev/alerts.html
* Hawkular Alerting Rest API
o http://www.hawkular.org/docs/rest/rest-alerts.html
* GitHub
o https://github.com/hawkular/hawkular-alerts
* Examples
o https://github.com/hawkular/hawkular-alerts/tree/master/examples
Hawkular Alerts Team
Jay Shaughnessy (jshaughn(a)redhat.com)
Lucas Ponce (lponce(a)redhat.com)
8 years, 7 months
