September 2015 - hawkular-dev - Jboss List Archives

by Michael Foley

The following is a new meeting request: Subject: MS5 Testing Review Organizer: "Michael Foley" <mfoley(a)redhat.com> Location: http://www.bluejeans.com/mfoley51 Time: Friday, October 16, 2015, 10:00:00 AM - 10:30:00 AM GMT -05:00 US/Canada Eastern Required: jon-qa-list(a)redhat.com; jon-pm-list(a)redhat.com Optional: hawkular-dev(a)lists.jboss.org; jboss-on-team(a)redhat.com *~*~*~*~*~*~*~*~*~* Hi, It has been 3 weeks from the MS5 Developer Demo; let's have a review of the QE qualification of MS5! Proposed Agenda: * Review the MS5 Testing Plan -->> http://pad.engineering.redhat.com/HawkularMS5TestPlanning * QEs ... add links to all PRs for MS5 test automation into your daily status emails ...and also onto this etherpad for code review * QE Deliverables: * UI Automation ... owner = Sunil (working with Prachi, Vojtech, and Matt) * add tests for new Jiras * refactor existing tests, as needed * a link to a passing test run ... onto the MS5 Test Planning etherpad (or Jiras opened for any issues or regressions) * all test results into Polarion, our system of record * REST API Automation ... owner = Jeeva (working with Matt ) * add tests for new Jiras * refactor existing tests, as needed * a link to a passing test run...onto the MS5 Test Planning etherpad (or Jiras opened for any issues or regressions) * all test results into Polarion, our system of record * Performance CI ... owner - Filip (working with Vojtech) * a link to CI ...and a statement such as "No peformance regressions in MS5" ...or "MS5 has a performance regression of x% based on this PR" * results into either Perf Repo, or Polarion * Continuous Delivery owners = Viet, Matt * a list of any CI/CD improvements made * # of new instances deployed and made available to Hawkular community * Openshift Integration Point * we are meeting separately on this, but ... * we should quickly review this etherpad -->> http://pad.engineering.redhat.com/Management-nextAndOpenshiftTestPlanning * the MS5 deliverable for this integation point is: * 1 functional testcase into Polarion * 1 simple scalability testcase into Polarion * 1 passing testcase execution run of these 2 testcases Regards, Michael Foley QE Supervisor, Middleware BU

9 years, 2 months

1
0
0 / 0

Let embedded Cassandra service manage its own logging

by Thomas Segismont

Hi, I've been looking at the duplicate logs issue in Hawkular since yesterday. Testing has shown that embedded Cassandra is the culprit. I couldn't determine what exactly is going wrong. I suspect it's a logging framework setup mess (Cassandra has a few logging framework dependencies, even JBoss logging...) I tried to make its logs configurable via Wildfly without success. So I've sent a PR to let embedded Cassandra manage its own logging: https://github.com/hawkular/hawkular-commons/pull/16 The consequences are the following: - Cassandra logs go to "${jboss.server.log.dir}/embedded-cassandra.log" - Log files follow a time base rolling policy (similar to Wildfly server log file) - You won't see Cassandra logs in Hawkular standard output anymore It will still be possible to configure Cassandra log level via the "hawkular.log.cassandra" system property (the logback configuration file uses it). I tried the changes in a Hawkular build and they solve the duplicate logs issue. If there's no objection on the principle, could someone please review the pull request? Thanks, Thomas

9 years, 2 months

1
0
0 / 0

Hawkular MS5 Test Planning Meeting

by Michael Foley

