GSoC 2018
by Hardik Vijayvargiya
Hi,
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
be appreciated.
Thanks
8 years
Separate APB org or just separate repo
by Craig Brookes
As mentioned by John having a consistent pattern for our services and their
various pieces (cli, apb, ui) etc needs to be figured out.
The options:
*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?
--
Craig Brookes
RHMAP
@maleck13 Github
8 years
Re: [aerogear-dev] [feedhenry-dev] APB service provision using secrets and configmaps and proposals in general
by David Martin
including aerogear-dev
On 13 December 2017 at 08:55, Craig Brookes <cbrookes(a)redhat.com> wrote:
> Hey guys,
>
> *tldr*
> *- 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
> following:
> 1) What
> 2) Why
> 3) How
> As an example here is a proposal that I put together for the ansible
> service broker:
> https://github.com/openshift/ansible-service-broker/blob/
> master/docs/proposals/last-operation-description.md
> This shows the kind of level of detail that I believe we should be
> capturing.
> 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
> RHMAP
> @maleck13 Github
>
> _______________________________________________
> feedhenry-dev mailing list
> feedhenry-dev(a)redhat.com
> https://www.redhat.com/mailman/listinfo/feedhenry-dev
>
>
--
David Martin
Red Hat Mobile
Twitter: @irldavem
IRC: @irldavem (feedhenry, mobile-internal)
8 years, 1 month
Openshift issues
by Matthias Wessendorf
Hi,
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
-M
--
Project lead AeroGear.org
8 years, 1 month
Re: [aerogear-dev] [feedhenry-dev] Demostration video of Openshift SAR, Grafana and Prometheus in OpenShift
by David Martin
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
> openshift).
>
> 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/
> archives/feedhenry-dev/2017-November/msg00023.html)
> 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
> fh-sync-server.
>
> 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
>> week.
>>
>> 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.
>>
>> https://youtu.be/-37OPXXhrTw
>>
>> Any questions or comments, please let me know.
>>
>> Regards,
>> Phil.
>>
>>
>> _______________________________________________
>> feedhenry-dev mailing list
>> feedhenry-dev(a)redhat.com
>> https://www.redhat.com/mailman/listinfo/feedhenry-dev
>>
>>
>
>
> --
> David Martin
> Red Hat Mobile
> Twitter: @irldavem
> IRC: @irldavem (feedhenry, mobile-internal)
>
--
David Martin
Red Hat Mobile
Twitter: @irldavem
IRC: @irldavem (feedhenry, mobile-internal)
8 years, 1 month
Fwd: Demostration video of Openshift SAR, Grafana and Prometheus in OpenShift
by Phil Brookes
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
OpenShift
To: feedhenry-dev(a)redhat.com, aerogear-dev(a)redhat.com
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
week.
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.
https://youtu.be/-37OPXXhrTw
Any questions or comments, please let me know.
Regards,
Phil.
8 years, 1 month
