January 2015 - hawkular-dev - Jboss List Archives

by Viliam Rockai

Hey All, I want to start this thread to gather some information about how components are shared between projects. So, to make the terminology clear, lets check this stuff: https://github.com/vrockai/hawkular/tree/master/ui/console/alerts https://github.com/vrockai/hawkular/tree/master/ui/console/metrics are future components/widgets which are going to be used on the console page. Those components are Hawtio 2.x plugins. According to: https://github.com/hawtio/hawtio/blob/master/docs/Overview2dotX.md I expect exposing plugins as bower packages is the preferred way in Hawtio 2.x. From my perspective (angular guy) this is pretty much what is expected. The only way to expose/share those components as bower packages to third-parties would be to put them in separate repo. As was already said on IRC, this may be overkill. I see two ways of resolution: 1. Create separate repository for each component. Those all would be bower dependencies of the hawkular console. Pros: possibly consistent with the Hawtio 2.x ways, modularity = we download only what we need. Cons: lots of repositories to take care of. 2. Create a single repository for all the plugins. The whole library of sibling components, similar to i.e. Angular-UI. Pros: easier maintenance. Cons: less modular = need to download whole library before we filter which plugins we want to use. I see, that the 2nd approach already exists in the hawtio repository, probably the best way would be to put our components to this repo: https://github.com/hawtio/hawtio-ui Thanks for your thoughts, Viliam

9 years, 3 months

4
7
0 / 0

Meeting recording of Jan 27th meeting

by Heiko W.Rupp

Hey, find below a link to the (video) recording of todays meeting. For those not on the call, I was talking a bit about Continuous Deployment and especially about KanBan and the respective Jira boards and also how we should use them and proceed. https://bluejeans.com/s/81Xm/ You should be able to see the boards when you go to issues.jboss.org and then in the top menu bar go on "Agile". This is the link to the overall board https://issues.jboss.org/secure/RapidBoard.jspa?rapidView=1242 One thing that I did not talk about is the reporting - we do not yet have enough data in the system. I will do that as soon as we have more data available. Heiko

9 years, 3 months

1
0
0 / 0

Outcome of Keycloak Demo

by Juraci Paixão Kröhling

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All, We had today our Keycloak Demo and I'd like to thank everyone who joined. It was a very nice experience. During the hangout, a few points were raised: 1) Would it be possible/desirable to make the Keycloak integration optional? 2) Would it be possible to not use the Keycloak appliance distribution, using Wildfly instead? For the first question, I'll open a new thread to discuss it. About the second, I'm going to work on the start.sh script next week and do it. The main advantage is that we'll have a place where the final users can use as reference in setting up their environment, and having Wildfly as start base is more comfortable than having Keycloak Appliance, even though the final outcome is the same (ie: Wildfly + Keycloak server + Keycloak adapters = Keycloak Appliance). Once again, I encourage you to try out the branch and see if you find any problems that I might have not seen. Best, Juca. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUwoWWAAoJECKM1e+fkPrXpVMH/0R7TdQ59IgGBby4QCCzxUVS IbAdC4+35b3nVF9306uekj2xBJu9i/Dj1ixp4KGeeQXOLVWVKIt1SLOO+1vXnG3a 2nDWfmTLuqm387tVhp8yNLj2e7I+JyQBNsBC1CAsLZUS1EWzlQ6/p2zy8r8LzH3X myVbiZg68LchHQiJMCa0ZF9i0pV+TuZXVYahuYFofmrwGsu+fTH2212XYPCtTaQB BRtytP6BE3Dm6X38zJYHeZJTADrP9ySNpk4ghxZ69EnVVbG0wfDPi49JRq5jI0ff l6WvhNBv+eQYOxcSY7Rjmw/+khgJpRr/jKci1zAkQ82mxFb9OpbxVnyYKnVX4xs= =rJGL -----END PGP SIGNATURE-----

