May 2016 - hawkular-dev - Jboss List Archives

by Lucas Ponce

Hello, These days we have had several discussions about the hawkular client ruby. Today there are two main uses cases (Hawkular Metrics from OpenShift and Hawkular Services for MiQ provider) and there are some complexity in the side effects of updating the clients related to the backward compatibility. I have started to collect some notes about this https://docs.google.com/document/d/17bAPbBJ6_2wdXAAg_XIQRMi0_RQfODyOEmdOs... I hope it can help to gather all requeriments to have a clear … [View More]

8 years, 9 months

2
2
0 / 0

Hawkular Organization - Repositories - Vote

by Stefan Negrea

Hello Everybody, Based on the emails and discussions from the past few weeks, I created a community poll to finalize the decision on unmaintained Hawkular repositories. The current Github org has a significant number of projects that no longer receive development. For a full list of projects please see [1], projects below red line are not active. Please vote on what to do with repos below the red line and future repos that will no longer be developed by Hawkular: 1) Move to new Hawkular-… [View More]

8 years, 9 months

1
1
0 / 0

SSL by default

by Juraci Paixão Kröhling

Team, I just sent a PR for hawkular-services [1] that adds SSL support by default to the distribution. I'd like you to take a moment and do a couple of simple tests of your component against this distribution, specially if you perform REST calls to a component endpoint. Apart from the Agent, I'm not aware of any REST calls made by individual components, but I'd need to be aware of any problems that this change might cause. My next step is to change the agent to accept certs on our … [View More]

8 years, 10 months

4
11
0 / 0

Reform Inventory REST API

by Lukas Krejci

Hi everyone, tl;dr Inventory's REST API is ambiguous and doesn't reflect the generic structure of the inventory well. Let's change that before it's too late! The access patterns in inventory's REST API predate the concept of the canonical path that we now use extensively throughout the model to uniquely identify the entities and because of that we're running into various issues with the REST API. From slight inconveniences to outright breakage due to ambiguous URLs. Here I propose a … [View More]reformed REST API centered around the canonical paths. It should have the same expressive power as the original REST API but should not suffer from the ambiguities and should be much more cohesive and "logical". The only thing that was possible using 1 call in the old API that will require 2 calls in the new API is disassociation of 2 entities (i.e. disassociate a metric from a resource, etc.). These operations are IMHO rather rare so I am not too worried about this. I'd like to know your opinions on the new API: URIs below are defined in EBNF, CP stands for canonical path of some entity, REL stands for a name of some relationship (pre-defined or user defined) == sync endpoint URI = "/", "sync", "/", CP; This is the same as it is currently. There is a parallel thread from the last week about the evolution of sync that will be addressed, too. == bulk endpoint URI = "/", "bulk"; might go away - we have sync doing almost the same thing == GET URLs This is a little bit complex but what this does is that it enhances a canonical path as is currently known with the ability to define filters on each path progression step. Basically, this is an attempt to express a graph traversal using an URL. ANY = ? just a URI path-escaped string representing an entity ID or relationship name ? ; FILTER_NAME = "type" | "id" | "name" | "cp" | "identical" | "propertyName" | "propertyValue" ; FILTER = FILTER_NAME , [ "=", ANY ] ; (* value is not required for the "identical" filter *) PATH_SEGMENT_TYPE = "t" | "e" | "mp" | "f" | "rt" | "mt" | "ot" | "r" | "m" | "d" ; PATH_SEGMENT_ID = ANY ; PATH_STEP = "/", PATH_SEGMENT_TYPE, ";", PATH_SEGMENT_ID, { ";", FILTER } ; WELL_KNOWN_REL = "contains" | "defines" | "incorporates" | "isParentOf" ; ANY_REL = ANY ; DIR_FILTER = ";", ( "in" | "out" | "both" ) REL_FILTER = ( "propertyName" | "propertyValue"), "=", ANY ; REL_STEP = "/rl;", ( WELL_KNOWN_REL | ANY_REL ), [ DIR_FILTER ], { REL_FILTER } ; FILTER_STEP = FILTER, { ";", FILTER } ; RETURN_TYPE = "" | "treeHash" ; PATH_END = ( PATH_STEP | FILTER_STEP ), RETURN_TYPE ; URI = { ( PATH_STEP | FILTER_STEP ), [ REL_STEP ] }, [ PATH_END ]; The "identical" bit is currently not present in the REST API but is in the Java API. What it'd do here is that it would "widen" the start of the query from the one entity specified by the CP to all entities that are identical to it according to the identity hash rules (same id, same significant structure). This is useful for scenarios like "querying all EAPs". The way this would work is that you'd have your resource type that you expect defined and a global level, possibly contained in a metadata pack. You'd then look for resources that are defined by the resource types identical to yours. Because feeds are free to (re-)define their resource types, this would match resources from feeds that have types identical to the global one. Note that there is no special relationship needed between the types - inventory figures this out automagically. This way we loosen the requirement for synchronizing the updates to the types defined by feeds and the user at the cost of "eventually consistent behavior" once the parties upgrade at their own pace. === Examples ==== Return a tenant / ==== Access Entity By Canonical Path /t;tenant_id/f;feed_id/rt;resourceType_id This is actually equivalent to: /t;tenant_id/rl;contains;out/f;feed_id/rl;contains;out/rt;resourceType_id which is no longer a canonical path but showcases how we declare "hops" over specific relationships. "rl;contains;out" translates to "relationship with name contains in the outgoing direction" and is implicit, if no other "hop" between entities is specified. To return the tree hash of the entity instead of the entity itself, one can: /f;feed_id/r;resource/treeHash Note that the tenant in the path is optional because it can be deduced from the authorization details. ==== Accessing Targets of Relationships /f;feed_id/r;resource_id/rl;incorporates/type=metric This is equivalent to the current `/feeds/feed_id/resources/resource_id/metrics`. /f;feed_id/r;resource_id/rl;isParentOf/ (notice the trailing slash) "give me all children of resource with id 'resource_id'". ==== Accessing Relationships /f;feed_id/rl;contains (notice the lack of trailing slash) "find all the 'contains' relationships going out of the feed with id 'feed_id'." To access a single relationship with known id: /rl;relationship_id ==== More Complex Example /f;feed_id/type=rt;name=My%20EAP;identical/rl;defines/type=resource/rl;isParentOf/type=resource?recursive=true "get a feed with id 'feed_id' and find all resource types called "My EAP" that it contains and all other resource types that are identical to it (them). Then find all the resources that those resource types define and find all the resources (recursively) that those resources are parents of." === Query Parameters ==== Paging `per_page`, `page`, `sort`, `order` Paging is very expensive, because it implies fully iterating through the result set (to be able to sort or determine the total). We may think about some kind of server-side "live result set" that would hold the results on the server and be accessed using some kind of token (with a TTL). This is how neo4j does it and would avoid having to fetch the full result set on each paged request. ==== `recursive` This causes the last hop (relationship + entity filter) to be recursively searched and added to the results. Tinkerpop defines a more generic concept of "loop" using a label as a marker of the start of the "recursive hop" but I don't think we need to be that powerful in a REST interface. Advanced users may want to use the `query` endpoint with the full power of Gremlin query. == POST URLs URI = "/", CP, "/", "resource" | "metric" | "resourceType" | ...; The idea here is that you can create the entities only at their canonical positions. While the Java API allows for creation after a non-canonical traversal, I think this would be unnecessarily complicated for the REST API. The users would pass the familiar blueprint objects to these endpoints as they do currently. Examples: /feed - send a feed blueprint and this will create a new feed /resourceType - send a resource type blueprint and it will create a new global resource type /metricType ... /f;feed/resourceType - creates a feed-local resource type == PUT URLs URI = "/", CP just send an update object corresponding to the type of entity on the path == DELETE URLs URI = "/", CP deletes the entity on the path disassociation needs to be 2 steps - find the relationship in question and then delete the relationship, e.g.: GET /f;feed_id/r;resource/rl;defines DELETE /rl;id-found-in-the-results-from-the-previous-query == Advanced Querying URI = "/", "query" free form, read-only gremlin query for more complex queries (this needs to wait for the port to Tinkerpop3) [View Less]

