About configuration
by Chris Pitman
Hey guys,
I'm a bit late to the party, but here are my two cents as someone who has spent
months integrating Puppet with EAP 6 ( https://github.com/cpitman/puppet-jboss_admin ).
> > > 3) Why not try to have all our configuration set in standalone.xml? If we > > > are going to be deployed in Wildfly, it would be nice to have everything > > > (not just our config, but the config for the wildfly subsystems too) in > > > one place. This also allows us to piggyback on jboss-cli - we simply use
> > > the jboss-cli to have a cmdline interface to our configuration.
> > > > I'd rather keep our apps config out the Wildfly config. > What is your reasoning for wanting to keep our apps config out of Wildfly config?
> The reason why I say it would be nice to use standalone.xml for our config is:
> 1) all configuration, for everything, is in one place. Remember JBoss 4, with all their many .xml config files? It was hard to manage, which is one reason why they went to a single .xml file (though, granted, I believe they are thinking about making it possible to import .xml files into the main config - don't know if that's available yet).
> 2) It gives us, for free, a CLI - we don't have to write and maintain one. If everything is in standalone.xml, we can use the JBoss CLI to look at our config and change it along with the rest of the wildfly subsystems.
The CLI is a painful way to automate deployment using declarative tools like Puppet.
If the goal is to make it easy to configure and deploy, files are superior. Yes,
standalone.xml is a file, but you can only edit it by shutting down the container
first (and scripting doing this in Puppet is also non-fun).
Not to say it impossible. The module I linked above could be used, but it is still
vastly more complicated than a solution that just needs a templated config file.
> 3) If our components consist of Wildfly Extensions, then this is how you configure that extension. So it would be natural to have all config (for the extension and the other pieces of the component) in the same place.
> 4) Address and port assignments. Right now, standalone.xml allows you to define socket binding groups - allowing a "one stop shop" to define all your port bindings. Adjusting the port-offset provides a nice way to easily offset ports so you can run multiple components on the same box. If we have different configs (that need to specify hostnames/ports), we now have multiple places where this is configured - thus opening up to possible conflicts plus just a pain to have to now go to different places to configure bindings. The port bindings in one place is nice for manageability.
> The one negative of this approach is if our components can run outside of being embedded in Wildfly, we lose all of the above. We would need our own configuration mechanism (and CLI) if we can run outside of WildFly.
> But I see alot of positives for putting our subsystem configuration in with the rest of WildFly subsystem configs.
Chris Pitman
Architect, Red Hat Consulting
DevOps Community of Practice Manager
9 years, 9 months
[Metrics] Python client and perspective from client developing..
by Michael Burman
Hi,
As we need clients to actually push data to our system (and that way to
get users & community), I've written one for the Python. I've tried to
follow what a normal contributor would do and just read the
documentation that's available. Short story - there isn't enough
documentation.
I don't think we reached a consensus yet where to push the client source
codes, so I haven't created a pull request for this and for that reason
haven't renamed the repository either. It is available from
https://github.com/burmanm/rhq-metrics-python-client with documentation.
I'll gladly take ideas, my Python most likely looks like some other
language written in Python syntax - but it works.
There are tests that trigger against the real hawkular-metrics server
(0.30.0-SNAPSHOT). Usually the Python client developers target a mocked
endpoint, but I decided to go after the real server as I believe our API
might still change and the documentation isn't a reliable reference
point. I tried to follow the documentation on
https://github.com/hawkular/hawkular-metrics/tree/master/api/metrics-api-...
but I had to revert in some cases to reading the source code on what was
really wanted, especially after receiving 400 / 500 error codes while
doing the testing (when the json looked like in the examples). I also
only created abilities that are defined on that page, as I have no idea
if rest of the undocumented REST APIs are actually there to stay or to
be removed.
Which brings me to the question, what parts of the API are stable at the
moment? There's counters and such which are not documented at all. We
have huge selection of endpoints for any client developer to implement,
perhaps too many of them. I can try to improve documentation, but even
then I would want to know what's going on. I heard alerts is getting
swagger-annotations, which is nice.
- Micke
9 years, 9 months
REST-api docs
by Heiko W.Rupp
Hey,
We should add the swagger annotations(*) to the rest-api to have
the documentation source where the rest-annotations live and not
in separate readme files, that get outdated pretty quickly.
The annotations are then processed by an annotation processor
and can be (via the one we have) be turned into xml , html, docbook.
In fact I can hack the processor to also emit AsciiDoc which then can
be easily added to the developer documentation.
RHQ has some pretty extensive usage of the swagger annotations -
the result in the JON documentation can be browsed here
https://access.redhat.com/documentation/en-US/Red_Hat_JBoss_Operations_Ne...
Heiko
*) Those are runtime annotations and do not require the servlet being
deployed or anything.
9 years, 9 months
Maven repositories in Hawkular Parent
by Peter Palaga
Hi Stefan,
what was your specific motivation for adding the JBoss Repos?
The topic was discussed before [1] with the result, that we will not
hard code any Maven repositories in Hawkular Parent. All we produce and
all we depend on should be on Maven Central.
The only inconvenience with Central is that JBoss Nexus is synced to
central once a day only. The ones wanting to rely on freshly released
artifacts are recommended to add JBoss Nexus to their settings.xml. This
holds also for CI jobs.
Thanks,
Peter
[1] on #hawkular on 2015-01-21, reasons against it are summed in
http://blog.sonatype.com/2009/02/why-putting-repositories-in-your-poms-is...
9 years, 9 months
Intro to Cassandra
by John Sanda
The following is a new meeting request:
Subject: Intro to Cassandra
Organizer: "John Sanda" <jsanda(a)redhat.com>
Location: bluejeans
Time: Friday, February 13, 2015, 10:00:00 AM - 11:00:00 AM GMT -05:00 US/Canada Eastern
Invitees: hawkular-dev(a)lists.jboss.org
*~*~*~*~*~*~*~*~*~*
I will cover topics such as,
* High availability
* Consistency
* Fault tolerance
* Data modeling
Assumes no prior knowledge of or experience with Cassandra.
---
Meeting URL: https://bluejeans.com/217788152
9 years, 9 months
nexus populated
by John Mazzitelli
(Almost) all our snapshots are now getting published to Nexus thanks to Stefan doing the grunt work.
However, inventory and pinger still need to be built locally (they are in different non-master branches, and their artifacts are not on nexus).
git clone git@github.com:pilhuhn/hawkular-inventory.git heiko-inv
cd heiko-inv
git co notifier
mvn clean install -DskipTests
git clone git@github.com:pilhuhn/hawkular.git heiko-hawk
cd heiko-hawk
git co pinger
mvn clean install -DskipTests
Once you do this, you can build the integration distribution, which is currently in hawkular repo under the branch mazz/integration-assembly:
git clone git@github.com:hawkular/hawkular.git
cd hawkular
git co mazz/integration-assembly
mvn clean install -Pdev
Go in target/wildfly*/bin and run standalone.sh to run the server. Its got bus, alerts, metrics, inventory, pinger and Cassandra running inside "the nest"
9 years, 9 months
REST ideas
by Viliam Rockai
Hi,
I'm looking at hawkular-inventory and I've got several comments (liveoak
legacy) which could apply on other rest endpoints, too:
1. I think it would be easier to use/get if we make it more
hierarchical. That means; instead of using two distinct URLs (resources
vs. resource) for lists (/hawkular/inventory/rest-test/resources/) and
entities (/hawkular/inventory/rest-test/resource/x1422733176502), we use
only one (/hawkular/inventory/rest-test/resources/x1422733176502).
2. Sometimes, in the docs, attribute called "name" is used, and referred
to, as an "id". Would it be possible and make sense to choose just one
notation and use it in the representation?
3. Usage of methods: When you want to create a metric, you use the PUT
method. What about unifying methods in some commonly used manner. Like
post for create, put for edit?
WDYT?
Viliam
9 years, 9 months
Alerts - Response Time and Downtime requirements
by Catherine Robson
Hi -
We see that alerting on response time and downtime are part of what we
hope to provide in the first iteration of Hawkular. We'd like to get
started on the designs related to alert definition/configuration. I'm
hoping that you can all share some of the requirements around alert
definitions that you think we need to have for Hawkular at this point.
I don't want to overdo it by looking at JON - I'd like to start simple.
Here's the requirements for the web console as I currently am thinking
of them, but would like the team to comment on them and add/remove
requirements as you see necessary.
Overall Alerts
As an administrator of a website, I would like to have all alerts sent
to me through e-mail.
Ad an administrator of a website, I would like to have all alerts sent
to me via text message.
Downtime
As an administrator of a website, I would like to configure Hawkular so
an alert is sent to me every time the system goes down.
As an administrator of a website, I would like to configure Hawkular so
an alert is only sent to me after the system is down for a certain
length of time, so I'm not alerted if there is a very minor downtime event.
Response time
As an administrator of a website, I would like to configure Hawkular to
alert me when my website's response time is slower than a threshold I
have set so I know there may be performance problems.
Are there any other "settings" to the alerts that we should be
considering at this point?
Thanks,
Catherine
--
Catherine Robson
User Experience Design
Red Hat JBoss Middleware
c: 978-944-3825
9 years, 9 months
[inventory] API beyond the MVP
by Lukas Krejci
Hey,
I just created a PR https://github.com/hawkular/hawkular-inventory/pull/10
with my idea about how the "true" inventory API could look like + an
implementation of that idea on top of Tinkerpop Blueprints graph API.
A lot of stuff is missing there but they should hopefully fit in the basic
picture outlined in the PR.
I kindly ask for your comments and ideas about it. It does not exactly follow
the ideas we were talking about in the various design talks but I think it
captures the essence of them.
Thanks,
Lukas
9 years, 9 months
