[aerogear-dev] Improving customization abilities of OpenShift cartridge

Karel Piwko kpiwko at redhat.com
Fri Oct 24 07:45:46 EDT 2014


Hello,

we had a discussion about technical details yesterday. Thanks Matthias
for surprising us by paying us a visit :-)

ad 1/ web.xml in openshift profile could change location of
keycloak.json and this file can be directly in cartridge, unlocked for
changes. Keycloak already supports loading that file from filesystem:

https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/servers/ups-as7/src/main/resources/openshift/web.xml
https://github.com/keycloak/keycloak/blob/master/integration/as7-eap6/adapter/src/main/java/org/keycloak/adapters/as7/KeycloakAuthenticatorValve.java#L98-L112

I can prepare PR for that and cartridge if you will.

ad 2/ Tadeas has a Poc with deploying LittleProxy [1] as another WAR
deployment in the cartridge and using rhc set-env to set JAVA_EXT_OPTS
to let EAP use that proxy. It works great with GCMs but not yet with
APNs, which uses sockets instead of HTTP/S, these in particular [2]. We
are investigating this, if you have any tips how to proxy SOCKS for Java
with least effort possible, please let us know. Or maybe we could expose
APNS proxy setup somehow in UPS configuration?

https://github.com/notnoop/java-apns/blob/master/src/main/java/com/notnoop/apns/ApnsServiceBuilder.java#L367-L450

Karel

[1] https://github.com/adamfisk/LittleProxy
[2]
https://github.com/notnoop/java-apns/blob/master/src/main/java/com/notnoop/apns/internal/Utilities.java#L60-L70


On Thu, 2014-10-23 at 16:11 +0200, Matthias Wessendorf wrote:
> yes, our cartridge will still function like that
> 
> I think what we can do for Karel, is have the realm.json file, for UPS so
> he and team can  import it into running keycloak.
> 
> Our cartridge will stay as is, at least that's my (current) understanding
> 
> On Thu, Oct 23, 2014 at 4:07 PM, Sebastien Blanc <scm.blanc at gmail.com>
> wrote:
> 
> > If we go for this let's make sure we have default values.
> > A lot of people might create an OpenShift App just using the online
> > interface and not clone it locally (and thus not modify the config files)
> >
> >
> > On Thu, Oct 23, 2014 at 2:06 PM, Matthias Wessendorf <matzew at apache.org>
> > wrote:
> >
> >>
> >>
> >> On Thu, Oct 23, 2014 at 1:51 PM, Matthias Wessendorf <matzew at apache.org>
> >> wrote:
> >>
> >>>
> >>>
> >>> On Wed, Oct 22, 2014 at 6:13 PM, Karel Piwko <kpiwko at redhat.com> wrote:
> >>>
> >>>> Hi All,
> >>>>
> >>>> I'd like to know your opinion on following changes to UnifiedPush
> >>>> Server. They are both focused on improving customization process for the
> >>>> cartridge.
> >>>>
> >>>> Just in short, current update process now:
> >>>> 1/ Clone official git repository of cartridge
> >>>> 2/ Extract wars and do the modifications or build ones
> >>>> 3/ Package wars
> >>>> 4/ Push cartridge to your own repository
> >>>> 5/ Create cartridge from your own repository
> >>>>
> >>>> Whereas, I'm proposing:
> >>>> 1/ Create cartridge from official repository
> >>>> 2/ Clone git repository for gear created by Openshift (by default if rhc
> >>>> is used)
> >>>> 3/ Modify some files there we expose for user modification
> >>>> 4/ Push back to make changes live
> >>>>
> >>>> What particular configuration elements I'm interested to have
> >>>> externalized?
> >>>>
> >>>> 1/ Ability to load keycloak.json from external location
> >>>>
> >>>> => This allows user to create cartridge and modify it prior the first
> >>>> access. This allows users to configure it to be consumable by other
> >>>> services automatically, e.g. they can add developer users, roles, etc.
> >>>>
> >>>
> >>> hrm, in theory, yeah, that could be possible. Perhaps Stian or abstractj
> >>> have an idea here
> >>>
> >>
> >> we could have our real in a JSON file, so that it is easy/easier to
> >> import it into an existing KC server, to run UPS against that
> >>
> >>
> >>>
> >>>
> >>>
> >>>>
> >>>> 2/ Externalize GCM/APNs locations
> >>>>
> >>>> => Now, URLs are hardcoded in GCM/APNs JARs.
> >>>
> >>>
> >>> yes, they are considered stable APIs :)
> >>>
> >>> We are not going to 'externalize' these URLs
> >>>
> >>>
> >>>> If they would be loaded
> >>>> from external location (defaults can still be hardcoded), this allows
> >>>> user to easily check business logic that queries data in UPS and not
> >>>> sending any messages. Also allows to put proxy in between UPS and
> >>>> APNs/GCMs.
> >>>>
> >>>> Both these will significantly reduce QE overhead. However, I believe
> >>>> they are valuable for other as well.
> >>>>
> >>>> Feedback and tomatoes (I prefer plum ones) are welcomed.
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Karel
> >>>>
> >>>> _______________________________________________
> >>>> aerogear-dev mailing list
> >>>> aerogear-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Matthias Wessendorf
> >>>
> >>> blog: http://matthiaswessendorf.wordpress.com/
> >>> sessions: http://www.slideshare.net/mwessendorf
> >>> twitter: http://twitter.com/mwessendorf
> >>>
> >>
> >>
> >>
> >> --
> >> Matthias Wessendorf
> >>
> >> blog: http://matthiaswessendorf.wordpress.com/
> >> sessions: http://www.slideshare.net/mwessendorf
> >> twitter: http://twitter.com/mwessendorf
> >>
> >> _______________________________________________
> >> aerogear-dev mailing list
> >> aerogear-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>
> >
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> 
> 
> 
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev




More information about the aerogear-dev mailing list