Prometheus metrics for UPS
by Matthias Wessendorf
Hi,
for version 1.2.x I want to look into adding a 'simple' /metrics endpoint
that returns some stats in a prometheus compliant format.
Questions, what should we expose ?
GLOBAL (for admin user)?
* total number of push messages ?
* total number of push applications ?
* total number of devices ?
similar per user - that she sees the stats for her own stuff ?
e.g.
* total number MY of push messages ?
* total number MY of push applications ?
* total number MY of devices ?
Thoughts ?
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
twitter: http://twitter.com/mwessendorf
8 years
Upstream Community Documentation
by Paul Wright
Hi AeroGear, FeedHenry
As part of a review of Digger (Build Farm) docs, I created a PR
<https://github.com/aerogear/aerogear.org/pull/687> to attempt to
improve user navigation of:
https://aerogear.org/
Feedback on that PR raised the question of general navigation of this
web site:
* What should be in the Getting Started menu to help me get started with
digger? (I think digger is more than a code snippet or library)
* If I'm interested in digger, should I expect any digger info under
module or platform menu items?
* I sometimes navigate to a page, but can't remember how I navigated to
it, then cannot find the info again.
These issues can be resolved, but will require a lot of effort, but
another question is:
* Will it provide us a platform to build the community we want?
The web site looks great, and I learn a lot from browsing it (eg I
didn't know about https://aerogear.org/sync/ until today), but I wonder
if it is doing the job we want it to do? and how do we keep it
up-to-date? (https://aerogear.org/docs/planning/
<https://aerogear.org/docs/planning/>)
Meanwhile over at:
http://feedhenry.org/docs/
Not much there at the moment, but it will be the location for
mobile.next doc
* Do we want users switching from MCP doc on feedhenry.org
<http://feedhenry.org> over to digger doc on aerogear.org
<http://aerogear.org> and back again for some fh.sync doc?
These are difficult and challenging questions, I don't expect them to be
easy to resolve and I'm happy to agree with whatever the communities
decide to do. All this mail hopes to do is to raise the question of
* How do we communicate the "mobile.next" (i.e. feedhenry mcp and
aerogear digger) message as cleanly as possible?
(The real challenge occurs after that, convincing them to adopt
mobile.next, but users will never adopt if they can't find answers they
hit the first stumbling block)
thanks,
Paul
8 years, 1 month
Handy mr commands for updating all apb repos
by David Martin
For future handiness,
If you've already run 'mr register' in each of the cloned apb repos (e.g
https://github.com/feedhenry/unifiedpush-apb), here's some commands to
update the same file in each repo, and create a PR.
In this case, it was updating the apb tools image name.
# Checkout master, update it, then checkout a new branch
mr run git checkout master
mr run git pull origin master
mr run git checkout -b update-apb-tools-image
# Replace the image name in the Makefile
mr run sed -i
's/ansibleplaybookbundle\/apb/ansibleplaybookbundle\/apb-tools/' Makefile
# Add, Commit and push
mr run git add Makefile
mr run git commit -m "Update the apb image to use apb-tools"
mr run git push origin update-apb-tools-image
# Create the pull requests
mr run hub pull-request -b feedhenry:master -m "Update the apb image to use
apb-tools"
.....
[1] https://myrepos.branchable.com/
[2[ https://github.com/github/hub
--
David Martin
Red Hat Mobile
Twitter: @irldavem
IRC: @irldavem (feedhenry, mobile-internal)
8 years, 1 month