9 years, 3 months

1
1
0 / 0

Realm selection modal

by Juraci Paixão Kröhling

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All, Once the Keycloak integration PR gets merged, I intend to work on the registration feature and that will impact the "realm selection modal" (which was also discussed during the demo). So, I'd like to ask for ideas on how to implement that. What we know so far: - - At first, each user is a tenant. So, the registration page could ask for: * an "account name" (serves as the realm name) * email address (this user will serve as the realm's super user) * password As the output, it shows the user a set of credentials. For instance, a UUID which will serve as "password" for wildfly-sender or other remote agents. This registration feature would be in a separate WAR, available probably on the /registration context. When logging in, we need to tell Keycloak against which realm to authenticate this user. So, we have two main choices here: Option 1 * Allow the user to enter their account name on the first page. * We then redirect the user to the Keycloak login page, based on the account name he entered. If the realm name exists, Keycloak shows the login page. Otherwise, Keycloak complains. - - or - Option 2 * We store the user's email and realm on our side * Before sending the user to the login page, we ask for the user's email address. We then retrieve the realm for this address and send the user for authentication. I like the first option more, because: * We can change this logic on the future to pre-fill the user's account based on some other meta-data (sub-domain, for instance). * Option 2 opens a door to email harvesting (the first step in an attack reconnaissance phase): just enter a bunch of email address and wait for a login page to appear and you have a confirmation that this email exists. As this is a topic that was discussed on the demo, I'd like to hear your opinions/suggestions on how to implement this. - - Juca. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUxmFRAAoJECKM1e+fkPrX8dMIAIiu//9xPvkmztXsjt1bpV6V SdgkfIk9Yctg4S4bRR2Cg2sigZ3Yq7zH/0CmiC/NCdh9dGYITjCPUmVjmmbEFVIz e/n+cPLOpnH7j0GGq0yPF7BY/eJGLCC2RkY/OjnxkLBQ8TgoMC2sS5eQ5EJFywz0 EoB/YOJG4riokD9/bhuL5ztjGB/V9GxsoMwUks7YQIquhbGbiZ9aVi0ieAwFFuUh MwtU5r4BoeVqDpwegkU5KU8Y3Jy20LtDm8kwKezsGNPyqkFeSUPymgn4uCnqlatM j7cEP7KFlG6zCmoxUZNHnuMfGS+sTF0oezJFanyheb6+idI8leUMrrUo0Oi9/Cs= =RPxX -----END PGP SIGNATURE-----

9 years, 3 months

1
0
0 / 0

Roles and Permissions in Hawkular

by Heiko W.Rupp

