Resourcetype again
by Heiko W.Rupp
Hey,
we have said that we do no longer want the very strict resource types
that
we had in RHQ. We also identified that we need resource types to define
capabilities like metric types with their units etc. The newest addition
now
are operations and resource config.
I believe that for a certain kind of resource - e.g. "WildFly 8.2", that
"we" manage
we should not have the agent/feed supply the types, but Hawkular should
do so.
A user may still decide to extend that to supply its own data, but we
need to be
careful when dealing with it.
For security relevant things we can not let the client/feed just provide
resource
type data, as otherwise it is too easy to work around checks.
For WildFly there are a bunch of RBAC roles [1,2] that need to map to
what
we (will) have in Hawkular, which we may define as just what WildFly
has.
In fact that will be beneficial, as users will already know how WildFly
RBAC works
and can apply it to Hawkular. Plus if the user already has its org
members in
a central KeyCloak with role mappings, we can hook up to that instance
and get the mappings "for free".
Now for operations on WildFly (not only the classic RHQ-operations, but
also modifying
resource config), RBAC in WildFly is "hiding" whole sub-trees, but also
(iiuc) individual attributes
if you do not have the right role:
role=SuperUser:
[standalone@localhost:9990 /] cd /core-service=management/access
[standalone@localhost:9990 access] ls
audit authorization
role=Monitor:
[standalone@localhost:9990 /] cd /core-service=management/access
[standalone@localhost:9990 access] ls
audit
With enough privileges it is possible to see the access definitions
under /core-service=management/access=authorization/constraint=*
While it is possible for WildFly to obtain the security levels
(automatically)
from the WildFly Metadata, we still need to find a good way to add this
information
into our resource types, as the UI may need to react to them and not
show a
restart button for user that only has the Monitoring role. In theory we
could
just issue the operation with the user perms and see it fail on WildFly
side, but that
is certainly not user-friendly and thus not desired.
For other kinds of resource like Tomcat we probably need to encode the
roles
to the best of our knowledge.
Heiko
[1] http://blog.arungupta.me/role-based-access-control-wildfly-8/
[2] http://www.dzone.com/articles/configuring-rbac-jboss-eap-and
7 years, 11 months
Each hawkular-metrics PR is now checked for performance regression
by Filip Brychta
Hello,
Please be aware that second check (first is continuous-integration/travis-ci/pr) on each hawkular-metrics PR now finally does something useful.
Following build (http://jenkins.jonqe.lab.eng.bos.redhat.com:9080/job/haw-perf-stability-t...) is launched for each PR which will:
1 - build the PR
2 - build hawkular-dist using snapshot artifact from step 1
3 - deploy hawkular-dist
4 - start perf test which will
- generate as high load as the hawkular is able to server. Right now from 300 threads where each thread is using unique tenantId.
- measure average throughput (one request == POST one data point to http://${server.host}:${server.port}/hawkular/metrics/gauges/test/data and wait for response)
- check % diff with previous build
- if the % diff is < -2, it will fail the build. Right now it's still not 100% stable because of shared network, this problem should be fixed soon. Expected instability is now +/- 2 % so anything bigger than 2% should be considered as regression
5 - report status back to the PR
So please from now on pay attention to result of that check and ping me if it fails.
Consider this just as first step, there will be more next week since we have more time now (JON 3.3.3 is out).
It would be nice if anybody could create a PR which would test this (just include some tiny sleep into request processing)
Thanks,
Filip
8 years, 1 month
faster dev build of hawkular
by Jiri Kremser
Hello there,
there is a PR hanging https://github.com/hawkular/hawkular/pull/342
that will change the way the -Pdev profile works. Currently, it creates the zip and gz archive, but most of us don't use it during the development. The directory is pretty much ok. So it won't be created anymore, if you need the zip/gz with precreated jdoe:password, use -Pdozip.
I am sending this not to break anyones automated workflow. I asked Filip and it seems QE don't depend on it.
Perhaps the dozip profile can go away completely, then.
jk
8 years, 1 month
Revisit resource naming + resource types for Alpha4
by Heiko W.Rupp
Hey,
we currently have a pretty ad-hoc resource naming scheme,
that involves magic constants like "MI~R" or "AI~R"
and also sometimes square brackets '[' and ']', which are
even invalid characters (if not escaped) inside a URL [1].
A recent switch from resource naming with [] to one without
[] created a bit of a mess, as the metric names still expect
the [] and probably other clients that are not part of the
github.com/hawkular repositories
We need to revisit and fix the resource types
(e.g. supply WildFly base data from within the Hawkular server)
and the resources using those including names of
metric definitions , operation definitions etc in Alpha4
before too much code relies on it.
Similar I believe that resource info should not contain
the full type information every time - only if explicitly
requested. Clients should be able to get the type info
by following a link that is supplied in the resource info.
On top of that we need to publish how client writers
can get the data they need.
[1] https://issues.jboss.org/browse/HAWKULAR-491
8 years, 1 month
What is the best way to build hawkular with the latest hawkular-metrics?
by Filip Brychta
Hello,
I have following goal:
1 - build each hawkular-metrics PR
2 - build hawkular-dist using artifact from step 1
3 - run some tests
What could be the best and most reliable way to do this?
a) just build hawkular dist with hawkular-metrics snapshot from step 1
- I tried this and it was working for a while but then it stopped working (I guess when those intergration branches were introduced)
- is there any chance that this approach will ever be reliable?
b) build hawkular dist using the latest snapshots for all components
- is this reliable?
c) any other option?
Or the only reliable way is to build hawkular-metrics and deploy it to a wildfly manually as a single component and test it this way?
Thank you,
Filip
8 years, 1 month
execute op
by John Mazzitelli
As part of the new UI-server-feed comm work, the following now works.
In our agent config, if a resource-type has an operation defined, you can execute that operation from end-to-end. I don't have the UI coded up - I mock out the UI with a simulated websocket client.
These are the log messages I got in the logs to show it working:
1) The UI sends in the request over websocket - the content of the request looks like this:
ExecuteOperationRequest={"resourceId":"mazztower~Local~/subsystem=hawkular-monitor", "operationName":"Status"}
2) The server receives it over the websocket. Log message:
Received message from UI client [AjEP4Q3X0ViCalHvAsodkve92mshxsCxJTy9PQ9r]
3) And then puts it on the bus. Whatever server is currently connected to that feed will have a bus listener for this particular command for that particular feed and picks it up. Log message from the bus listener:
Asking feed [mazztower] to execute operation [Status] on resource ID [mazztower~Local~/subsystem=hawkular-monitor]
4) That bus listener does what it needs to do - in this case, forwards the message to the appropriate feed/agent. Log message:
Attempting to send async message to [1] clients: [ExecuteOperationRequest={"resourceId":"mazztower~Local~/subsystem=hawkular-monitor","operationName":"Status"}]
5) The agent gets the message from its websocket. Log messages:
Received message from server
Received request to execute operation [Status] on resource [mazztower~Local~/subsystem=hawkular-monitor]
6) Once the operation is executed, the results are sent back to the server - these are logs back on the server again:
Received message from feed [mazztower]
Operation execution completed. Resource=[mazztower~Local~/subsystem=hawkular-monitor], Operation=[Status], Status=[OK], Message=["STOPPED"]
So you can see the server was told that the operation succeeded and what the results were in Message.
Lots more to do. But the end-to-end is working. Need to support parameters, next. Then have to figure out how to do resource configuration using this same comm mechanism.
8 years, 2 months
