I am a Computer Science undergrad (sophomore) and am quite sound in Java. I
am new to open source contribution but would really like to contribute to
the JBoss community after seeing your projects in GSoC 2017. Any help would
As mentioned by John having a consistent pattern for our services and their
various pieces (cli, apb, ui) etc needs to be figured out.
*Single Repo: * We kinda ruled this one out as it unlikely it would work
well against 3rd part integrations such as 3scale or keycloak.
*Repo for each piece: *Lots of overhead and different repos. Off the top of
my head it would be:
- repo for any cli piece
- repo for client sdks (iOS, android, cordova) etc ..
- repo for APB
*Single Repo for clients*
- 1 repo for cli, sdks and (maybe UI too?)
- 1 repo for APB (not a client but is a deployment mechanism).
Any other or better options people can think of?
On 13 December 2017 at 08:55, Craig Brookes <cbrookes(a)redhat.com> wrote:
> Hey guys,
> *- Use a combination of configmaps and secrets to store public (ie client
> config) vs secret (ie credentials) when provisioning services via an APB*
> *- Use proposals for these kind of changes (ie where they are larger
> changes, breaking changes or changes in technical direction that have cross
> cutting concerns.)*
> *- As we have many pieces, setup aerogear/proposals repo.*
> I would like to suggest that we make use of a mixture of configmap and
> secrets during the provision of a mobile "aware" service.
> Currently when we provision a service we must also create a secret with a
> label: mobile:enabled and at least two pieces of information:
> - uri
> - name
> but it often contains more (such as username and password etc)
> This secret is used by the UI to represent that the service is present in
> the namespace and to display the credential information that allows the
> developer to sign into the service.
> During the PoC this secret was also used to populate the mobile client
> config. This meant filtering out fields that we did not want the mobile
> client to have access to.
> My suggestion is that we move to using an additional configmap labeled
> "mobile:enabled" that contains the public information that can be exposed
> to the mobile client as configuration and a secret still labeled
> "mobile:enabled" to capture other information such as the credentials for
> logging into the service.
> This really amounts to a proposal. Which brings me to the second
> question. Where to keep proposals? I would like us to standardise on have a
> public record of technical changes. These proposals should capture the
> 1) What
> 2) Why
> 3) How
> As an example here is a proposal that I put together for the ansible
> service broker:
> This shows the kind of level of detail that I believe we should be
> When is a proposal necessary? In my experience they are often used for
> larger changes, breaking changes or changes in technical direction that
> have cross cutting concerns. So in the case of my change outlined above, it
> is a breaking change that both the CLI and UI need to be aware of along
> with the developers of service APBs and so it should be a proposal.
> In the ansible service broker case the proposal is kept in the docs dir of
> the repo, however for something larger like Kubernetes they have a separate
> repo https://github.com/kubernetes/community.
> We could do something similar: aerogear/proposals with directories for
> each area
> - core
> - ui
> - cli
> - ide-extenstions
> - services
> - apbs
> - push
> - sync
> I think this would allow the owner or gatekeeper of the proposal to be
> clearly identified.
> Interested in hearing thoughts and opinions
> Craig Brookes
> @maleck13 Github
> feedhenry-dev mailing list
Red Hat Mobile
IRC: @irldavem (feedhenry, mobile-internal)
I had a few issues getting stuff running (ASB / MCP).
The thing that helped me to fix the issue, was really nuking the content of
the "/var/lib/origin" folder - that was full w/ lot's of stuff
Project lead AeroGear.org
re-replying with aerogear-dev jboss mailing list
On 11 December 2017 at 16:47, David Martin <davmarti(a)redhat.com> wrote:
> Nice video Phil!
> For anyone wondering about how the proxy stuff works,
> we're using this application here https://github.com/openshift/oauth-proxy
> It can sit in front of anything as a reverse proxy, providing
> authentication (& authorisation via a Subject Access Review request to
> It wasn't shown in this video, but the Prometheus Dashboard can also be
> accessed via an oauth proxy.
> Prometheus doesn't provide any auth at all, so the proxy provides a very
> useful service on a publicly exposed route.
> One other thing that wasn't shown in this video, but was alluded to (and
> mentioned in a separate video. See https://www.redhat.com/
> was the service discovery mechanism prometheus used.
> The fh-sync-server has a particular annotation, which proemthues looks
> for. It then starts gathering metrics from the /metrics endpoint in
> WRT Grafana, although 2 default dashboards were included with it
> (Promtetheus & fh-sync-server), the user is free to add their own
> dashboards or tweak the existing ones.
> On 11 December 2017 at 16:29, Phil Brookes <pbrookes(a)redhat.com> wrote:
>> Hey Everyone,
>> I have put together a video demonstrating the latest developments in
>> metrics for 5.x using Grafana to render the metrics stored in Prometheus.
>> Dave Martin and I have been working on this over the course of the last
>> This video also demonstrates the OpenShift Subject Access Review rules
>> that can be used to restrict / allow access to services.
>> Prometheus is also using service discovery in this demo to find the
>> services it can scrape metrics for.
>> Any questions or comments, please let me know.
>> feedhenry-dev mailing list
> David Martin
> Red Hat Mobile
> Twitter: @irldavem
> IRC: @irldavem (feedhenry, mobile-internal)
Red Hat Mobile
IRC: @irldavem (feedhenry, mobile-internal)
I had put in the wrong address for aerogear-dev by mistake!
---------- Forwarded message ----------
From: Phil Brookes <pbrookes(a)redhat.com>
Date: Mon, Dec 11, 2017 at 4:29 PM
Subject: Demostration video of Openshift SAR, Grafana and Prometheus in
To: feedhenry-dev(a)redhat.com, aerogear-dev(a)redhat.com
I have put together a video demonstrating the latest developments in
metrics for 5.x using Grafana to render the metrics stored in Prometheus.
Dave Martin and I have been working on this over the course of the last
This video also demonstrates the OpenShift Subject Access Review rules that
can be used to restrict / allow access to services.
Prometheus is also using service discovery in this demo to find the
services it can scrape metrics for.
Any questions or comments, please let me know.
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 ?
* total number MY of push messages ?
* total number MY of push applications ?
* total number MY of devices ?