Sync Day 3 Sync takes Manhattan
by Summers Pittman
I rolled up the feedback to the email I sent yesterday.
One quick note, this is not a 0.1.0 plan nor a 1.0.0 plan. It is
probably closer to a 1.5 or 2.0 plan in terms of scope. I tried to
order things and break out big "chunks" which will need to be done and
the approximate order they should be done in while also drawing a line
around what features we have. This is why I have not placed ANY
versions YET. By the end of today/tomorrow morning I hope that we will
be in a good place to do that.
Big changes from yesterday, User mgmt moved to M4. M6 (Sync Listener
Upgrading)was merged into M3(Push Listeners) so that we can have
optional push sooner.
# M1 - Basic revision Control, Data Model, Change Management, Server <->
Client Contract
* We seem to be in agreement on a basic set of metadata to be kept for
each object. [objectId, revision, object].
* We should have a basic server definition which supports CRUD and
keeps our revision numbers in check. This may not be a server product
but just a spec that can be implemented by anything at this point.
* We should have basic client code which keeps up with revisions, can
check the server for new revisions, and alert the user if there is a
sync conflict.
M2 - Sync Listener w/ Polling based sync listener, conflict management,
* We define on the client how callbacks will work for alerts when
remote data changes
* We implement a listener which polls a data source and delivers
changes to the user.
* We define how conflicts are managed
M3 - Push based Sync Listener, Sync Listener Strategy Management
* The client and server will negotiate when it is appropriate to
switch between polling, push, and realtime sync strategies.
* We will build on our previous Listener work from M2 to include a
Push listener that the server can speak to.
* We will support ways of automagically managing sync listeners based
on the availability of Push.
M4 - Server user management, Network Management, Server side session
management
* We will define in the client how network state and sync state
interact. IE how to handle errors in fetching new data when the
Listener is alerted. (Exponential back off, retry, etc)
* The server will need to have some mechanism for managing user
"sessions". This is what users are actively being synced.
* The server should have a basic authentication and authorization plan
for controlling how data is synced
M5 - "Real Time" Sync Listener. Bidirectional automatic sync
* Instead of using push, Realtime Sync uses something like web
sockects. to automatically sync local and remote data.
* Previous Sync listeners may have to be upgraded to include "upload"
abilities.
* We will also include the ability to switch between Realtime sync
listeners, polling listeners, and push listeners
* The server will need to support this as well.
M6 - Conflict resolution, Error detection and support
* Provide a more comprehensive strategy for managing conflicts.
* Provide some automated conflict resolvers
* The server could get a larger set of conflict and errors messages
M8 - Party
* We have a sync party.
10 years, 2 months
Sync Day 2: All our cars are frozen in ice
by Summers Pittman
I'm going to take some time to roll up yesterday's Sync Thread so we can
stop chasing down individual ideas.
Also I am going to propose a potential milestone conga line. I think
one of the things that keeps happening in these discussions is everyone
has an idea of what sync is but we don't really know what order things
should be done or released in.
If everyone likes this I'll slice things into JIRA epics.
# M1 - Basic revision Control, Data Model, Change Management, Server <->
Client Contract
* We seem to be in agreement on a basic set of metadata to be kept for
each object. [objectId, revision, object].
* We should have a basic server definition which supports CRUD and
keeps our revision numbers in check. This may not be a server product
but just a spec that can be implemented by anything at this point.
* We should have basic client code which keeps up with revisions, can
check the server for new revisions, and alert the user if there is a
sync conflict.
M2 - Sync Listener w/ Polling based sync listener, conflict management,
Serve user management
* We define on the client how callbacks will work for alerts when
remote data changes
* We implement a listener which polls a data source and delivers
changes to the user.
* We define how conflicts are managed
* The server should have a basic authentication and authorization plan
for controlling how data is synced
M3 - Push based Sync Listener, Network Management, Serverside session
management
* We will build on our previous Listener work from M2 to include a
Push listener that the server can speak to.
* We will define in the client how network state and sync state
interact. IE how to handle errors in fetching new data when the
Listener is alerted. (Exponential back off, retry, etc)
* The server will need to have some mechanism for managing user
"sessions". This is what users are actively being synced.
M4 - "Real Time" Sync Listener. Bidirectional automatic sync
* Instead of using push, Realtime Sync uses something like web
sockects. to automatically sync local and remote data.
* Previous Sync listeners may have to be upgraded to include "upload"
abilities.
* The server will need to support this as well.
M5 - Conflict resolution, Error detection and support
* Provide a more comprehensive strategy for managing conflicts.
* Provide some automated conflict resolvers
* The server could get a larger set of conflict and errors messages
M6 - Sync connection Upgrading
* The client and server will negotiate when it is appropriate to
switch between polling, push, and realtime sync strategies.
M7 - Party
* We have a sync party.
10 years, 2 months
Keycloak on AeroGear
by Bruno Oliveira
Good morning peeps, yesterday I started to replace AeroGear Security on Unified Push server by Keycloak and you might be asking: “Why?”. Keycloak is a SSO with some handy features like TOTP, OAuth2, user management support and I think we have too much to contribute, is the only way to have some success with security, “divide to conquer" (at least for authorization and authentication).
So will ag-security be discontinued? No! Keycloak is still on Alpha and we have to test it against our projects before fully replace ag-security, but the only way to upstream our needs, is to using it.
This replacement only applies to authentication/authorization features, we still have a ton of projects which Keycloak is not able to replace like: TOTP, crypto and OAuth2 on mobile, our focus.
- PoC
So let’s talk about this replacement, any dependency on ag-security was removed from the push server and replaced by Keycloak: https://github.com/abstractj/aerogear-unifiedpush-server/tree/o...
Based on Keycloak examples, I just did copy & paste from one of the demos (https://github.com/abstractj/auth-server/tree/openshift) to create a server. Keycloak requires Resteasy 3.0.4, for this reason I had to manually replace some modules on JBoss.
To test it go to: http://push-abstractj.rhcloud.com/ag-push/ you must be redirected to Keycloak, enter:
username: john(a)doe.com
password: password
You must be redirected to agpush console, keep in mind that I took some shortcuts to get this demo working, so for example the create will fail because I removed everything related into the ember interface.
Is also possible to enable TOTP, user’s registration and whatever you want.
So what do you think?
--
abstractj
10 years, 2 months
Aerogear Cordova Push Plugin
by Burr Sutter
https://github.com/aerogear/aerogear-pushplugin-cordova/
My project/notes in the readme.md - it could be that I have missed a step, so I tried to describe my steps carefully in the readme, everything from the command line right now - I will attempt JBoss Tools once the command line steps seem to work.
https://github.com/burrsutter/hellopush
I have also tested with
https://github.com/edewit/aerogear-pushplugin-cordova/tree/agdroid-195
It only works on Android 4.3, funny enough that was the first device I tried - perhaps there is some "affinity" for a single device? :-)
It fails on:
Android 2.3.4
Android 4.4.2 (two different devices)
iOS 6.1.5
iOS 7.0.4
Let's define "fail":
- the app always deploys but...
- the additional devices never register a device token in the UPS console. I assume I will see "instances" for the various devices
- in the case of iOS, the deviceready does not even fire correctly
- in the case of Android (all versions), the onError handler is called with "no value for pushconfig" - including the 4.3 where things do work.
10 years, 2 months
Upgrading process for the OpenShift AeroGear UPS cartridge
by Andrea Vibelli
Hello all,
I just wanted to let you know that Farah is working on AGPUSH-504, a snapshot/restore approach for upgrading the downloadable cartridge.
The overall idea is to take a snapshot of the database (and other configuration) for an older existing cartridge instance, delete this old instance, and then create a new instance based on the latest cartridge version and restore the new instance's database (and other configuration) to the state in the snapshot. The new instance must have the same name as the old instance. The main thing that she needed to determine was what needed to be included in the snapshot that's not already part of the MySQL database. The SimplePush token key was one of these things (we generate this value when a cartridge instance is created and it is used by the server for encryption and decryption of endpoint URLs). The standalone.xml file also needed to be backed up just in case the user made any changes to it. (Creating a backup of this file allows users to manually merge back any changes they may have made.)
The snapshot/restore action hooks she has created can be found in [1].
The steps she has been using to try upgrading from an 0.8.1 instance are listed below. It would be great if you could try out these steps as well. There's one important caveat though: because an 0.8.1 instance won't have the necessary snapshot hook, you'll need to manually perform some commands to save the necessary data (step 3 below). If we include these snapshot/restore action hooks in the 0.10.0 cartridge release, users will be able to make use of these hooks for future upgrades, e.g., for upgrading from 0.10.0 to 0.11.0.
1) Create an 0.8.1 cartridge instance
rhc create-app mypush "https://cartreflect-claytondev.rhcloud.com/reflect?github=aerogear/opensh..." mysql-5.1
2) Log into the admin console, change password, create push applications, create variants, send push notifications, etc.
3) ssh into your instance and perform these commands (this step manually captures needed data)
echo "$OPENSHIFT_AEROGEAR_PUSH_TOKEN_KEY" > $OPENSHIFT_DATA_DIR/aerogear_push_token_key
cp $OPENSHIFT_AEROGEAR_PUSH_DIR/standalone/configuration/standalone.xml $OPENSHIFT_DATA_DIR/standalone.snapshot.xml
4) Create a snapshot of the 0.8.1 instance: rhc snapshot save mypush
5) Delete the 0.8.1 instance: rhc app delete mypush
6) Delete the local directory on the local machine (from step 1, you should have a directory named 'mypush')
7) Create a new cartridge instance (this uses her fork of the 0.9.0 cartridge repository that contains the snapshot/restore action hooks)
rhc create-app mypush "https://cartreflect-claytondev.rhcloud.com/reflect?github=fjuma/openshift..." mysql-5.1
8) Restore the instance: rhc snapshot restore mypush -f /PATH/TO/mypush.tar.gz
9) You should now be able to log into the admin console with the same password you previously set, see existing push applications, variants, send push notifications, etc.
One disadvantage of this snapshot/restore approach is the extra work for the user. It would be nice to have a single command that can do the snapshot, delete, create, and restore all at once. She is going to start looking into this "wrappering" functionality.
Why am I writing about this?
I have made some test about the above steps. At a first glance, it seemed that something was broken between steps 6 and 7.
Doing various tests, what I saw in the logs (server.log) were different errors:
2014/01/26 10:19:18,061 ERROR [org.jboss.as] (MSC service thread 1-3) JBAS015875: JBoss AS 7.1.1.Final "Brontes" started (with errors) in 296088ms - Started 349 of 524 services (52 services failed or missing dependencies, 119 services are passive or on-demand)
2014/01/26 10:19:18,344 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS015870: Deploy of deployment "ROOT.war" was rolled back with failure message {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"ROOT.war#unifiedpush-default\"jboss.naming.context.java.jboss.datasources.PushEEDSMissing[jboss.persistenceunit.\"ROOT.war#unifiedpush-default\"jboss.naming.context.java.jboss.datasources.PushEEDS]","jboss.persistenceunit.\"ROOT.war#picketlink-default\"jboss.naming.context.java.jboss.datasources.PushEEDSMissing[jboss.persistenceunit.\"ROOT.war#picketlink-default\"jboss.naming.context.java.jboss.datasources.PushEEDS]"]}
2014/01/26 10:19:19,390 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015877: Stopped deployment ROOT.war in 1125ms
2014/01/26 10:19:19,393 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 2) JBAS014774: Service status report
JBAS014775: New missing/unsatisfied dependencies:
service jboss.naming.context.java.jboss.datasources.PushEEDS (missing) dependents: [service jboss.persistenceunit."ROOT.war#unifiedpush-default", service jboss.persistenceunit."ROOT.war#picketlink-default"]
2014/01/26 10:19:19,440 ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) {"JBAS014653: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-2" => {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"ROOT.war#unifiedpush-default\"jboss.naming.context.java.jboss.datasources.PushEEDSMissing[jboss.persistenceunit.\"ROOT.war#unifiedpush-default\"jboss.naming.context.java.jboss.datasources.PushEEDS]","jboss.persistenceunit.\"ROOT.war#picketlink-default\"jboss.naming.context.java.jboss.datasources.PushEEDSMissing[jboss.persistenceunit.\"ROOT.war#picketlink-default\"jboss.naming.context.java.jboss.datasources.PushEEDS]"]}}}
OR
2014/01/26 05:41:46,522 INFO [org.jboss.as.connector] (MSC service thread 1-1) JBAS010408: Starting JCA Subsystem (JBoss IronJacamar 1.0.9.Final)
2014/01/26 05:41:46,922 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 62) Operation ("enable") failed - address: ([
("subsystem" => "datasources"),
("data-source" => "PostgreSQLDS")
]) - failure description: "JBAS014802: Cannot resolve expression 'expression \"jdbcostgresql://${env.OPENSHIFT_POSTGRESQL_DB_HOST}:${env.OPENSHIFT_POSTGRESQL_DB_PORT}/mypush13\"' -- java.lang.IllegalStateException: Failed to resolve expression: ${env.OPENSHIFT_POSTGRESQL_DB_HOST}"
OR
no errors in the logs, but in the deployments directory I found 'ROOT.war.dodeploy' and 'ROOT.war.isdeploying' files, but no 'ROOT.war.deployed' file.
Those error seemed to me as random and too strange (by the way, the creation of the cartridge is always correct, I never had problems if I created a new instance with a never used before name).
To investigate further, I then tried to do the same steps with a completely different application: 'Kitchensink on OpenShift', and I had the same error! After the deletion and the recreation of a cartridge with a same name, I encountered: 'The requested URL /app was not found on this server.'
The steps I have done are:
1) rhc app create -a kitchensink -t jbossas-7 --from-code git://github.com/openshift/kitchensink-example.git
2) rhc snapshot save kitchensink
3) rhc app delete kitchensink
4) rm -rf kitchensinkhtml5/
5) rhc app create -a kitchensink -t jbossas-7 --from-code git://github.com/openshift/kitchensink-example.git
6) Access to the application.
So the good news is that the error I encountered is not related to this specific AeroGear cartridges, but the bad news is that is something more general about OpenShift.
We need to investigate further and find out if there is a way to "flush" the deletion, it seems that there is something appended or cached that prevent the recreation of a cartridge with a same name.
We are currently doing some more tests on these process.
10 years, 2 months
Data Sync Thoughts
by Lucas Holmquist
yup, this is another Data Sync thread,
>From a client side perspective, i have concerns that there is still not a clear direction yet.
I know there are multiple ideas floating around on what our model should be, i'm all for choice, but what about deciding on 1 model to get started with. Then later once we have this nailed down, we can have other "adapters" with different models perhaps
10 years, 2 months
Browser Targets
by Lucas Holmquist
So after looking at the Global stats for browsers( desktop ), it looks like IE 9 is below 4%
I think we need to consider dropping this support. I've been +9001 from the beginning but now that it is this low, i'm +9002
on this same topic, what % should we be looking at when thinking about dropping support for other platforms, like android and iOS
link to the stats:
http://gs.statcounter.com/#browser_version_partially_combined-ww-monthly-...
10 years, 2 months
Website suggestion: Team members page
by Hylke Bons
Hey,
What does everyone think about having a team members page on the website?
I think it would be good for community engagement.
It would have profile pictures, and maybe 2-3 lines about who you are
and what you are doing on the project. It doesn't have to go in-depth.
Maybe links to blogs and Twitter accounts would be nice too.
Something like: http://openstack.redhat.com/People
Let me know what you think.
Hylke
10 years, 3 months
