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, 5 months
Parent POM and Wildfly BOM
by Thomas Segismont
Hi everyone,
I've been working on the changes needed in Metrics for the parent POM
upgrade to version 16 (those introducing Wildfly 9).
There are three things I noticed which I believe are worth sharing.
Firstly beware that the Wildfly guys have changed their philosophy about
the BOM: now they force the "provided" scope in the BOM and exclude all
the dependencies they think you shouldn't care about as a EE7
application developer.
On one hand it frees you from adding the provided scope declaration in
your application POM. On the other hand, if you use one of the artifacts
in tests then dependency resolution could suddenly be broken.
Secondly our parent POM does not only declare the Wildfly POM in
dependency management section, in also imports it. Which means that all
our projects get forced versioning and scope, even if they are not
Wildfly based.
Thirdly, minor issue, the Wildfly Maven plugin does not configure a
default Wildfly version which means that we are all forced to declare in
components parent POMs. Like this in Metrics:
https://github.com/hawkular/hawkular-metrics/blob/master/pom.xml#L190-L196
Going forward, I propose that we no longer "import" the BOM in Hawkular
parent, and let components do it where needed. And that we declare the
Wildfly version to start with the Wildfly Maven plugin in the parent.
Regards,
Thomas
7 years, 8 months
Prototype of operations execution on the feed
by Heiko W.Rupp
Hey,
I have prototyped the execution of operations on the feed (WF-server for
now).
Note, that this is not any way of final implementation, but merely a
proof of
concept to get this started with the possibility to discuss some less
abstract situation/code.
Also for the "action on all selected items" - that is currently not
taking
the selected items only.
This works by having a new endpoint on the server
http://localhost:8080/hawkular/opsq
where a post to it submits one or more jobs onto the server.
A get to opsq/{feedid} then pulls one job for that feed.
The wf-agent now has a new runnable 'OpsGroupRunnable' that
once per minute polls that above endpoint and executes jobs that are
available.
I think that for a real implementation we should consider upgrading
the server-feed communication from many http/1.1 requests to
a websocket connection, that is then multiplexed on the server and
when something is added to the queue of jobs, it directly gets
pushed instead of the agent polling for it.
Also the result of the operation needs to be delivered back to the
server and ui; we need to add some unique operation id, to be able
to correlate request and result.
This also brings back the resource type discussion (see other email),
as e.g. a .war file does not support a :delete action. This needs e.g.
to
be broken out into a :undeploy and then remove-from-vf-content-repo
action. Or there are no :enable/:disable actions. They may need to be
translated into deploy/undeploy. Or greyed out in the UI.
The implementation spans multiple repositories - I do not intend
to send pull-requests, as this is only a prototype / proof of concept.
Hawkular-Monitor:
https://github.com/pilhuhn/hawkular-agent/tree/ops-get
UI-Services:
https://github.com/pilhuhn/hawkular-ui-services/tree/ops-get
Hawkular:
- QueueHandling
https://github.com/pilhuhn/hawkular/tree/ops-get/modules/ops-queue
- UI
https://github.com/pilhuhn/hawkular/tree/ops-get/ui/console/src/main/scripts
7 years, 8 months
Apps list search
by Gabriel Cardoso
Hello,
I was assigned to design the search/filter component for the applications list and would like to bring some questions. I already got some requirements from Liz/Thomas.
My proposal would be to present a behaviour similar to what JIRA does. They have “dropdown” selectors to allow filtering + a search box (initially).
For our context, the dropdowns would be to filter State (Up, Down etc.) and Type (EAP, Wildfly etc.). We probably don’t need the find input in the beginning, when we have not many options.
Thomas brought this comment:
> The input text should still be editable to do more filtering such as:
> "(status=DOWN OR status=UNKNOWN) AND hostname ~ 'corp.redhat.com <http://corp.redhat.com/>' " (To show all servers on *.corp.redhat.com <http://corp.redhat.com/> that are down or unknown)
JIRA also covers that, when clicking on Advanced, the dropdowns are hidden and everything goes inside the search input:
I like this approach because we offer something user-friendly and at the same time provide something more powerful for advanced users.
I would like to hear your feedback.
@Inventory team, from what was presented, it is feasible to be implemented?
Thanks,
Gabriel
Gabriel Cardoso
UX designer @ Red Hat
7 years, 8 months
Inventory 0.1.0.Alpha3 released
by Lukas Krejci
Hi all,
In a surprising move, Inventory released its 0.1.0.Alpha3 version AFTER
0.1.0.Final. The release was cut from a branch branched off of a commit
preceding 0.1.0.Final such that 0.1.0.Alpha3 only contains the fix for
https://issues.jboss.org/browse/HWKINVENT-54 on top of what already has been
available in inventory 0.1.0.Alpha2.
This has been done so that Hawkular 1.0.0.Alpha2 can be released without any
further API breakage.
Thanks,
Lukas
7 years, 8 months
C* schema design
by John Sanda
I had been looking at the alerts schema briefly and wanted to share some thoughts on schema design in general. My understanding is that there can be many alerts for a single trigger. And based on my understanding and experience with RHQ, it is possible for there to be a large number of alerts. Here is the schema for the alerts table,
CREATE TABLE alerts (
tenantid text,
alertid text,
payload text,
PRIMARY KEY (tenantid, alertid)
)
Simple enough. Here is a short test driver[1] I wrote to insert 100 million alerts into a 3 node cluster. Note that only a single tenant is used. As the test ran, I periodically ran nodetool status to check the load on the cluster. You can see the output of that here[2]. You will that only of the nodes owns virtually all of load. 127.0.0.1 has over 2 GB of data while the other two have less than 500 KB each.
All of the alerts for a single tenant are stored in a single partition. In other words, all alerts are stored in one physical row on disk. This does not scale. Regardless of the number of nodes, only one node owns all of the data for a given tenant. This will also probably increasingly negative impact on read performance.
The first change I might consider is to partition by trigger, but that alone is probably not sufficient. What if a single trigger generates thousands of alerts per day? That is still going to lead to hot spots (i.e., partition becoming too large). I would also consider partitioning by some time slice. Something like this,
CREATE TABLE alerts (
tenantid text,
triggerid text,
date timestamp,
alertid text,
payload text,
PRIMARY KEY ((tenantid, triggerid, date), alertid)
)
Now data is partitioned by tenant, trigger, and date. The date column might be rounded down to week, day, hour, etc. It really depends on the frequency of writes as well as the read patterns. Now the data will be spread across nodes in a more scalable way. And when you have to fetch data across multiple time slices, you can execute the queries in parallel.
[1] https://gist.github.com/jsanda/ce07905fa9f16f13c661 <https://gist.github.com/jsanda/ce07905fa9f16f13c661>
[2] https://gist.github.com/jsanda/6d2ee6cd5bcab07331d2 <https://gist.github.com/jsanda/6d2ee6cd5bcab07331d2>
7 years, 8 months