Hey, one thing that we did not touch yet, but we probably should are user roles and their permissions. The driver for me here is that the current rhq-metrics rest api offers endpoints to upload and retrieve (metric) data, but also to modify (meta)meta data like the retention period of metrics. This is something I consider as more restrictive, as you don't want arbitrary feeds to just set the retention period to 10years without anyone noticing. There are probably other endpoints (in existing rhq-metrics) that need more elevated rights as well. Same applies of course for the more overall Hawkular project. We are trying to (conceptually) align with what WildFly offers (at least on the role side), so that users who know one, also feel at home with the other. There are obvious differences though with what RHQ has been offering for a long time (even before AS7). Not only from the fact that expect to "superuser" no roles are built in, but also in the fact that the assignment of role to resource is not "direct", but done via resource groups, that can be composed on the fly. See e.g. the first part of https://developer.jboss.org/community/rhq/next/blog/2014/11/11/thoughts-o... for a quick intro into that. Current RHQ RBAC also has shortcomings where the WildFly one is better (and still, there may be some more fine grained permissions needed). E.g. we have so called "operations" (a lot like the operations on WildFly resources), where we are not able to differentiate between "harmless" show-xyz operations and more sensitive "reboot box X" ones From Brian Stansberry: --- WildFly RBAC isn't heavily based on resource assignment. It's about assigning different constraints to roles and then providing information about the actions users want to take and the resource/attribute/operation involved and seeing if the constraints are met. The answers as to whether a constraint is violated don't generally fall along resource lines. The main constraints: 1) Is it a read or a write. Presumably dealing this kind of thing won't be an issue with any authorization scheme. :) 2) Does a write affect persistent configuration? This often depends on the particular attribute/operation, not the resource. Perhaps it's not so critical though. 3) Is the resource/attribute/operation configured as security sensitive? This is the key one and it doesn't map cleanly to resource assignment, since individual attributes can be sensitive while the overall resource is not, and different classifications of security sensitive can differ as to whether reads and writes are both sensitive, or just writes. --- Anyway: we need to start tagging endpoints with information about access levels so that we can enforce them by different policies. Those policies should probably not only take the user + credentials into account, but also the origin of requests, as for the above example, a request coming from the same machine or e.g. the Hawkular-glue may be treated differently than one coming from some random dump feed on the internet. Note, that those access levels usually do not replace authentication (via KeyCloak), but are applied after successful authentication and probably role assignment. Depending on the use case (embedded Hawkular-metrics, Standalone Hawkular-Metrics, Standalone Hawkular) the check points may be at different places, or we decide to e.g. always enforce at the component boundary. The following two drawings should illustrate this The green circle illustrates the "check being at java-level" on the standalone side, which also would still work for the embedded case when the rest-api is replaced by some other implementation. For the Hawkular server, we could move the check earlier e.g at the message-gw. Or just pass the additional information (origin, ...) on the message on the bus and then keep the checks at Hawkular-metrics core as in above case. Heiko

9 years, 3 months

2
1
0 / 0

JUnit and TestNG

by John Sanda

The decision was made a while ago to migrate from TestNG to JUnit. There was a PR[1] that migrated some of the integration tests to JUnit. I wound up rejecting the PR and keeping the integration tests in TestNG because it is not clear to me how JUnit supports some of the features that we have used and will continue to use with TestNG. Dependent methods is a good example. For the metrics aggregation tests in RHQ, there are tests for computing the 1 hr metrics, and there are tests for computing the 6 hr metrics. The 6 hr metrics test depends on the 1 hr metrics test. In JUnit the set up/tear down methods are considered part of the test fixture. In TestNG, they are configuration methods. This is a big difference because if a configuration method fails, then subsequent tests are skipped. This makes a lot of sense for integration tests. If I cannot create a connection to the database for example, then it is pointless to run the tests which rely on that connection. My understanding is that there were a couple reasons for the change - 1) Arquillian has better support for JUnit than for TestNG and 2) JUnit is more up to date than earlier versions like 3.x (e.g., annotation driven). hawkular-metrics does not use Arquillian so I do not care about 1) and 2) is not much of a reason. Unless JUnit provides similar capabilities, I prefer to keep integration/functional tests in TestNG for hawkular-metrics. [1] https://github.com/rhq-project/rhq-metrics/pull/101 <https://github.com/rhq-project/rhq-metrics/pull/101> - John

9 years, 3 months

2
1
0 / 0

embedding hawkular-metrics

by John Sanda

We already know from previous discussions that one of the use cases for metrics is embedding. There have been plenty of discussions with the WildFly team, notably with Heiko Braun, as well as discussions with the Fabric8 team about embedding metrics into their respective platforms. It has already been established that the dependency on JAX-RS prevents embedding the metrics UI components into the WildFly management console. Do we want to have a different, alternative stack for the embedded use case? An alternative stack would of course *not* depend on JAX-RS. It would maintain a smaller set of dependencies, and maybe more importantly it would require less and not more components/services from WildFly. I like the idea of a small stack with minimal dependencies, but I do not necessarily like the idea of maintaining one stack for embedded and another stack for other use cases. In other words, I do not want to maintain two implementations of the REST endpoints. Thoughts?