The following is a new meeting request: Subject: Hawkular MS5 Test Planning Meeting Organizer: "Michael Foley" <mfoley(a)redhat.com> Location: http://bluejeans.com/mfoley51 Time: Friday, September 25, 2015, 9:00:00 AM - 9:30:00 AM GMT -05:00 US/Canada Eastern Required: jon-qa-list(a)redhat.com Optional: jboss-on-team(a)redhat.com; jon-pm-list(a)redhat.com; hawkular-dev(a)lists.jboss.org *~*~*~*~*~*~*~*~*~* Hi, Let's have a Hawkular MS5 Test Planning meeting! We will have seen the MS5 Developer Demo yesterday (September 24th). Let's review the testing plan to and define how we will test this. The link to the etherpad is here -->> http://pad.engineering.redhat.com/HawkularMS5TestPlanning And here is the pre-plan (subject to change, of course, based on what we see and learn in the developer demo) : Hawkular MS5 Test Planning Link to developer demo -->> Jira payload * Link to planned payload https://issues.jboss.org/projects/JMAN4/versions/12327712 * https://issues.jboss.org/browse/JMAN4-34 Deploy and Manage Applications to EAP7 * https://issues.jboss.org/browse/JMAN4-35 Define and Manage Datasources in EAP7 * https://issues.jboss.org/browse/JMAN4-36 Create and Manage JDBC Drivers * https://issues.jboss.org/browse/JMAN4-46 Adminster Audit Logging * https://issues.jboss.org/browse/JMAN4-24 RH Connected Customer, Case Management MS5 Sign-off Document, Michael -->> REST API Automation ...Jeeva * Run the whole test suite to look for regressions * New tests for these Jiras * https://issues.jboss.org/browse/JMAN4-34 Deploy and Manage Applications to EAP7 * https://issues.jboss.org/browse/JMAN4-35 Define and Manage Datasources in EAP7 * https://issues.jboss.org/browse/JMAN4-36 Create and Manage JDBC Drivers * test execution results exported to Polarion Manual testcases in Polarion, Sunil, Prachi, Vojtech * add these 5 requirements * https://issues.jboss.org/browse/JMAN4-34 Deploy and Manage Applications to EAP7 * https://issues.jboss.org/browse/JMAN4-35 Define and Manage Datasources in EAP7 honda civic * https://issues.jboss.org/browse/JMAN4-36 Create and Manage JDBC Drivers * https://issues.jboss.org/browse/JMAN4-46 Adminster Audit Logging * https://issues.jboss.org/browse/JMAN4-24 RH Connected Customer, Case Management * add 5 testcases * 1 documnted testcase execution UI Automation ... Sunil, Prachi, Vojtech * Run the whole test suite to look for regressions * New tests for these Jiras * https://issues.jboss.org/browse/JMAN4-24 RH Connected Customer, Case Management * https://issues.jboss.org/browse/JMAN4-46 Adminster Audit Logging * test execution results exported to Polarion CI/CD Improvements ...Viet, Matt * improve CI/CD to include remote Wildfly * Cantos board ... these specific cards Performance CI....Filip, Vojtech * integration with Perf Repo Openshift Integration Viet, Matt, Peter * http://pad.engineering.redhat.com/Management-nextAndOpenshiftTestPlanning * Goals for MS5 * get a few instances of Openshift+Hawkular setup * bladecenter * multi-node setup in Mountain view DONE * very simple smoke test * REST API call to deployed container to see that it is emitting metrics * scalability * UI automation * pair programming with peter ruan to get some automation in place in the openshift cucu-shift CI ... it may only be a few tests

9 years, 2 months

1
0
0 / 0

Metric id and url restrictions

by Matt Wringe