8 years, 10 months

2
4
0 / 0

BTM or not BTM, that is the question

by Gary Brown

Hi all As discussed in the recent blog (and demo), Hawkular BTM now provides Application Performance Management (APM), Distributed Tracing (DT) and Business Transaction Management (BTM). The project was initially started to address the third area, hence being called BTM - however BTM requires the collection of the information used to provide APM and DT - and providing those other views on the information is useful to users. Due to the wider scope, just wondering whether the BTM name is now … [View More]

8 years, 10 months

9
13
0 / 0

Metrics: Cassandra Driver timeouts during the build

by Peter Palaga

Hi *, Short version: doubling the read timeouts [1] for all three uses of Cassandra Driver solved the problem for me. Is this a good idea? Can anybody see a better solution to my problem? Long version: https://issues.jboss.org/browse/HWKMETRICS-404 As some of you already know from my complaints on IRC, I have not been able to build Metrics since a couple of weeks. My builds failed mostly on core-services but sometimes also in configuration-service and resr-tests-jaxrs, the error … [View More]

8 years, 10 months

2
2
0 / 0

Progress Report on Android Client of Hawkular

by Anuj Garg

Hello, I am Anuj. Final year computer Science graduation student and currently working on Android Client of Hawkular as my GSoC Project. It is my first report of what is going on the client recently. *What have been accomplished till yet* -> A detail screen for alert have been introduced from where you can change the state of alert read important detail about it. Read and send comments on the alert. -> Previously Android client showed only Open Alerts which have been changed to … [View More]

8 years, 10 months

1
0
0 / 0

Hawkular Data Mining 0.2.0.Final Released

by Pavol Loffay

I'm happy to announce release 0.2.0.Final of Hawkular Data Mining. List of major changes: - Getting historical metrics from Hawkular Metrics - Calculation of prediction/confidence intervals of predicted points - Improved REST API for more specific configuration of automatic forecaster Regards, Pavol

8 years, 10 months

6
5
0 / 0

inventory standalone server

by Austin Kuo

Hi all, I’m currently trying to report vertx instance to inventory, therefore I am doing some experiments that is communicating to the server with REST API. Wondering if there’s a way not to run an entire hawkular server (because i’m working on my laptop) but the inventory component alone? or any other better way to do that?

8 years, 10 months

3
4
0 / 0

Ansible playbooks

by Thomas Heute

I was working on Ansible playbooks (mostly to do a demo, but the work extended to actually build the demo...) I started with: https://github.com/hawkular/hawkular-agent/tree/mazz/ansible/hawkular-wil... and then I found: https://github.com/pilhuhn/hawkular-agent-ansible And I wanted to create a playbook to install Hawkular Server as well. I am not very familiar with Ansible (Tower) but it looks like we should have a top level repo with all our playbooks, we could also upload to Ansible … [View More]

8 years, 10 months

2
2
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

hawkular-dev May 2016