9 years, 3 months

6
11
0 / 0

How to work with the license plugin

by Peter Palaga

Hi *, Have you ever updated the copyright range after you changed a file? To spare us from the tedious manual work and to bring in consistency and standards required by Red Hat Legal dept., the license plugin was recently included [1] in metrics. Other projects will follow soon. Here here is a couple of recommendations how to work with the plugin: (1) Having the file templates up to date in your IDE can save you some work git clone https://github.com/hawkular/hawkular-build-tools.git cd hawkular-build-tools/ide-configs ... and import what is there. If your IDE is not supported, you are welcome to contribute a configuration. Nevertheless, one can work without an IDE support, see (2). (2) The license plugin is able to add/fix licenses as necessary. Just invoke mvn license:format in the root of your project (assuming license plugin is configured in the pom hierarchy.) (3) The license:check goal is now bound to validation phase in metrics. It can make your build fail. If you want to avoid the checks for any reason (reduce build time, known temporary inconsistencies, ...) feel free to build with -Dlicense.failOnMissing=false But note that Travis will fail if you push files that do not meet the standards. (4) From my sustaining engineer's experience, I can say that it is often handy to have non-code changes in separate commits. This holds not only for code formatting but also for copyright range updates. Please keep them separate if possible. A typical workflow might look like this: (i) code, build with -Dlicense.failOnMissing=false, commit as many times as you need (ii) mvn license:format; git commit -m "License headers added or fixed" (iii) git push ... ; hub pull-request ... Thanks, Peter [1] https://github.com/rhq-project/rhq-metrics/pull/132

9 years, 3 months

2
2
0 / 0

Demo about the Keycloak integration

by Juraci Paixão Kröhling

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All, As mentioned yesterday on the IRC channel, I'll be doing a demo tomorrow (Friday) at 16:00 UTC about the Keycloak integration. The topics will be mostly around what I've described on the wiki page[1] but I'll also show some code to explain where the changes are and how to use it. 1 - https://developer.jboss.org/wiki/KeycloakIntegration Around 15:50 UTC I'll be sending the link to the conference, which will probably take place as a Google Hangout, unless someone has objections. - - Juca. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUwM9jAAoJECKM1e+fkPrXdYgH/iUkPUy+IailX3+bPg1n8P4X 8iigT8Csgv9qf+qihUzf0p34VCq4J9IKo6DVdoO5OPET7GAuUQq65GEGzFRKeFpO W5vccLOu4YzzqIDG/sg4SAHc4t0r5Qnz7pBY4ZZvyqj/dRPpObE9beJPf5y97UK2 8UZz9qpVD8PbhTntAT3glaD62qwH6cD5lyONNgZzaEysvNIZ9eXgoo1X20sDrerb lswPNXickPim/h/R1Fql3JFWwejsUETvXilH0eDTk0WM+xyvadnYP+GyxGwbMT9g SAFjCOAXTErwg00lLMLHXqLkNk6QNGCrfCEh2GcA6bTIFy/EK7AM8rAJ0V0/aTA= =FT3o -----END PGP SIGNATURE-----

9 years, 3 months

2
1
0 / 0

UI Dev Changes (typescript version change from 1.3.0 to 1.4.1)

by mike thompson

If you are doing UI work in hawkular(rhq-metrics right now), the version of typescript has been bumped to version 1.4.1. This is reflected in the build so nothing is needed to be done. However, if you are doing UI dev work then you should update the version of typescript so that your IDE will pick up the new version. As a first step, I have changed the version but not added any typescript 1.4.1 syntax changes to minimize change as a first step. Syntax additions will find their way into the codebase soon though. To check which version you are using use ‘tsc —version’. If you are using npm to load typescript you can use the command ‘npm update typescript -g’ to update to the new version. — Mike

9 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

hawkular-dev January 2015