Currently we are storing metric id as any string. There are no restrictions on how we name the metrics, and when you access a single metric via a url you just need to make sure its url encoded properly here. This works fine when dealing with a client and the Hawkular Metrics directly, but can cause problems when dealing with proxies or other intermediary servers which are not exactly url compliant. The big issue is with slashes in the metric id. Even when properly encoded this can cause problems with things like proxies not accepting them (and even certain web container don't like them). Since we need to be able to integrate over networks with these types of servers, we need to find a solution to resolve this in hawkular. Possible solutions - enforce naming of anything which can show up in a the URL to make sure it cannot include a '/' . This would include things like metric Id. This should probably be enabled by default, but we could have an option to disable this if a user needs it. - create a new endpoint which can be used to perform a POST instead of doing a GET on the metric endpoint. This would mean sending things like the metric id and query string as part of the message body in the POST instead of in the URL. Any thoughts?

9 years, 2 months

6
8
0 / 0

Embedded Cassandra default log level

by Thomas Segismont

Hi everyone, There's a bunch of log messages when you start Hawkular with embedded Cassandra. IMHO, this prevents the user to focus on informative messages. I'd like to change the default log level of embedded C* to WARN. https://github.com/hawkular/hawkular/pull/487 Regards, Thomas

9 years, 2 months

4
6
0 / 0

Termin gestrichen: Hawkular-Team Update - Di 22. Sep. 2015 3:30PM - 4PM (hrupp@redhat.com)

by hrupp＠redhat.com

Dieser Termin wurde gestrichen und aus Ihrem Kalender entfernt. Titel: Hawkular-Team Update This is a all-Hawkular team meeting to give updates where we are and so on. This is *open to the public*. Location: on bluejeans: https://redhat.bluejeans.com/hrupp/ or alternatively teleconference Reservationless+ , passcode 204 2160 481 You can find Dial-In telephone numbers here: https://www.intercallonline.com/listNumbersByCode.action?confCode=2042160481 RedHat internal short dial numbers are 16666 and 15555 (and probably others, depends on your location) Wann: Di 22. Sep. 2015 3:30PM - 4PM Berlin Wo: pc 204 2160 481 Kalender: hrupp(a)redhat.com Wer * Heiko Rupp - Organisator * Peter Palaga * Simeon Pinder * Lucas Ponce * lkrejci(a)redhat.com * Mike Thompson * amendonc(a)redhat.com * Gabriel Cardoso * hawkular-dev(a)lists.jboss.org * Jay Shaughnessy * snegrea(a)redhat.com * theute(a)redhat.com * gbrown(a)redhat.com * John Mazzitelli * jcosta(a)redhat.com * Viliam Rockai * John Sanda * Jiri Kremser * Thomas Segismont * miburman(a)redhat.com Einladung von Google Kalender: https://www.google.com/calendar/ Sie erhalten diese E-Mail unter hawkular-dev(a)lists.jboss.org, da Sie ein Gast bei diesem Termin sind. Lehnen Sie diesen Termin ab, um keine weiteren Informationen zu diesem Termin zu erhalten. Sie können auch unter https://www.google.com/calendar/ ein Google-Konto erstellen und Ihre Benachrichtigungseinstellungen für Ihren gesamten Kalender steuern. Wenn Sie diese Einladung weiterleiten, kann jeder Empfänger Ihre Antwort auf die Einladung ändern. Weitere Informationen finden Sie unter https://support.google.com/calendar/answer/37135#forwarding

9 years, 2 months

1
0
0 / 0

Token errors with WebSockets and other backend calls

by Juraci Paixão Kröhling

All, I've seen some problems lately that are hard to debug and may cause you to waste valuable time. In short, if you face "strange" issues related to authentication, specially when trying features that make use of WebSockets (ie: add deployment), make sure you are accessing the web UI via 127.0.0.1 , and not localhost . In case you are interested in the details, keep reading. Upon login, Keycloak issues a token for the client, taking the auth server host into consideration (as the "issuer authority"). If you use localhost, then that's the hostname that Keycloak will use inside the token. This value is later used to validate the incoming token. Ideally, all the hostnames would be a match, and that's usually the case if you use the "-b" switch when starting Wildfly. But if you don't specify, we fall back to 127.0.0.1 [1] , causing the "backend call" to be 127.0.0.1, while the "frontend call" came via localhost. I have a couple of ideas on how to solve this in our side, but until a fix is done, tested and merged, please use 127.0.0.1 on the UI. 1 - http://git.io/vnJfx - Juca.

9 years, 2 months

1
1
0 / 0

Recent changes in hawkular-metrics performance tests

by Filip Brychta

Hello, there is one important change in the test setup. Baselines are no longer taken from last successful job but are defined statically now. It means that any change to the baselines must be done manually. This was done to avoid silent performance drops and to have every baseline change documented. See [1] for details. Another thing is reporting improvement. Simple report containing each build step and some instructions is now available on public VM (accessible outside of VPN). It should be easy to find out which build step failed and what to do to next without looking into internal jenkins job console logs. This report is accessible from each pull request (Details link next to haw-perf-stability-test check). Example: http://209.132.178.156/report268.html Filip [1] - https://mojo.redhat.com/docs/DOC-1045245

9 years, 2 months

1
0
0 / 0

[Metrics] JAX-RS 1.1 implementation update

by Thomas Segismont

Hi, This morning I've fixed the remaining issues in the JAX-RS 1.1 implementation branch. The REST API test suite is now fully passing against both JAX-RS 1.1 and 2.0 implementations. I've added a 'diff.txt' file in the 'api' [1]. Reviewers should carefully look at handler code differences. Regards, Thomas [1] diff -r --exclude=target metrics-api-jaxrs metrics-api-jaxrs-1.1 > diff.txt

9 years, 2 months

3
10
0 / 0

Coming to inventory 0.4.0 - bulk create of entities

by Lukas Krejci

Hi all, pending a peer-review is a new feature in inventory to support bulk creation of entities (in a single transaction). So far, our REST API was rather granular and concentrated on working with single entities or even their individual relationships. This was quite costly especially during create, update or delete operations, where the clients would need to do stuff one-by-one. This is being addressed in Inventory 0.4.0 (hopefully coming to Hawkular Alpha5) with a new REST endpoint called "/bulk". For 0.4.0 we will only support bulk creation with update and delete coming in the next versions. The bulk endpoint accepts a rather complex javascript object that can be used to specify what is being created and where. The best way to explain it is by an example: { "/t;tenant": { "environment": [ { "id": "env1", "properties": {"key": "value"} }, { "id": "env2", "properties": {"key": "value2"} } ], "resourceType": [ { "id": "URL" } ], "metricType": [ { "id": "ResponseTime" } ] }, "/t;tenant/rt;URL": { "data": [ { "role": "configurationSchema", "value": { "title": "URL config schema", "description": "A json schema describing configuration of an URL", "type": "string" } } ], "operationType": [ { "id": "ping" } ] }, "/t;tenant/e;env1": { "resource": [ { "id": "url1", "resourceTypePath": "/t;tenant/rt;URL" } ], "metric": [ { "id": "url1_responseTime", "metricTypePath": "/t;tenant/mt;ResponseTime" } ] }, "/t;tenant/e;env1/r;url1": { "data": [ { "role": "configuration", "value": "http://redhat.com" } ], "relationship": [ { "name": "incorporates", "otherEnd": "/t;tenant/e;env1/m;url1_responseTime", "direction": "outgoing" } ] } } The javascript object above would cause creation of 2 new environments, "env1" and "env2", under the tenant "tenant", a new resource type called "URL" and a new metric type called "ResponseTime". When the URL resource type is created, a configuration schema is created for it (and the configuration schema prescribes that the configuration of the URL is merely a string). Additionally, an operation called "ping" is defined for the resource type. After that a new resource, "url1" is added to environment "env1" with the "URL" resource type and a metric called "url1_responseTime" is also added to the environment. Finally a configuration is added to the resource and the resource is configured to incorporate the previously created metric. The structure of the javascript object is following: 1) The top-level keys are paths to the inventory entities *under* which the new entities should be added, e.g. the first key "/t;tenant" means that the value of that key describes what should be created directly under a tenant called "tenant". The second key, "/t;tenant/rt;URL", tells the REST API that the value of that key describes what should be added "under" that resource type. The structure of what kinds of entities can contain what kinds of entities can be found in the documentation [1]. Notice that the order of the keys in the object is significant. 2) The second-level keys describe what type of data to create under a given parent (notice that you can create more than 1 type of data under some entity types). The values of those keys are arrays of actual blueprint objects describing the new entities to be created (each entity type can have different format). The blueprint objects are the same as the ones passed in to the granular REST endpoints that already exist. The response always has the 201 - Created status code and is a JSON object with the types of entities created as keys and values are again objects with keys being the canonical paths to the entities created and values are HTTP status codes describing the result of the creation (201, 409, etc.). E.g. for the above example the following would be a response: { "environment": { "/t;tenant/e;env1": 201, "/t;tenant/e;env2": 201 }, "resourceType": { "/t;tenant/rt;URL": 201 } "metricType": { "/t;tenant/mt;ResponseTime": 201 }, "data": { "/t;tenant/rt;URL/d;configurationSchema": 201, "/t;tenant/e;env1/r;url1/d;configuration": 201 }, "operationType": { "/t;tenant/rt;URL/ot;ping": 201 }, "resource": { "/t;tenant/e;env1/r;url1": 201 }, "metric": { "/t;tenant/e;env1/m;url1_responseTime": 201 }, "relationship": { "<some-random-id>": 201 } } Hope you will find this useful, Lukas [1] http://www.hawkular.org/docs/components/inventory/index.html#inventory-or...

9 years, 2 months

3
6
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

hawkular-dev September 2015