From pwright at redhat.com Thu Nov 2 10:42:40 2017 From: pwright at redhat.com (Paul Wright) Date: Thu, 2 Nov 2017 10:42:40 +0000 Subject: [feedhenry-dev] MCP Local Dev Message-ID: <54531b1b-7c8c-eb2b-4793-05d234e203e5@redhat.com> Hi, I'm trying to follow https://github.com/feedhenry/mcp-standalone/blob/master/docs/walkthroughs/local-setup.adoc I was getting? following during ansible-service-broker-setup: "error: unable to recognize servicecatalog.k8s.io/v1beta1, Kind=ClusterServiceBroker: no matches for servicecatalog.k8s.io/, Kind=ClusterServiceBroker", I think i worked around that by export DOCKERHUB_APBS_ORG="feedhenry" (altho that command was removed from doc) I'm now getting following? during ansible-service-broker-setup: ?"Error from server (AlreadyExists): project.project.openshift.io \"ansible-service-broker\" already exists", "stderr_lines": ["Error from server (AlreadyExists): project.project.openshift.io \"ansible-service-broker\" already exists"], Can anyone help me figure out how to debug? thanks, Paul From bsutter at redhat.com Thu Nov 2 14:24:19 2017 From: bsutter at redhat.com (Burr Sutter) Date: 2 Nov 2017 10:24:19 -0400 Subject: [feedhenry-dev] Upcoming Red Hat DevNation Live Tech Talk: Update your database schema with zero-downtime migrations Message-ID: Read the online version . "Red Hat" Hi RedHat, Join the Red Hat DevNation for an upcoming live session on November?16, 2017, as Edson Yanaga?presents Updating your Database Schema with Zero-Downtime Migrations. You joined the DevOps movement and want to release software even more quickly and safely. How do you achieve this multiple times per day without disrupting your users in production? Join this webinar to learn about a zero-downtime approach to migrations that considers: *Your data *Your relational database schema *While ?code is easy, data is hard,? it?s definitely possible and practical. Edson Yanaga is Red Hat's director of Developer Experience, a Java Champion, and a Microsoft MVP. He is also a published author and a frequent speaker at international conferences, discussing JavaTM, microservices, cloud computing, DevOps, and software craftsmanship. Yanaga considers himself a software craftsman and is convinced we all can create a better world for people with better software. He is passionate about helping developers worldwide more quickly and safely deliver better software. Register Now For more information and to view the schedule, click here . We hope you join us! Regards, Burr Sutter The Red Hat Developer Program __________________________________________________________________ [f1]Contact our sales team [f2]Manage your newsletter preferences [f3]Read our privacy policy [f4]Unsubscribe from all Red Hat email "Red Hat" and the "Shadowman" logo are trademarks or registered trademarks of Red Hat, Inc. Linux is a registered trademark of Linus Torvalds. ? 2016 Red Hat, Inc. All rights reserved. 100 East Davie Street Raleigh, NC 27601 [f5][twitter.png] [f6][facebook.png] [f7][redhat.png] References f1. http://www.redhat.com/apps/webform.html?event_type=contact_sales&eid=21 f2. https://www.redhat.com/wapps/ugc/email-subscriptions.html?elqc=241&elq=b0a37945ea2f4876b56ec1f8ec9d69c3 f3. http://www.redhat.com/legal/privacy_statement.html f4. https://www.redhat.com/wapps/ugc/master-unsubscribe.html?elqc=241&elq=b0a37945ea2f4876b56ec1f8ec9d69c3 f5. http://www.twitter.com/redhatnews f6. http://www.facebook.com/pages/Red-Hat/11218770329 f7. http://www.redhat.com/community/?sc_cid=70160000000I9TnAAK -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsutter at redhat.com Thu Nov 2 14:40:34 2017 From: bsutter at redhat.com (Burr Sutter) Date: 2 Nov 2017 10:40:34 -0400 Subject: [feedhenry-dev] =?utf-8?q?Join_us_today_for_a_tech_talk_on_Why_yo?= =?utf-8?q?u=E2=80=99re_going_to_fail_running_Java_on_Docker?= Message-ID: Read the online version . "Red Hat" Hi RedHat, Are you ready to attend the Red Hat DevNation live session, Why you?re going to fail running Java on Docker, presented by Rafael Benevides ? Join us today at 12 pm EST for this thirty minute session. Running Java? on Docker is easy, right? Just create a Dockerfile, run a Docker build and then you?re ready to go. This way of thinking is the easiest path to complete failure when running Docker containers in production. The JVM knows how to auto-tune itself to achieve the best possible performance in the environment in which it?s running. So far, that environment has been a single physical or virtual machine. But containers change everything?you need to know how containers manages their own resources, and you need to apply this knowledge when running and optimizing your JVM running in a container. In this session, you?ll learn: *The best way to run Java on Docker in production. *A lot about JVM and containers to avoid the highway to debugging hell. *Simple tips & tricks to save you many hours logging and debugging container problems. Register Now For more information and to view the schedule, click here . We hope you join us! Regards, Burr Sutter The Red Hat Developer Program __________________________________________________________________ [f1]Contact our sales team [f2]Manage your newsletter preferences [f3]Read our privacy policy [f4]Unsubscribe from all Red Hat email "Red Hat" and the "Shadowman" logo are trademarks or registered trademarks of Red Hat, Inc. Linux is a registered trademark of Linus Torvalds. ? 2016 Red Hat, Inc. All rights reserved. 100 East Davie Street Raleigh, NC 27601 [f5][twitter.png] [f6][facebook.png] [f7][redhat.png] References f1. http://www.redhat.com/apps/webform.html?event_type=contact_sales&eid=21 f2. https://www.redhat.com/wapps/ugc/email-subscriptions.html?elqc=241&elq=aa734c88ca0c46d5af841f75efff4d52 f3. http://www.redhat.com/legal/privacy_statement.html f4. https://www.redhat.com/wapps/ugc/master-unsubscribe.html?elqc=241&elq=aa734c88ca0c46d5af841f75efff4d52 f5. http://www.twitter.com/redhatnews f6. http://www.facebook.com/pages/Red-Hat/11218770329 f7. http://www.redhat.com/community/?sc_cid=70160000000I9TnAAK -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Thu Nov 2 17:23:52 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Thu, 2 Nov 2017 18:23:52 +0100 Subject: [feedhenry-dev] MCP: Openshift template's IMAGE_TAG Message-ID: Hi, https://github.com/feedhenry/mcp-standalone/blob/master/artifacts/openshift/template.json#L218 the above, on master - should that always point to latest, as we develop it? On the "release tag", it should match the actual version (e.g. 0.0.6 tag in GH, should have that as value in there") ? I think for the release process, we should try to automate that, like the maven release plugin manages the versions (e.g. actual version VS -SNAPSHOT versions) Suggestion/proposal: let's do a "mcp target" on the makefile: * have a target that combines these two things: https://github.com/feedhenry/mcp-standalone/blob/master/docs/Release.md#mcp-release * as an improvement, the target should change the "latest" to the value of the given TAG (w/ some 'sed' fu) * commit the change (to local master/release branch) * at the end: create a git tag, and push it * finally, change the value in the template back to "latest" (sed fu reloaded). and commit to master that way, we do not loose any commits, and things are fairly automated, with our Makefile Any thoughts? -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From akeating at redhat.com Fri Nov 3 09:57:21 2017 From: akeating at redhat.com (Aiden Keating) Date: Fri, 3 Nov 2017 09:57:21 +0000 Subject: [feedhenry-dev] MCP Demo - 3scale Service Message-ID: Hey everyone, We've recorded a demo about the work we've been doing recently on the 3scale service and using it with the Mobile Control Panel. The demo is pretty short. It includes setting up the 3scale service, integrating it with the FeedHenry Sync Service and taking a quick look at 3scale analytics. https://youtu.be/zuJQm9zxSjs Thanks, Aiden -------------- next part -------------- An HTML attachment was scrubbed... URL: From ngough at redhat.com Fri Nov 3 10:17:13 2017 From: ngough at redhat.com (Nano Gough) Date: Fri, 3 Nov 2017 10:17:13 +0000 Subject: [feedhenry-dev] MCP Demo - 3scale Service In-Reply-To: References: Message-ID: Well done Aiden - demo very well delivered & great to see the progress on the 3Scale product integration. On 3 November 2017 at 09:57, Aiden Keating wrote: > Hey everyone, > > We've recorded a demo about the work we've been doing recently on the > 3scale service and using it with the Mobile Control Panel. > > The demo is pretty short. It includes setting up the 3scale service, > integrating it with the FeedHenry Sync Service and taking a quick look at > 3scale analytics. > > https://youtu.be/zuJQm9zxSjs > > Thanks, > Aiden > -- Nano Gough Senior Principal Product Manager RedHat Mobile Tel (mob): +353 (0) 86 3651465 ngough at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bofarrel at redhat.com Fri Nov 3 10:19:40 2017 From: bofarrel at redhat.com (Brendan O'Farrell) Date: Fri, 3 Nov 2017 10:19:40 +0000 Subject: [feedhenry-dev] MCP Demo - 3scale Service In-Reply-To: References: Message-ID: Thanks Aiden Excellent video Cheers On Fri, Nov 3, 2017 at 9:57 AM, Aiden Keating wrote: > Hey everyone, > > We've recorded a demo about the work we've been doing recently on the > 3scale service and using it with the Mobile Control Panel. > > The demo is pretty short. It includes setting up the 3scale service, > integrating it with the FeedHenry Sync Service and taking a quick look at > 3scale analytics. > > https://youtu.be/zuJQm9zxSjs > > Thanks, > Aiden > -- BRENDAN O'FARRELL ASSOCIATE ENGINEERING MANAGER, MOBILE Red Hat Ireland Communications House, Cork Road Waterford, Ireland. X91 NY33 bofarrel at redhat.com T: 00353518260110 M: 00353868143848 IM: @bofarrel TRIED. TESTED. TRUSTED. -------------- next part -------------- An HTML attachment was scrubbed... URL: From psturc at redhat.com Fri Nov 3 10:27:50 2017 From: psturc at redhat.com (Pavel Sturc) Date: Fri, 3 Nov 2017 11:27:50 +0100 Subject: [feedhenry-dev] MCP Demo - 3scale Service In-Reply-To: References: Message-ID: Very nicely done, Aiden. Cool video! On Fri, Nov 3, 2017 at 11:19 AM, Brendan O'Farrell wrote: > Thanks Aiden > > Excellent video > > Cheers > > On Fri, Nov 3, 2017 at 9:57 AM, Aiden Keating wrote: > >> Hey everyone, >> >> We've recorded a demo about the work we've been doing recently on the >> 3scale service and using it with the Mobile Control Panel. >> >> The demo is pretty short. It includes setting up the 3scale service, >> integrating it with the FeedHenry Sync Service and taking a quick look at >> 3scale analytics. >> >> https://youtu.be/zuJQm9zxSjs >> >> Thanks, >> Aiden >> > > > > -- > > BRENDAN O'FARRELL > > ASSOCIATE ENGINEERING MANAGER, MOBILE > > Red Hat Ireland > > Communications House, Cork Road > > Waterford, Ireland. X91 NY33 > > bofarrel at redhat.com T: 00353518260110 M: 00353868143848 IM: > @bofarrel > > TRIED. TESTED. TRUSTED. > > -- Regards, PAVEL STURC QUALITY ENGINEER Red Hat Mobile Application Platform psturc at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbrookes at redhat.com Fri Nov 3 15:51:30 2017 From: pbrookes at redhat.com (Phil Brookes) Date: Fri, 3 Nov 2017 15:51:30 +0000 Subject: [feedhenry-dev] Istio demo video Message-ID: Hey Everyone, I?ve finished putting the demo video together. The content is very similar to what was covered in the earlier live demo. https://drive.google.com/a/redhat.com/file/d/1M58uJo1y1N72olUEMupINegqkeP_24NY/view?usp=sharing Any questions, let me know. Regards, Phil. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From gryan at redhat.com Sat Nov 4 12:05:24 2017 From: gryan at redhat.com (Gerard Ryan) Date: Sat, 04 Nov 2017 12:05:24 +0000 Subject: [feedhenry-dev] Istio demo video In-Reply-To: (Phil Brookes's message of "Fri, 3 Nov 2017 15:51:30 +0000") References: Message-ID: <87a8026ygr.fsf@thinkpad.grdryn.redhat> Great demo Phil! From damurphy at redhat.com Mon Nov 6 11:41:26 2017 From: damurphy at redhat.com (Damien Murphy) Date: Mon, 6 Nov 2017 11:41:26 +0000 Subject: [feedhenry-dev] MCP Local Dev In-Reply-To: <54531b1b-7c8c-eb2b-4793-05d234e203e5@redhat.com> References: <54531b1b-7c8c-eb2b-4793-05d234e203e5@redhat.com> Message-ID: Hi Paul, I found running a make clean and then doing a re-install helped with some install issues (if the clean won?t run as some of the pods are still locked, running sudo umount for each of the problematic pods will then let you run the make clean), Damien ? On 2 November 2017 at 10:42, Paul Wright wrote: > Hi, > > I'm trying to follow > > https://github.com/feedhenry/mcp-standalone/blob/master/docs > /walkthroughs/local-setup.adoc > > I was getting following during ansible-service-broker-setup: > > "error: unable to recognize servicecatalog.k8s.io/v1beta1, > Kind=ClusterServiceBroker: no matches for servicecatalog.k8s.io/, > Kind=ClusterServiceBroker", > > I think i worked around that by export DOCKERHUB_APBS_ORG="feedhenry" > (altho that command was removed from doc) > > I'm now getting following during ansible-service-broker-setup: > > > "Error from server (AlreadyExists): project.project.openshift.io > \"ansible-service-broker\" already exists", "stderr_lines": ["Error from > server (AlreadyExists): project.project.openshift.io > \"ansible-service-broker\" already exists"], > > Can anyone help me figure out how to debug? > > thanks, > > Paul > > > > > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > -- DAMIEN MURPHY SOFTWARE ENGINEER Red Hat Mobile IM: damurphy -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwright at redhat.com Mon Nov 6 12:43:20 2017 From: pwright at redhat.com (Paul Wright) Date: Mon, 6 Nov 2017 12:43:20 +0000 Subject: [feedhenry-dev] MCP Local Dev In-Reply-To: References: <54531b1b-7c8c-eb2b-4793-05d234e203e5@redhat.com> Message-ID: <0c671f98-58b2-82b6-105a-39597b26f8d1@redhat.com> Thanks Damien, got it running on two laptops after this tip (each laptop was giving different error, but now both running), Paul On 11/06/2017 11:41 AM, Damien Murphy wrote: > > Hi Paul, > > I found running a |make clean| and then doing a re-install helped with > some install issues (if the clean won?t run as some of the pods are > still locked, running |sudo umount | for each of the > problematic pods will then let you run the |make clean|), > > Damien > > ? > > On 2 November 2017 at 10:42, Paul Wright > wrote: > > Hi, > > I'm trying to follow > > https://github.com/feedhenry/mcp-standalone/blob/master/docs/walkthroughs/local-setup.adoc > > > I was getting? following during ansible-service-broker-setup: > > "error: unable to recognize servicecatalog.k8s.io/v1beta1 > , Kind=ClusterServiceBroker: > no matches for servicecatalog.k8s.io/ > , Kind=ClusterServiceBroker", > > I think i worked around that by export > DOCKERHUB_APBS_ORG="feedhenry" (altho that command was removed > from doc) > > I'm now getting following? during ansible-service-broker-setup: > > > ?"Error from server (AlreadyExists): project.project.openshift.io > \"ansible-service-broker\" > already exists", "stderr_lines": ["Error from server > (AlreadyExists): project.project.openshift.io > \"ansible-service-broker\" > already exists"], > > Can anyone help me figure out how to debug? > > thanks, > > Paul > > > > > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > > > > > -- > > DAMIEN MURPHY > > SOFTWARE ENGINEER > > > > Red Hat?Mobile > > IM:?damurphy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jstaffor at redhat.com Mon Nov 6 16:05:15 2017 From: jstaffor at redhat.com (John Stafford) Date: Mon, 6 Nov 2017 16:05:15 +0000 Subject: [feedhenry-dev] python-paramiko & sshpass dependencies Message-ID: Hi, Attempting to get Ansible running as part of installing MCP however, I hit the following issues: [ [jstaffor at jstaffor Downloads]$ rpm -i ansible-2.4.0.0-1.el7.ans.noarch.rpm warning: ansible-2.4.0.0-1.el7.ans.noarch.rpm: Header V4 RSA/SHA1 Signature, key ID 442667a9: NOKEY error: Failed dependencies: PyYAML is needed by ansible-2.4.0.0-1.el7.ans.noarch python-jinja2 is needed by ansible-2.4.0.0-1.el7.ans.noarch python-paramiko is needed by ansible-2.4.0.0-1.el7.ans.noarch sshpass is needed by ansible-2.4.0.0-1.el7.ans.noarch ] The first two were straight forward fixes however, I'm getting lost down 'rabbit holes' with the last two. Anyone know a straight forward way of obtaining these dependencies? BTW - I'm running RHEL 7.4 CSB (rooted) -- JOHN STAFFORD TECHNICAL WRITER, CCS Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: From gryan at redhat.com Mon Nov 6 17:07:42 2017 From: gryan at redhat.com (Gerard Ryan) Date: Mon, 06 Nov 2017 17:07:42 +0000 Subject: [feedhenry-dev] python-paramiko & sshpass dependencies In-Reply-To: (John Stafford's message of "Mon, 6 Nov 2017 16:05:15 +0000") References: Message-ID: <8760an8hep.fsf@thinkpad.grdryn.redhat> John Stafford writes: > Hi, > > Attempting to get Ansible running as part of installing MCP however, I hit > the following issues: > > [ > > [jstaffor at jstaffor Downloads]$ rpm -i ansible-2.4.0.0-1.el7.ans.noarch.rpm > > warning: ansible-2.4.0.0-1.el7.ans.noarch.rpm: Header V4 RSA/SHA1 > Signature, key ID 442667a9: NOKEY > > error: Failed dependencies: > > PyYAML is needed by ansible-2.4.0.0-1.el7.ans.noarch > > python-jinja2 is needed by ansible-2.4.0.0-1.el7.ans.noarch > > python-paramiko is needed by ansible-2.4.0.0-1.el7.ans.noarch > > sshpass is needed by ansible-2.4.0.0-1.el7.ans.noarch > ] > > The first two were straight forward fixes however, I'm getting lost down > 'rabbit holes' with the last two. > > Anyone know a straight forward way of obtaining these dependencies? > > BTW - I'm running RHEL 7.4 CSB (rooted) Hi John, If you're on RHEL7, I don't think you should need to download an rpm and install it with rpm. You should be able to install it from the instructions here: https://access.redhat.com/articles/3174981 Note that there are two sets of instructions there: "If you have a Red Hat Ansible Engine Subscription", and "If you are a RHEL only Customer". Hope this helps, Gerard. From jstaffor at redhat.com Mon Nov 6 17:13:41 2017 From: jstaffor at redhat.com (John Stafford) Date: Mon, 6 Nov 2017 17:13:41 +0000 Subject: [feedhenry-dev] python-paramiko & sshpass dependencies In-Reply-To: <8760an8hep.fsf@thinkpad.grdryn.redhat> References: <8760an8hep.fsf@thinkpad.grdryn.redhat> Message-ID: Will give it ago - cheers Ger! On Mon, Nov 6, 2017 at 5:07 PM, Gerard Ryan wrote: > John Stafford writes: > > > Hi, > > > > Attempting to get Ansible running as part of installing MCP however, I > hit > > the following issues: > > > > [ > > > > [jstaffor at jstaffor Downloads]$ rpm -i ansible-2.4.0.0-1.el7.ans. > noarch.rpm > > > > warning: ansible-2.4.0.0-1.el7.ans.noarch.rpm: Header V4 RSA/SHA1 > > Signature, key ID 442667a9: NOKEY > > > > error: Failed dependencies: > > > > PyYAML is needed by ansible-2.4.0.0-1.el7.ans.noarch > > > > python-jinja2 is needed by ansible-2.4.0.0-1.el7.ans.noarch > > > > python-paramiko is needed by ansible-2.4.0.0-1.el7.ans.noarch > > > > sshpass is needed by ansible-2.4.0.0-1.el7.ans.noarch > > ] > > > > The first two were straight forward fixes however, I'm getting lost down > > 'rabbit holes' with the last two. > > > > Anyone know a straight forward way of obtaining these dependencies? > > > > BTW - I'm running RHEL 7.4 CSB (rooted) > > Hi John, > > If you're on RHEL7, I don't think you should need to download an rpm and > install it with rpm. You should be able to install it from the > instructions here: > > https://access.redhat.com/articles/3174981 > > Note that there are two sets of instructions there: "If you have a Red > Hat Ansible Engine Subscription", and "If you are a RHEL only > Customer". > > Hope this helps, > Gerard. > -- JOHN STAFFORD TECHNICAL WRITER, CCS Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: From eshortis at redhat.com Mon Nov 6 23:18:49 2017 From: eshortis at redhat.com (Evan Shortiss) Date: Mon, 6 Nov 2017 15:18:49 -0800 Subject: [feedhenry-dev] MCP Demo - 3scale Service In-Reply-To: References: Message-ID: Nice demo Aiden. Very developer friendly which is great. On Fri, Nov 3, 2017 at 3:27 AM, Pavel Sturc wrote: > Very nicely done, Aiden. > Cool video! > > On Fri, Nov 3, 2017 at 11:19 AM, Brendan O'Farrell > wrote: > >> Thanks Aiden >> >> Excellent video >> >> Cheers >> >> On Fri, Nov 3, 2017 at 9:57 AM, Aiden Keating >> wrote: >> >>> Hey everyone, >>> >>> We've recorded a demo about the work we've been doing recently on the >>> 3scale service and using it with the Mobile Control Panel. >>> >>> The demo is pretty short. It includes setting up the 3scale service, >>> integrating it with the FeedHenry Sync Service and taking a quick look at >>> 3scale analytics. >>> >>> https://youtu.be/zuJQm9zxSjs >>> >>> Thanks, >>> Aiden >>> >> >> >> >> -- >> >> BRENDAN O'FARRELL >> >> ASSOCIATE ENGINEERING MANAGER, MOBILE >> >> Red Hat Ireland >> >> Communications House, Cork Road >> >> Waterford, Ireland. X91 NY33 >> >> bofarrel at redhat.com T: 00353518260110 M: 00353868143848 IM: >> @bofarrel >> >> TRIED. TESTED. TRUSTED. >> >> > > > -- > Regards, > > PAVEL STURC > > QUALITY ENGINEER > > Red Hat Mobile Application Platform > > > psturc at redhat.com > > -- EVAN SHORTISS MOBILE DEVELOPER Red Hat NA Los Angeles evan.shortiss at redhat.com M: +1-781-354-2834 IM: @evanshortiss TRIED. TESTED. TRUSTED. @redhatnews Red Hat Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: From jstaffor at redhat.com Tue Nov 7 12:08:41 2017 From: jstaffor at redhat.com (John Stafford) Date: Tue, 7 Nov 2017 12:08:41 +0000 Subject: [feedhenry-dev] "Template service broker apiserver fails to start" during Ansible MCP startup Message-ID: Hi, 1) when I run "ansible-playbook playbook.yml -e "dockerhub_username= $DOCKERHUB_USERNAME" -e "dockerhub_password=$DOCKERHUB_PASSWORD" --ask-become-pass" 2) the execution gets as far as "TASK [oc-cluster-up : Cluster up] " and then terminates with an error[1] (after hanging for about 4-5 mins) 3) the docker image[2] in cockpit contains the the message "Unable to connect to the server: dial tcp 172.30.0.1:443: getsockopt: no route to host disconnected" Any ideas on how to troubleshoot/work around this? FYI - I completed a 'make clean' against the '/home/jstaffor/MCP/mcp-standalone/' folder and executed the command above again but unfortunately the same situation occurred. [1] ?Unable to connect to the server: dial tcp 172.30.0.1:443: getsockopt: no route to host disconnected? fatal: [localhost]: FAILED! => {"changed": false, "cmd": "oc cluster up --service-catalog=true --host-config-dir=/home/jstaffor/MCP/mcp-standalone/ui --host-data-dir=/home/jstaffor/MCP/mcp-standalone/ui/openshift-data --host-pv-dir=/home/jstaffor/MCP/mcp-standalone/ui/openshift-pvs --host-volumes-dir=/home/jstaffor/MCP/mcp-standalone/ui/openshift-volumes --routing-suffix=192.168.37.1.nip.io --public-hostname=192.168.37.1 --version=v3.7.0-rc.0 --image=openshift/origin", "delta": "0:10:42.022010", "end": "2017-11-07 11:45:48.927503", "failed": true, "msg": "non-zero return code", "rc": 1, "start": "2017-11-07 11:35:06.905493", "stderr": "", "stderr_lines": [], "stdout": "Starting OpenShift using openshift/origin:v3.7.0-rc.0 ...\n-- Checking OpenShift client ... OK\n-- Checking Docker client ... OK\n-- Checking Docker version ... OK\n-- Checking for existing OpenShift container ... OK\n-- Checking for openshift/origin:v3.7.0-rc.0 image ... OK\n-- Checking Docker daemon configuration ... OK\n-- Checking for available ports ... \n WARNING: Binding DNS on port 8053 instead of 53, which may not be resolvable from all clients.\n-- Checking type of volume mount ... \n Using nsenter mounter for OpenShift volumes\n-- Creating host directories ... OK\n-- Finding server IP ... \n Using public hostname IP 192.168.37.1 as the host IP\n Using 192.168.37.1 as the server IP\n-- Checking service catalog version requirements ... OK\n-- Starting OpenShift container ... \n Creating initial OpenShift configuration\n Starting OpenShift using container 'origin'\n Waiting for API server to start listening\n OpenShift server started\n-- Adding default OAuthClient redirect URIs ... OK\n-- Installing registry ... \n scc \"privileged\" added to: [\"system:serviceaccount:default:registry\"]\n-- Installing router ... OK\n-- Importing image streams ... OK\n-- Importing templates ... OK\n-- Importing service catalog templates ... OK\n-- Installing service catalog ... OK\n-- Installing template service broker ... FAIL\n Error: failed to start the template service broker apiserver: timed out waiting for the condition", "stdout_lines": ["Starting OpenShift using openshift/origin:v3.7.0-rc.0 ...", "-- Checking OpenShift client ... OK", "-- Checking Docker client ... OK", "-- Checking Docker version ... OK", "-- Checking for existing OpenShift container ... OK", "-- Checking for openshift/origin:v3.7.0-rc.0 image ... OK", "-- Checking Docker daemon configuration ... OK", "-- Checking for available ports ... ", " WARNING: Binding DNS on port 8053 instead of 53, which may not be resolvable from all clients.", "-- Checking type of volume mount ... ", " Using nsenter mounter for OpenShift volumes", "-- Creating host directories ... OK", "-- Finding server IP ... ", " Using public hostname IP 192.168.37.1 as the host IP", " Using 192.168.37.1 as the server IP", "-- Checking service catalog version requirements ... OK", "-- Starting OpenShift container ... ", " Creating initial OpenShift configuration", " Starting OpenShift using container 'origin'", " Waiting for API server to start listening", " OpenShift server started", "-- Adding default OAuthClient redirect URIs ... OK", "-- Installing registry ... ", " scc \"privileged\" added to: [\"system:serviceaccount:default:registry\"]", "-- Installing router ... OK", "-- Importing image streams ... OK", "-- Importing templates ... OK", "-- Importing service catalog templates ... OK", "-- Installing service catalog ... OK", "-- Installing template service broker ... FAIL", " Error: failed to start the template service broker apiserver: timed out waiting for the condition"]} -- ?[2] Id: bc3e4b7320ec40571486521712ad33420f7c04b2f44e3b7ecdcaee0b768a3554 Created: 2017-11-07T11:55:52.864111572Z Image: ?? docker.io/openshift/origin at sha256:aa3339aeae8accb9735f9d21ec5ca43f9cc82924f7ce3e8cbe92e02fc4b35c45 sha256:76d9e4ab142b310fa8adf1427f99f98fdc627ae8e460b92f55878ba68e6a9679 Command: /bin/bash -c "#/bin/bash set -e function generate_pv() { local basedir=\"${1}\" local name=\"${2}\" cat < /dev/null; then echo \"Not setting SELinux content for ${dir}\" fi chmod 770 \"${dir}\" } function create_pv() { local basedir=\"${1}\" local name=\"${2}\" setup_pv_dir \"${basedir}/${name}\" if ! oc get pv \"${name}\" &> /dev/null; then generate_pv \"${basedir}\" \"${name}\" | oc create -f - else echo \"persistentvolume ${name} already exists\" fi } basedir=\"/home/jstaffor/MCP/mcp-standalone/ui/openshift-pvs\" setup_pv_dir \"${basedir}/registry\" for i in $(seq -f \"%04g\" 1 100); do create_pv \"${basedir}\" \"pv${i}\" done " State: Exited 1 Restart Policy: IP Address: IP Prefix Length: 0 Gateway: MAC Address: ? JOHN STAFFORD TECHNICAL WRITER, CCS Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfrizell at redhat.com Tue Nov 7 12:23:26 2017 From: jfrizell at redhat.com (John Frizelle) Date: Tue, 7 Nov 2017 12:23:26 +0000 Subject: [feedhenry-dev] "Template service broker apiserver fails to start" during Ansible MCP startup In-Reply-To: References: Message-ID: Hi John, >From looking at the output and my own experience, this is OpenShift itself not starting up correctly - "Error: failed to start the template service broker apiserver: timed out waiting for the condition"]}" If you manually run oc cluster up, you often get a bit more info (and in a more readable format) than what is output from the ansible installer. Since the problem here is specific to oc, we might end up needing input from some openshift folks. Regards, John. -- John Frizelle Chief Architect, Red Hat Mobile Consulting Engineer mobile: *+353 87 290 1644 * twitter:* @johnfriz* skype: *john_frizelle* mail: *jfrizell at redhat.com * On 7 November 2017 at 12:08, John Stafford wrote: > Hi, > > 1) when I run "ansible-playbook playbook.yml -e "dockerhub_username=$ > DOCKERHUB_USERNAME" -e "dockerhub_password=$DOCKERHUB_PASSWORD" > --ask-become-pass" > > 2) the execution gets as far as "TASK [oc-cluster-up : Cluster up] " and > then terminates with an error[1] (after hanging for about 4-5 mins) > > 3) the docker image[2] in cockpit contains the the message "Unable to > connect to the server: dial tcp 172.30.0.1:443: getsockopt: no route to > host disconnected" > > Any ideas on how to troubleshoot/work around this? > > FYI - I completed a 'make clean' against the '/home/jstaffor/MCP/mcp-standalone/' > folder and executed the command above again but unfortunately the same > situation occurred. > > [1] > > ?Unable to connect to the server: dial tcp 172.30.0.1:443: getsockopt: no > route to host disconnected? > > > fatal: [localhost]: FAILED! => {"changed": false, "cmd": "oc cluster up > --service-catalog=true --host-config-dir=/home/jstaffor/MCP/mcp-standalone/ui > --host-data-dir=/home/jstaffor/MCP/mcp-standalone/ui/openshift-data > --host-pv-dir=/home/jstaffor/MCP/mcp-standalone/ui/openshift-pvs > --host-volumes-dir=/home/jstaffor/MCP/mcp-standalone/ui/openshift-volumes > --routing-suffix=192.168.37.1.nip.io --public-hostname=192.168.37.1 > --version=v3.7.0-rc.0 --image=openshift/origin", "delta": "0:10:42.022010", > "end": "2017-11-07 11:45:48.927503", "failed": true, "msg": "non-zero > return code", "rc": 1, "start": "2017-11-07 11:35:06.905493", "stderr": "", > "stderr_lines": [], "stdout": "Starting OpenShift using > openshift/origin:v3.7.0-rc.0 ...\n-- Checking OpenShift client ... OK\n-- > Checking Docker client ... OK\n-- Checking Docker version ... OK\n-- > Checking for existing OpenShift container ... OK\n-- Checking for > openshift/origin:v3.7.0-rc.0 image ... OK\n-- Checking Docker daemon > configuration ... OK\n-- Checking for available ports ... \n WARNING: > Binding DNS on port 8053 instead of 53, which may not be resolvable from > all clients.\n-- Checking type of volume mount ... \n Using nsenter > mounter for OpenShift volumes\n-- Creating host directories ... OK\n-- > Finding server IP ... \n Using public hostname IP 192.168.37.1 as the > host IP\n Using 192.168.37.1 as the server IP\n-- Checking service > catalog version requirements ... OK\n-- Starting OpenShift container ... \n > Creating initial OpenShift configuration\n Starting OpenShift using > container 'origin'\n Waiting for API server to start listening\n > OpenShift server started\n-- Adding default OAuthClient redirect URIs ... > OK\n-- Installing registry ... \n scc \"privileged\" added to: > [\"system:serviceaccount:default:registry\"]\n-- Installing router ... > OK\n-- Importing image streams ... OK\n-- Importing templates ... OK\n-- > Importing service catalog templates ... OK\n-- Installing service catalog > ... OK\n-- Installing template service broker ... FAIL\n Error: failed to > start the template service broker apiserver: timed out waiting for the > condition", "stdout_lines": ["Starting OpenShift using > openshift/origin:v3.7.0-rc.0 ...", "-- Checking OpenShift client ... OK", > "-- Checking Docker client ... OK", "-- Checking Docker version ... OK", > "-- Checking for existing OpenShift container ... OK", "-- Checking for > openshift/origin:v3.7.0-rc.0 image ... OK", "-- Checking Docker daemon > configuration ... OK", "-- Checking for available ports ... ", " WARNING: > Binding DNS on port 8053 instead of 53, which may not be resolvable from > all clients.", "-- Checking type of volume mount ... ", " Using nsenter > mounter for OpenShift volumes", "-- Creating host directories ... OK", "-- > Finding server IP ... ", " Using public hostname IP 192.168.37.1 as the > host IP", " Using 192.168.37.1 as the server IP", "-- Checking service > catalog version requirements ... OK", "-- Starting OpenShift container ... > ", " Creating initial OpenShift configuration", " Starting OpenShift > using container 'origin'", " Waiting for API server to start listening", > " OpenShift server started", "-- Adding default OAuthClient redirect URIs > ... OK", "-- Installing registry ... ", " scc \"privileged\" added to: > [\"system:serviceaccount:default:registry\"]", "-- Installing router ... > OK", "-- Importing image streams ... OK", "-- Importing templates ... OK", > "-- Importing service catalog templates ... OK", "-- Installing service > catalog ... OK", "-- Installing template service broker ... FAIL", " > Error: failed to start the template service broker apiserver: timed out > waiting for the condition"]} > -- > > ?[2] > Id: bc3e4b7320ec40571486521712ad33420f7c04b2f44e3b7ecdcaee0b768a3554 > Created: 2017-11-07T11:55:52.864111572Z > Image: > ?? > docker.io/openshift/origin at sha256:aa3339aeae8accb9735f9d21ec5ca4 > 3f9cc82924f7ce3e8cbe92e02fc4b35c45 > sha256:76d9e4ab142b310fa8adf1427f99f98fdc627ae8e460b92f55878ba68e6a9679 > Command: /bin/bash -c "#/bin/bash set -e function generate_pv() { local > basedir=\"${1}\" local name=\"${2}\" cat < PersistentVolume metadata: name: ${name} labels: volume: ${name} spec: > capacity: storage: 100Gi accessModes: - ReadWriteOnce - ReadWriteMany - > ReadOnlyMany hostPath: path: ${basedir}/${name} > persistentVolumeReclaimPolicy: Recycle EOF } function setup_pv_dir() { > local dir=\"${1}\" if [[ ! -d \"${dir}\" ]]; then mkdir -p \"${dir}\" fi if > ! chcon -t svirt_sandbox_file_t \"${dir}\" &> /dev/null; then echo \"Not > setting SELinux content for ${dir}\" fi chmod 770 \"${dir}\" } function > create_pv() { local basedir=\"${1}\" local name=\"${2}\" setup_pv_dir > \"${basedir}/${name}\" if ! oc get pv \"${name}\" &> /dev/null; then > generate_pv \"${basedir}\" \"${name}\" | oc create -f - else echo > \"persistentvolume ${name} already exists\" fi } > basedir=\"/home/jstaffor/MCP/mcp-standalone/ui/openshift-pvs\" > setup_pv_dir \"${basedir}/registry\" for i in $(seq -f \"%04g\" 1 100); do > create_pv \"${basedir}\" \"pv${i}\" done " > State: Exited 1 > Restart Policy: > IP Address: > IP Prefix Length: 0 > Gateway: > MAC Address: > > ? > > > JOHN STAFFORD > > TECHNICAL WRITER, CCS > > Red Hat > > > > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 11472 bytes Desc: not available URL: From jstaffor at redhat.com Tue Nov 7 13:31:31 2017 From: jstaffor at redhat.com (John Stafford) Date: Tue, 7 Nov 2017 13:31:31 +0000 Subject: [feedhenry-dev] "Template service broker apiserver fails to start" during Ansible MCP startup In-Reply-To: References: Message-ID: *@ John F *- thanks for feedback. I was working with John R on running 'oc cluster up' and working with info coming back from this, which is: *Logged into "https://127.0.0.1:8443 " as "system:admin" using existing credentials.* *You have access to the following projects and can switch between them with 'oc project ':* * default* * kube-public* * kube-system* * * myproject* * openshift* * openshift-infra* * openshift-node* It looks like I am missing two services, Ansible being one. *@John R* - the following is the error message from the image that was running at the very end of execution: E1107 13:13:30.019459 1 reflector.go:216] github.com/openshift/origin/ pkg/template/generated/informers/internalversion/factory.go:45: Failed to list *template.Template: Get https://172.30.0.1:443/apis/ template.openshift.io/v1/templates?resourceVersion=0: dial tcp 172.30.0.1:443: getsockopt: no route to host *and* this is message from the URL 'https://172.30.0.1/apis/ template.openshift.io/v1/templates?resourceVersion=0': User "system:anonymous" cannot list templates.template.openshift.io at the cluster scope: User "system:anonymous" cannot list all templates.template.openshift.io in the cluster On Tue, Nov 7, 2017 at 12:23 PM, John Frizelle wrote: > Hi John, > > From looking at the output and my own experience, this is OpenShift itself > not starting up correctly - "Error: failed to start the template service > broker apiserver: timed out waiting for the condition"]}" > > If you manually run oc cluster up, you often get a bit more info (and in a > more readable format) than what is output from the ansible installer. > > Since the problem here is specific to oc, we might end up needing input > from some openshift folks. > > Regards, > John. > > -- > John Frizelle > Chief Architect, Red Hat Mobile > Consulting Engineer > > mobile: *+353 87 290 1644 * > twitter:* @johnfriz* > skype: *john_frizelle* > mail: *jfrizell at redhat.com * > > > > > On 7 November 2017 at 12:08, John Stafford wrote: > >> Hi, >> >> 1) when I run "ansible-playbook playbook.yml -e "dockerhub_username= >> $DOCKERHUB_USERNAME" -e "dockerhub_password=$DOCKERHUB_PASSWORD" >> --ask-become-pass" >> >> 2) the execution gets as far as "TASK [oc-cluster-up : Cluster up] " and >> then terminates with an error[1] (after hanging for about 4-5 mins) >> >> 3) the docker image[2] in cockpit contains the the message "Unable to >> connect to the server: dial tcp 172.30.0.1:443: getsockopt: no route to >> host disconnected" >> >> Any ideas on how to troubleshoot/work around this? >> >> FYI - I completed a 'make clean' against the >> '/home/jstaffor/MCP/mcp-standalone/' folder and executed the command >> above again but unfortunately the same situation occurred. >> >> [1] >> >> ?Unable to connect to the server: dial tcp 172.30.0.1:443: getsockopt: >> no route to host disconnected? >> >> >> fatal: [localhost]: FAILED! => {"changed": false, "cmd": "oc cluster up >> --service-catalog=true --host-config-dir=/home/jstaffor/MCP/mcp-standalone/ui >> --host-data-dir=/home/jstaffor/MCP/mcp-standalone/ui/openshift-data >> --host-pv-dir=/home/jstaffor/MCP/mcp-standalone/ui/openshift-pvs >> --host-volumes-dir=/home/jstaffor/MCP/mcp-standalone/ui/openshift-volumes >> --routing-suffix=192.168.37.1.nip.io --public-hostname=192.168.37.1 >> --version=v3.7.0-rc.0 --image=openshift/origin", "delta": "0:10:42.022010", >> "end": "2017-11-07 11:45:48.927503", "failed": true, "msg": "non-zero >> return code", "rc": 1, "start": "2017-11-07 11:35:06.905493", "stderr": "", >> "stderr_lines": [], "stdout": "Starting OpenShift using >> openshift/origin:v3.7.0-rc.0 ...\n-- Checking OpenShift client ... OK\n-- >> Checking Docker client ... OK\n-- Checking Docker version ... OK\n-- >> Checking for existing OpenShift container ... OK\n-- Checking for >> openshift/origin:v3.7.0-rc.0 image ... OK\n-- Checking Docker daemon >> configuration ... OK\n-- Checking for available ports ... \n WARNING: >> Binding DNS on port 8053 instead of 53, which may not be resolvable from >> all clients.\n-- Checking type of volume mount ... \n Using nsenter >> mounter for OpenShift volumes\n-- Creating host directories ... OK\n-- >> Finding server IP ... \n Using public hostname IP 192.168.37.1 as the >> host IP\n Using 192.168.37.1 as the server IP\n-- Checking service >> catalog version requirements ... OK\n-- Starting OpenShift container ... \n >> Creating initial OpenShift configuration\n Starting OpenShift using >> container 'origin'\n Waiting for API server to start listening\n >> OpenShift server started\n-- Adding default OAuthClient redirect URIs ... >> OK\n-- Installing registry ... \n scc \"privileged\" added to: >> [\"system:serviceaccount:default:registry\"]\n-- Installing router ... >> OK\n-- Importing image streams ... OK\n-- Importing templates ... OK\n-- >> Importing service catalog templates ... OK\n-- Installing service catalog >> ... OK\n-- Installing template service broker ... FAIL\n Error: failed to >> start the template service broker apiserver: timed out waiting for the >> condition", "stdout_lines": ["Starting OpenShift using >> openshift/origin:v3.7.0-rc.0 ...", "-- Checking OpenShift client ... OK", >> "-- Checking Docker client ... OK", "-- Checking Docker version ... OK", >> "-- Checking for existing OpenShift container ... OK", "-- Checking for >> openshift/origin:v3.7.0-rc.0 image ... OK", "-- Checking Docker daemon >> configuration ... OK", "-- Checking for available ports ... ", " WARNING: >> Binding DNS on port 8053 instead of 53, which may not be resolvable from >> all clients.", "-- Checking type of volume mount ... ", " Using nsenter >> mounter for OpenShift volumes", "-- Creating host directories ... OK", "-- >> Finding server IP ... ", " Using public hostname IP 192.168.37.1 as the >> host IP", " Using 192.168.37.1 as the server IP", "-- Checking service >> catalog version requirements ... OK", "-- Starting OpenShift container ... >> ", " Creating initial OpenShift configuration", " Starting OpenShift >> using container 'origin'", " Waiting for API server to start listening", >> " OpenShift server started", "-- Adding default OAuthClient redirect URIs >> ... OK", "-- Installing registry ... ", " scc \"privileged\" added to: >> [\"system:serviceaccount:default:registry\"]", "-- Installing router ... >> OK", "-- Importing image streams ... OK", "-- Importing templates ... OK", >> "-- Importing service catalog templates ... OK", "-- Installing service >> catalog ... OK", "-- Installing template service broker ... FAIL", " >> Error: failed to start the template service broker apiserver: timed out >> waiting for the condition"]} >> -- >> >> ?[2] >> Id: bc3e4b7320ec40571486521712ad33420f7c04b2f44e3b7ecdcaee0b768a3554 >> Created: 2017-11-07T11:55:52.864111572Z >> Image: >> ?? >> docker.io/openshift/origin at sha256:aa3339aeae8accb9735f9d21ec >> 5ca43f9cc82924f7ce3e8cbe92e02fc4b35c45 >> sha256:76d9e4ab142b310fa8adf1427f99f98fdc627ae8e460b92f55878ba68e6a9679 >> Command: /bin/bash -c "#/bin/bash set -e function generate_pv() { local >> basedir=\"${1}\" local name=\"${2}\" cat <> PersistentVolume metadata: name: ${name} labels: volume: ${name} spec: >> capacity: storage: 100Gi accessModes: - ReadWriteOnce - ReadWriteMany - >> ReadOnlyMany hostPath: path: ${basedir}/${name} >> persistentVolumeReclaimPolicy: Recycle EOF } function setup_pv_dir() { >> local dir=\"${1}\" if [[ ! -d \"${dir}\" ]]; then mkdir -p \"${dir}\" fi if >> ! chcon -t svirt_sandbox_file_t \"${dir}\" &> /dev/null; then echo \"Not >> setting SELinux content for ${dir}\" fi chmod 770 \"${dir}\" } function >> create_pv() { local basedir=\"${1}\" local name=\"${2}\" setup_pv_dir >> \"${basedir}/${name}\" if ! oc get pv \"${name}\" &> /dev/null; then >> generate_pv \"${basedir}\" \"${name}\" | oc create -f - else echo >> \"persistentvolume ${name} already exists\" fi } >> basedir=\"/home/jstaffor/MCP/mcp-standalone/ui/openshift-pvs\" >> setup_pv_dir \"${basedir}/registry\" for i in $(seq -f \"%04g\" 1 100); do >> create_pv \"${basedir}\" \"pv${i}\" done " >> State: Exited 1 >> Restart Policy: >> IP Address: >> IP Prefix Length: 0 >> Gateway: >> MAC Address: >> >> ? >> >> >> JOHN STAFFORD >> >> TECHNICAL WRITER, CCS >> >> Red Hat >> >> >> >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > -- JOHN STAFFORD TECHNICAL WRITER, CCS Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 11472 bytes Desc: not available URL: From lgriffin at redhat.com Tue Nov 7 16:05:03 2017 From: lgriffin at redhat.com (Leigh Griffin) Date: Tue, 7 Nov 2017 16:05:03 +0000 Subject: [feedhenry-dev] RFC: MCP-standalone Release Process In-Reply-To: References: <878tfxf3gu.fsf@thinkpad.grdryn.redhat> Message-ID: Sorry PTO for a week then backlog of mails. It's formally needed for productisation but as Matthias pointed out it's good to be transparent in the community as well. Anything we as a company ship (product wise) needs to have a license so I would assume OpenShift have one. Could be worth reaching out to them to find out perhaps? On Fri, Oct 27, 2017 at 9:40 AM, Matthias Wessendorf wrote: > > > On Fri, Oct 27, 2017 at 9:35 AM, Gerard Ryan wrote: > >> Leigh Griffin writes: >> >> > Just want to throw it out there that the XML Licenser is going to be a >> > requirement here. It's not a painful step in the above that you >> described >> > but it's a step nonetheless. So if our code is anything outside of Java >> > (maven based) or Node.js we might need to consider building a tool to >> > create the licensing information or reach out wider to find a team >> already >> > in flight on it. >> >> Would that just be needed for the eventual Red Hat productization of it, >> or is it also needed for the open source releases here? >> > > OpenSource communities do that too, here a few examples of our own: > * https://github.com/keycloak/keycloak/pull/4491 > * https://github.com/aerogear/aerogear-unifiedpush-server/pull/937 > > the second example is inspired by the release process of the ASF, > requiring "LICENSE", "DEPENDENCIES" and "NOTICE" file as part of the > (binary) artifact. > and a first step into what EAP does (for product) > > >> >> In any case, I'd expect that other projects that Red Hat productizes >> downstream, that are also Go projects, would also have this requirement, >> right (e.g. OpenShift)? > > > yep, I was wondering that too, what they have > > >> Whatever they're using, would ideally be reused >> here, rather than each of us creating our own way of doing it. >> > > +1000 > > I started a little thread on the apb repo: > https://github.com/ansibleplaybookbundle/ansible- > playbook-bundle/issues/154 > > > >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> > > > > -- > Project lead AeroGear.org > -- LEIGH GRIFFIN ENGINEERING MANAGER, MOBILE Red Hat Ireland Communications House, Cork Road Waterford City, Ireland X91NY33 lgriffin at redhat.com M: +353877545162 IM: lgriffin TRIED. TESTED. TRUSTED. @redhatway @redhatinc @redhatsnaps -------------- next part -------------- An HTML attachment was scrubbed... URL: From dffrench at redhat.com Thu Nov 9 12:18:00 2017 From: dffrench at redhat.com (David Ffrench) Date: Thu, 9 Nov 2017 12:18:00 +0000 Subject: [feedhenry-dev] Looking for someone with fh-mbaas-express knowledge In-Reply-To: References: Message-ID: Hi All, After modifying the code weeks ago, i finally have time to come back and manually test this change E2E. I have tested the multer changes with the forms endpoints and it is working as expected. Unfortunately i have not been able to find what uses the following endpoints for file upload. I am hoping someone else will know. *Does anyone know what uses these endpoints in `fh-mbaas-express` for file upload?* - https://github.com/feedhenry/fh-mbaas-express/blob/master/ lib/cloud/cloud.js#L45 - https://github.com/feedhenry/fh-mbaas-express/blob/master/ lib/mbaas.js#L173 Kind Regards, DAVID FFRENCH senior software engineer, RED HAT MOBILE Red Hat Waterford Communications House, Cork Road Waterford, Ireland dffrench at redhat.com On Mon, Oct 16, 2017 at 8:39 AM, David Ffrench wrote: > Thank you very much for the response John, your information is extremely > helpful. > > DAVID FFRENCH > > senior software engineer, RED HAT MOBILE > > Red Hat Waterford > > Communications House, Cork Road > > Waterford, Ireland > > dffrench at redhat.com > > > > On Fri, Oct 13, 2017 at 9:37 AM, John Frizelle > wrote: > >> Hi David, >> >> I have had a look through the code and as far as I can tell, the changes >> are relatively straight forward. There are 3 places where an additional >> parameter is required in a route definition: >> >> - https://github.com/feedhenry/fh-mbaas-express/blob/master/li >> b/cloud/cloud.js#L45 >> - https://github.com/feedhenry/fh-mbaas-express/blob/master/li >> b/mbaas.js#L173 >> - https://github.com/feedhenry/fh-mbaas-express/blob/master/li >> b/mbaas.js#L299 >> >> In all 3 cases, we need to add upload.any() as the middle param - this >> will put any uploaded files in a files array, which is what is expected >> in the rest of the code [1]. >> >> Regards, >> John. >> >> [1] https://github.com/feedhenry/fh-mbaas-express/blob/ >> master/lib/cloud/params.js#L42, https://github.com/feedhenry >> /fh-mbaas-express/blob/master/lib/common/requestValidator.js#L111, >> https://github.com/feedhenry/fh-mbaas-express/ >> blob/master/lib/fh-middleware.js#L25, https://github.com/ >> feedhenry/fh-mbaas-express/blob/master/lib/cloud/cloud.js#L69 >> >> >> -- >> John Frizelle >> Chief Architect, Red Hat Mobile >> Consulting Engineer >> >> mobile: *+353 87 290 1644 * >> twitter:* @johnfriz* >> skype: *john_frizelle* >> mail: *jfrizell at redhat.com * >> >> >> >> >> On 12 October 2017 at 17:54, David Ffrench wrote: >> >>> Hi All, >>> >>> I am looking to talk to someone with a high knowledge of the >>> https://github.com/feedhenry/fh-mbaas-express codebase. Specifically >>> around the use of the multer module. >>> >>> Due to a security vulnerability, i need to upgrade the version of multer >>> from 0.1.8 to 1.0.0 which breaks the app due to a breaking change in the >>> multer api. This will require code modifications in fh-mbaas-express to >>> resolve. >>> >>> There are only 2 locations in the app that multer is used but due to the >>> way it's api has changed, there could be more code modifications required. >>> >>> Any help of guidance would be greatly appreciated. >>> >>> Best Regards, >>> >>> DAVID FFRENCH >>> >>> senior software engineer, RED HAT MOBILE >>> >>> Red Hat Waterford >>> >>> Communications House, Cork Road >>> >>> Waterford, Ireland >>> >>> dffrench at redhat.com >>> >>> >>> >>> _______________________________________________ >>> feedhenry-dev mailing list >>> feedhenry-dev at redhat.com >>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 11472 bytes Desc: not available URL: From davmarti at redhat.com Fri Nov 10 11:28:57 2017 From: davmarti at redhat.com (David Martin) Date: Fri, 10 Nov 2017 11:28:57 +0000 Subject: [feedhenry-dev] Looking for someone with fh-mbaas-express knowledge In-Reply-To: References: Message-ID: Hey David, In the first link, it looks like its a generic handler for if you had a main.js file? For helping migrating from FH2 to FH3. In the second link, it looks to be doing some authentication check for every request. You may find more info by looking at the history of that module before it was made public. (Apologies for the private repo link https://github.com/fheng/fh-mbaas-express) On 9 November 2017 at 12:18, David Ffrench wrote: > Hi All, > > After modifying the code weeks ago, i finally have time to come back and > manually test this change E2E. I have tested the multer changes with the > forms endpoints and it is working as expected. Unfortunately i have not > been able to find what uses the following endpoints for file upload. I am > hoping someone else will know. > > *Does anyone know what uses these endpoints in `fh-mbaas-express` for file > upload?* > - https://github.com/feedhenry/fh-mbaas-express/ > blob/master/lib/cloud/cloud.js#L45 > - https://github.com/feedhenry/fh-mbaas-express/ > blob/master/lib/mbaas.js#L173 > > Kind Regards, > > DAVID FFRENCH > > senior software engineer, RED HAT MOBILE > > Red Hat Waterford > > Communications House, Cork Road > > Waterford, Ireland > > dffrench at redhat.com > > > > On Mon, Oct 16, 2017 at 8:39 AM, David Ffrench > wrote: > >> Thank you very much for the response John, your information is extremely >> helpful. >> >> DAVID FFRENCH >> >> senior software engineer, RED HAT MOBILE >> >> Red Hat Waterford >> >> Communications House, Cork Road >> >> Waterford, Ireland >> >> dffrench at redhat.com >> >> >> >> On Fri, Oct 13, 2017 at 9:37 AM, John Frizelle >> wrote: >> >>> Hi David, >>> >>> I have had a look through the code and as far as I can tell, the changes >>> are relatively straight forward. There are 3 places where an additional >>> parameter is required in a route definition: >>> >>> - https://github.com/feedhenry/fh-mbaas-express/blob/master/li >>> b/cloud/cloud.js#L45 >>> - https://github.com/feedhenry/fh-mbaas-express/blob/master/li >>> b/mbaas.js#L173 >>> - https://github.com/feedhenry/fh-mbaas-express/blob/master/li >>> b/mbaas.js#L299 >>> >>> In all 3 cases, we need to add upload.any() as the middle param - this >>> will put any uploaded files in a files array, which is what is expected >>> in the rest of the code [1]. >>> >>> Regards, >>> John. >>> >>> [1] https://github.com/feedhenry/fh-mbaas-express/blob/maste >>> r/lib/cloud/params.js#L42, https://github.com/feedhenry/fh- >>> mbaas-express/blob/master/lib/common/requestValidator.js#L111, >>> https://github.com/feedhenry/fh-mbaas-express/blob/ >>> master/lib/fh-middleware.js#L25, https://github.com/feedhe >>> nry/fh-mbaas-express/blob/master/lib/cloud/cloud.js#L69 >>> >>> >>> -- >>> John Frizelle >>> Chief Architect, Red Hat Mobile >>> Consulting Engineer >>> >>> mobile: *+353 87 290 1644 * >>> twitter:* @johnfriz* >>> skype: *john_frizelle* >>> mail: *jfrizell at redhat.com * >>> >>> >>> >>> >>> On 12 October 2017 at 17:54, David Ffrench wrote: >>> >>>> Hi All, >>>> >>>> I am looking to talk to someone with a high knowledge of the >>>> https://github.com/feedhenry/fh-mbaas-express codebase. Specifically >>>> around the use of the multer module. >>>> >>>> Due to a security vulnerability, i need to upgrade the version of >>>> multer from 0.1.8 to 1.0.0 which breaks the app due to a breaking change in >>>> the multer api. This will require code modifications in fh-mbaas-express to >>>> resolve. >>>> >>>> There are only 2 locations in the app that multer is used but due to >>>> the way it's api has changed, there could be more code modifications >>>> required. >>>> >>>> Any help of guidance would be greatly appreciated. >>>> >>>> Best Regards, >>>> >>>> DAVID FFRENCH >>>> >>>> senior software engineer, RED HAT MOBILE >>>> >>>> Red Hat Waterford >>>> >>>> Communications House, Cork Road >>>> >>>> Waterford, Ireland >>>> >>>> dffrench at redhat.com >>>> >>>> >>>> >>>> _______________________________________________ >>>> feedhenry-dev mailing list >>>> feedhenry-dev at redhat.com >>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>> >>>> >>> >> > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 11472 bytes Desc: not available URL: From dffrench at redhat.com Fri Nov 10 12:33:41 2017 From: dffrench at redhat.com (David Ffrench) Date: Fri, 10 Nov 2017 12:33:41 +0000 Subject: [feedhenry-dev] Looking for someone with fh-mbaas-express knowledge In-Reply-To: References: Message-ID: Hey David, This is great info, thank you very much. DAVID FFRENCH senior software engineer, RED HAT MOBILE Red Hat Waterford Communications House, Cork Road Waterford, Ireland dffrench at redhat.com On Fri, Nov 10, 2017 at 11:28 AM, David Martin wrote: > Hey David, > > In the first link, it looks like its a generic handler for if you had a > main.js file? For helping migrating from FH2 to FH3. > In the second link, it looks to be doing some authentication check for > every request. > > You may find more info by looking at the history of that module before it > was made public. > (Apologies for the private repo link https://github.com/fheng/ > fh-mbaas-express) > > On 9 November 2017 at 12:18, David Ffrench wrote: > >> Hi All, >> >> After modifying the code weeks ago, i finally have time to come back and >> manually test this change E2E. I have tested the multer changes with the >> forms endpoints and it is working as expected. Unfortunately i have not >> been able to find what uses the following endpoints for file upload. I am >> hoping someone else will know. >> >> *Does anyone know what uses these endpoints in `fh-mbaas-express` for >> file upload?* >> - https://github.com/feedhenry/fh-mbaas-express/blob/master/ >> lib/cloud/cloud.js#L45 >> - https://github.com/feedhenry/fh-mbaas-express/blob/master/ >> lib/mbaas.js#L173 >> >> Kind Regards, >> >> DAVID FFRENCH >> >> senior software engineer, RED HAT MOBILE >> >> Red Hat Waterford >> >> Communications House, Cork Road >> >> Waterford, Ireland >> >> dffrench at redhat.com >> >> >> >> On Mon, Oct 16, 2017 at 8:39 AM, David Ffrench >> wrote: >> >>> Thank you very much for the response John, your information is extremely >>> helpful. >>> >>> DAVID FFRENCH >>> >>> senior software engineer, RED HAT MOBILE >>> >>> Red Hat Waterford >>> >>> Communications House, Cork Road >>> >>> Waterford, Ireland >>> >>> dffrench at redhat.com >>> >>> >>> >>> On Fri, Oct 13, 2017 at 9:37 AM, John Frizelle >>> wrote: >>> >>>> Hi David, >>>> >>>> I have had a look through the code and as far as I can tell, the >>>> changes are relatively straight forward. There are 3 places where an >>>> additional parameter is required in a route definition: >>>> >>>> - https://github.com/feedhenry/fh-mbaas-express/blob/master/li >>>> b/cloud/cloud.js#L45 >>>> - https://github.com/feedhenry/fh-mbaas-express/blob/master/li >>>> b/mbaas.js#L173 >>>> - https://github.com/feedhenry/fh-mbaas-express/blob/master/li >>>> b/mbaas.js#L299 >>>> >>>> In all 3 cases, we need to add upload.any() as the middle param - this >>>> will put any uploaded files in a files array, which is what is >>>> expected in the rest of the code [1]. >>>> >>>> Regards, >>>> John. >>>> >>>> [1] https://github.com/feedhenry/fh-mbaas-express/blob/maste >>>> r/lib/cloud/params.js#L42, https://github.com/feedhenry/fh-m >>>> baas-express/blob/master/lib/common/requestValidator.js#L111, >>>> https://github.com/feedhenry/fh-mbaas-express/blob/master/ >>>> lib/fh-middleware.js#L25, https://github.com/feedhenry/fh- >>>> mbaas-express/blob/master/lib/cloud/cloud.js#L69 >>>> >>>> >>>> -- >>>> John Frizelle >>>> Chief Architect, Red Hat Mobile >>>> Consulting Engineer >>>> >>>> mobile: *+353 87 290 1644 * >>>> twitter:* @johnfriz* >>>> skype: *john_frizelle* >>>> mail: *jfrizell at redhat.com * >>>> >>>> >>>> >>>> >>>> On 12 October 2017 at 17:54, David Ffrench wrote: >>>> >>>>> Hi All, >>>>> >>>>> I am looking to talk to someone with a high knowledge of the >>>>> https://github.com/feedhenry/fh-mbaas-express codebase. Specifically >>>>> around the use of the multer module. >>>>> >>>>> Due to a security vulnerability, i need to upgrade the version of >>>>> multer from 0.1.8 to 1.0.0 which breaks the app due to a breaking change in >>>>> the multer api. This will require code modifications in fh-mbaas-express to >>>>> resolve. >>>>> >>>>> There are only 2 locations in the app that multer is used but due to >>>>> the way it's api has changed, there could be more code modifications >>>>> required. >>>>> >>>>> Any help of guidance would be greatly appreciated. >>>>> >>>>> Best Regards, >>>>> >>>>> DAVID FFRENCH >>>>> >>>>> senior software engineer, RED HAT MOBILE >>>>> >>>>> Red Hat Waterford >>>>> >>>>> Communications House, Cork Road >>>>> >>>>> Waterford, Ireland >>>>> >>>>> dffrench at redhat.com >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> feedhenry-dev mailing list >>>>> feedhenry-dev at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>>> >>>>> >>>> >>> >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > > -- > David Martin > Red Hat Mobile > Twitter: @irldavem > IRC: @irldavem (feedhenry, mobile-internal) > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 11472 bytes Desc: not available URL: From pbrookes at redhat.com Fri Nov 10 14:17:29 2017 From: pbrookes at redhat.com (Phil Brookes) Date: Fri, 10 Nov 2017 14:17:29 +0000 Subject: [feedhenry-dev] Demo of Prometheus with kubernetes service discovery Message-ID: Hey Everyone, I have been investigating using Prometheus on Openshift to collect metrics on the services running there. I have also investigated using service discovery to make Prometheus aware of new services to collect metrics for as they are deployed. This video is a demo of this work. I have also provided a gist of the Prometheus configuration settings that I used in in this demo. Let me know if you have any questions. Regards, Phil. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From weil at redhat.com Fri Nov 10 14:20:38 2017 From: weil at redhat.com (Wei Li) Date: Fri, 10 Nov 2017 14:20:38 +0000 Subject: [feedhenry-dev] Demo of Prometheus with kubernetes service discovery In-Reply-To: References: Message-ID: Hi Phil, Looks like the video is private? On Fri, Nov 10, 2017 at 2:17 PM, Phil Brookes wrote: > Hey Everyone, > > I have been investigating using Prometheus on Openshift to collect metrics > on the services running there. I have also investigated using service > discovery to make Prometheus aware of new services to collect metrics for > as they are deployed. > > This video > > is a demo of this work. I have also provided a gist of the Prometheus > configuration settings > > that I used in in this demo. > > Let me know if you have any questions. > > Regards, > Phil. > ? > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- WEI LI SENIOR SOFTWARE ENGINEER Red Hat Mobile weil at redhat.com M: +353862393272 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbrookes at redhat.com Fri Nov 10 14:21:55 2017 From: pbrookes at redhat.com (Phil Brookes) Date: Fri, 10 Nov 2017 14:21:55 +0000 Subject: [feedhenry-dev] Demo of Prometheus with kubernetes service discovery In-Reply-To: References: Message-ID: Thanks Wei, I have just made it accessible to everyone in Red Hat now! Regards, Phil. On Fri, Nov 10, 2017 at 2:20 PM, Wei Li wrote: > Hi Phil, > > Looks like the video is private? > > > On Fri, Nov 10, 2017 at 2:17 PM, Phil Brookes wrote: > >> Hey Everyone, >> >> I have been investigating using Prometheus on Openshift to collect >> metrics on the services running there. I have also investigated using >> service discovery to make Prometheus aware of new services to collect >> metrics for as they are deployed. >> >> This video >> >> is a demo of this work. I have also provided a gist of the Prometheus >> configuration settings >> >> that I used in in this demo. >> >> Let me know if you have any questions. >> >> Regards, >> Phil. >> ? >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > > -- > > WEI LI > > SENIOR SOFTWARE ENGINEER > > Red Hat Mobile > > weil at redhat.com M: +353862393272 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davmarti at redhat.com Fri Nov 10 14:37:58 2017 From: davmarti at redhat.com (David Martin) Date: Fri, 10 Nov 2017 14:37:58 +0000 Subject: [feedhenry-dev] Demo of Prometheus with kubernetes service discovery In-Reply-To: References: Message-ID: That's excellent Phil! Looks like a nice way to setup & configure Prometheus for any number of services Some of the commands are hard to see as the bottom of the video was clipped for me, but they scroll up the screen eventually On 10 November 2017 at 14:21, Phil Brookes wrote: > Thanks Wei, > > I have just made it accessible to everyone in Red Hat now! > > Regards, > Phil. > > On Fri, Nov 10, 2017 at 2:20 PM, Wei Li wrote: > >> Hi Phil, >> >> Looks like the video is private? >> >> >> On Fri, Nov 10, 2017 at 2:17 PM, Phil Brookes >> wrote: >> >>> Hey Everyone, >>> >>> I have been investigating using Prometheus on Openshift to collect >>> metrics on the services running there. I have also investigated using >>> service discovery to make Prometheus aware of new services to collect >>> metrics for as they are deployed. >>> >>> This video >>> >>> is a demo of this work. I have also provided a gist of the Prometheus >>> configuration settings >>> >>> that I used in in this demo. >>> >>> Let me know if you have any questions. >>> >>> Regards, >>> Phil. >>> ? >>> >>> _______________________________________________ >>> feedhenry-dev mailing list >>> feedhenry-dev at redhat.com >>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>> >>> >> >> >> -- >> >> WEI LI >> >> SENIOR SOFTWARE ENGINEER >> >> Red Hat Mobile >> >> weil at redhat.com M: +353862393272 >> >> > > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Fri Nov 10 14:48:48 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Fri, 10 Nov 2017 15:48:48 +0100 Subject: [feedhenry-dev] Demo of Prometheus with kubernetes service discovery In-Reply-To: References: Message-ID: nice demo, Phil! I think the video could be made public, especially it's shared on a public list ;-) On Fri, Nov 10, 2017 at 3:21 PM, Phil Brookes wrote: > Thanks Wei, > > I have just made it accessible to everyone in Red Hat now! > > Regards, > Phil. > > On Fri, Nov 10, 2017 at 2:20 PM, Wei Li wrote: > >> Hi Phil, >> >> Looks like the video is private? >> >> >> On Fri, Nov 10, 2017 at 2:17 PM, Phil Brookes >> wrote: >> >>> Hey Everyone, >>> >>> I have been investigating using Prometheus on Openshift to collect >>> metrics on the services running there. I have also investigated using >>> service discovery to make Prometheus aware of new services to collect >>> metrics for as they are deployed. >>> >>> This video >>> >>> is a demo of this work. I have also provided a gist of the Prometheus >>> configuration settings >>> >>> that I used in in this demo. >>> >>> Let me know if you have any questions. >>> >>> Regards, >>> Phil. >>> ? >>> >>> _______________________________________________ >>> feedhenry-dev mailing list >>> feedhenry-dev at redhat.com >>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>> >>> >> >> >> -- >> >> WEI LI >> >> SENIOR SOFTWARE ENGINEER >> >> Red Hat Mobile >> >> weil at redhat.com M: +353862393272 >> >> > > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From supittma at redhat.com Mon Nov 20 12:56:00 2017 From: supittma at redhat.com (Summers Pittman) Date: Mon, 20 Nov 2017 07:56:00 -0500 Subject: [feedhenry-dev] Installing Windows Hyper-V OpenShift Container Platform Message-ID: Might be useful if someone is going to pick up Windows or Xamarin clients for MCP. https://dzone.com/articles/installing-windows-hyper-v-openshift-container-pla -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Mon Nov 20 15:14:43 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Mon, 20 Nov 2017 16:14:43 +0100 Subject: [feedhenry-dev] MCP: Push integration JIRAs Message-ID: Hi folks! based on our quick call this morning, I've created three epics to should cover the three main bodies of work for getting UPS integrated to MCP While this one lives in the AeroGear community: * https://issues.jboss.org/browse/AGPUSH-2216 We have to FH JIRA epics that rely on the above being delivered: * https://issues.jboss.org/browse/FH-4361 * https://issues.jboss.org/browse/FH-4362 Please review these and add comments/questions/suggestions as needed! Thanks! -Matthias -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbrookes at redhat.com Mon Nov 20 15:39:10 2017 From: pbrookes at redhat.com (Phil Brookes) Date: Mon, 20 Nov 2017 15:39:10 +0000 Subject: [feedhenry-dev] MCP: Push integration JIRAs In-Reply-To: References: Message-ID: Might be worth discussing the Prometheus Jira's in the same call? https://issues.jboss.org/browse/FH-4356 https://issues.jboss.org/browse/FH-4357 https://issues.jboss.org/browse/FH-4358 https://issues.jboss.org/browse/FH-4359 https://issues.jboss.org/browse/FH-4360 Regards, Phil, On Mon, Nov 20, 2017 at 3:14 PM, Matthias Wessendorf wrote: > Hi folks! > > based on our quick call this morning, I've created three epics to should > cover the three main bodies of work for getting UPS integrated to MCP > > While this one lives in the AeroGear community: > * https://issues.jboss.org/browse/AGPUSH-2216 > > We have to FH JIRA epics that rely on the above being delivered: > * https://issues.jboss.org/browse/FH-4361 > * https://issues.jboss.org/browse/FH-4362 > > Please review these and add comments/questions/suggestions as needed! > > Thanks! > -Matthias > > > -- > Project lead AeroGear.org > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Mon Nov 20 15:42:37 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Mon, 20 Nov 2017 16:42:37 +0100 Subject: [feedhenry-dev] MCP: Push integration JIRAs In-Reply-To: References: Message-ID: Perhaps let's get a separated call? 30 min is perhaps short for all of that On Mon, Nov 20, 2017 at 4:39 PM, Phil Brookes wrote: > Might be worth discussing the Prometheus Jira's in the same call? > > https://issues.jboss.org/browse/FH-4356 > https://issues.jboss.org/browse/FH-4357 > https://issues.jboss.org/browse/FH-4358 > https://issues.jboss.org/browse/FH-4359 > https://issues.jboss.org/browse/FH-4360 > > Regards, > Phil, > > On Mon, Nov 20, 2017 at 3:14 PM, Matthias Wessendorf > wrote: > >> Hi folks! >> >> based on our quick call this morning, I've created three epics to should >> cover the three main bodies of work for getting UPS integrated to MCP >> >> While this one lives in the AeroGear community: >> * https://issues.jboss.org/browse/AGPUSH-2216 >> >> We have to FH JIRA epics that rely on the above being delivered: >> * https://issues.jboss.org/browse/FH-4361 >> * https://issues.jboss.org/browse/FH-4362 >> >> Please review these and add comments/questions/suggestions as needed! >> >> Thanks! >> -Matthias >> >> >> -- >> Project lead AeroGear.org >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbrookes at redhat.com Mon Nov 20 15:56:13 2017 From: pbrookes at redhat.com (Phil Brookes) Date: Mon, 20 Nov 2017 15:56:13 +0000 Subject: [feedhenry-dev] MCP: Push integration JIRAs In-Reply-To: References: Message-ID: Sure thing, I'll set it up now. On Mon, Nov 20, 2017 at 3:42 PM, Matthias Wessendorf wrote: > Perhaps let's get a separated call? 30 min is perhaps short for all of > that > > On Mon, Nov 20, 2017 at 4:39 PM, Phil Brookes wrote: > >> Might be worth discussing the Prometheus Jira's in the same call? >> >> https://issues.jboss.org/browse/FH-4356 >> https://issues.jboss.org/browse/FH-4357 >> https://issues.jboss.org/browse/FH-4358 >> https://issues.jboss.org/browse/FH-4359 >> https://issues.jboss.org/browse/FH-4360 >> >> Regards, >> Phil, >> >> On Mon, Nov 20, 2017 at 3:14 PM, Matthias Wessendorf > > wrote: >> >>> Hi folks! >>> >>> based on our quick call this morning, I've created three epics to should >>> cover the three main bodies of work for getting UPS integrated to MCP >>> >>> While this one lives in the AeroGear community: >>> * https://issues.jboss.org/browse/AGPUSH-2216 >>> >>> We have to FH JIRA epics that rely on the above being delivered: >>> * https://issues.jboss.org/browse/FH-4361 >>> * https://issues.jboss.org/browse/FH-4362 >>> >>> Please review these and add comments/questions/suggestions as needed! >>> >>> Thanks! >>> -Matthias >>> >>> >>> -- >>> Project lead AeroGear.org >>> >>> _______________________________________________ >>> feedhenry-dev mailing list >>> feedhenry-dev at redhat.com >>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>> >>> >> > > > -- > Project lead AeroGear.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwright at redhat.com Wed Nov 22 13:59:13 2017 From: pwright at redhat.com (Paul Wright) Date: Wed, 22 Nov 2017 13:59:13 +0000 Subject: [feedhenry-dev] Upstream Community Documentation Message-ID: <7da1aebd-2cdc-104a-a694-b9720d30647c@redhat.com> Hi AeroGear, FeedHenry As part of a review of Digger (Build Farm) docs,? I created a PR 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/ ) 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 over to digger doc on 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wtrocki at redhat.com Wed Nov 22 15:02:37 2017 From: wtrocki at redhat.com (Wojciech Trocki) Date: Wed, 22 Nov 2017 15:02:37 +0000 Subject: [feedhenry-dev] Upstream Community Documentation In-Reply-To: <7da1aebd-2cdc-104a-a694-b9720d30647c@redhat.com> References: <7da1aebd-2cdc-104a-a694-b9720d30647c@redhat.com> Message-ID: Thanks for raising that question - I think it's really important to talk about it. I think we had the similar conversation 6 months ago when kickstarting RainCatcher docs. Personally I think is essential for every project to have his own landing sub page (with documentation,demo video etc.) that can be accessed easily from feedhenry, aerogear main web pages. In RainCatcher we went even further and created separate web page (that is linked in feedhenry.org). This works pretty well as documentation, getting started etc. is exposed directly on the main page. I think that feedhenry.org has really good layout itself when listing all projects. We could just provide less information so people looking for something specific will not need to scroll too much. Spring (any many other aggregating communities) do the same. For example: https://spring.io/docs/reference We can apply similar list to aerogear website - however I'm not aware of the impact or challenges in that area) On Wed, Nov 22, 2017 at 1:59 PM, Paul Wright wrote: > Hi AeroGear, FeedHenry > > As part of a review of Digger (Build Farm) docs, I created a PR > 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/) > > 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 over to digger > doc on 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 > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- WOJCIECH TROCKI Red Hat Mobile IM: wtrocki -------------- next part -------------- An HTML attachment was scrubbed... URL: From matzew at apache.org Thu Nov 23 08:13:44 2017 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 23 Nov 2017 09:13:44 +0100 Subject: [feedhenry-dev] [aerogear-dev] Upstream Community Documentation In-Reply-To: <7da1aebd-2cdc-104a-a694-b9720d30647c@redhat.com> References: <7da1aebd-2cdc-104a-a694-b9720d30647c@redhat.com> Message-ID: Hi Paul, lot's of content on the AeroGear website is out of date, due to lack of work in the past two years (see the planing page). Note: the sync was a prototype, for real-time sync; based on different algorithms and papers in that area, but never went really anywere... I guess it's dead now. Over the past two years we did work a bit on the AeroGear Push server, and their libraries (e.g. mobile client-side lib and server-side integrations for node/java). Regarding Digger - it's a standalone project, under the aerogear realm - like push. Both bits can be used completely independent. I think some content (e.g. sync) needs to be removed (while we can still keep the repos), but we should be perhaps focusing on AeroGear UPS and digger, for community offerings. ag.org/push (like is) ag.org/digger (with backgrounds motivations, Laura's videos etc) Regarding feedhenry / mcp , just one comment: it does integrate w/ AG features, such as push or digger, and will IMO offer the integration parts (e.g. APBs etc) -Matthias On Wed, Nov 22, 2017 at 2:59 PM, Paul Wright wrote: > Hi AeroGear, FeedHenry > > As part of a review of Digger (Build Farm) docs, I created a PR > 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/) > > 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 over to digger > doc on 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 > > _______________________________________________ > 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/ twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: From aliok at redhat.com Thu Nov 23 13:09:49 2017 From: aliok at redhat.com (Ali Ok) Date: Thu, 23 Nov 2017 14:09:49 +0100 Subject: [feedhenry-dev] [aerogear-dev] Upstream Community Documentation In-Reply-To: References: <7da1aebd-2cdc-104a-a694-b9720d30647c@redhat.com> Message-ID: Hello, FYI, once I started this epic to improve and clean up AeroGear.org website: https://issues.jboss.org/browse/AEROGEAR-1760 If we would like to do it, we need to find out a group that takes ownership of the clean up. AeroGear people are now more spread than before. Cheers On Thu, Nov 23, 2017 at 9:13 AM, Matthias Wessendorf wrote: > Hi Paul, > > lot's of content on the AeroGear website is out of date, due to lack of > work in the past two years (see the planing page). > > Note: the sync was a prototype, for real-time sync; based on different > algorithms and papers in that area, but never went really anywere... > I guess it's dead now. > > Over the past two years we did work a bit on the AeroGear Push server, and > their libraries (e.g. mobile client-side lib and server-side integrations > for node/java). > > Regarding Digger - it's a standalone project, under the aerogear realm - > like push. Both bits can be used completely independent. > > > I think some content (e.g. sync) needs to be removed (while we can still > keep the repos), but we should be perhaps focusing on AeroGear UPS and > digger, for community offerings. > > ag.org/push (like is) > ag.org/digger (with backgrounds motivations, Laura's videos etc) > > > Regarding feedhenry / mcp , just one comment: it does integrate w/ AG > features, such as push or digger, and will IMO offer the integration parts > (e.g. APBs etc) > > > -Matthias > > > On Wed, Nov 22, 2017 at 2:59 PM, Paul Wright wrote: > >> Hi AeroGear, FeedHenry >> >> As part of a review of Digger (Build Farm) docs, I created a PR >> 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/) >> >> 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 over to >> digger doc on 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 >> >> _______________________________________________ >> 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/ > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfrizell at redhat.com Thu Nov 23 13:23:33 2017 From: jfrizell at redhat.com (John Frizelle) Date: Thu, 23 Nov 2017 13:23:33 +0000 Subject: [feedhenry-dev] [aerogear-dev] Upstream Community Documentation In-Reply-To: References: <7da1aebd-2cdc-104a-a694-b9720d30647c@redhat.com> Message-ID: Hi All, I would like to get people's thoughts on the cost / benefit of continuing to maintain both the feedhenry and aerogear communities (mailing lists, IRC channels, web sites etc...). There seems to be a lot of cross over between the two (the are both mobile focused communities backed primarily by Red Hat) and I struggle to see what benefit we, or our community members, get from having our work spread across these two communities... >From my perspective, I would rather see one healthy, vibrant community that we can all get behind instead of the current fractured status where it is unclear what lives where and why. Just my 2 cents... Cheers, John. -- John Frizelle Chief Architect, Red Hat Mobile Consulting Engineer mobile: *+353 87 290 1644 * twitter:* @johnfriz* skype: *john_frizelle* mail: *jfrizell at redhat.com * On 23 November 2017 at 13:09, Ali Ok wrote: > Hello, > > FYI, once I started this epic to improve and clean up AeroGear.org > website: https://issues.jboss.org/browse/AEROGEAR-1760 > > If we would like to do it, we need to find out a group that takes > ownership of the clean up. AeroGear people are now more spread than before. > > Cheers > > On Thu, Nov 23, 2017 at 9:13 AM, Matthias Wessendorf > wrote: > >> Hi Paul, >> >> lot's of content on the AeroGear website is out of date, due to lack of >> work in the past two years (see the planing page). >> >> Note: the sync was a prototype, for real-time sync; based on different >> algorithms and papers in that area, but never went really anywere... >> I guess it's dead now. >> >> Over the past two years we did work a bit on the AeroGear Push server, >> and their libraries (e.g. mobile client-side lib and server-side >> integrations for node/java). >> >> Regarding Digger - it's a standalone project, under the aerogear realm - >> like push. Both bits can be used completely independent. >> >> >> I think some content (e.g. sync) needs to be removed (while we can still >> keep the repos), but we should be perhaps focusing on AeroGear UPS and >> digger, for community offerings. >> >> ag.org/push (like is) >> ag.org/digger (with backgrounds motivations, Laura's videos etc) >> >> >> Regarding feedhenry / mcp , just one comment: it does integrate w/ AG >> features, such as push or digger, and will IMO offer the integration parts >> (e.g. APBs etc) >> >> >> -Matthias >> >> >> On Wed, Nov 22, 2017 at 2:59 PM, Paul Wright wrote: >> >>> Hi AeroGear, FeedHenry >>> >>> As part of a review of Digger (Build Farm) docs, I created a PR >>> 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/) >>> >>> 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 over to >>> digger doc on 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 >>> >>> _______________________________________________ >>> 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/ >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 11472 bytes Desc: not available URL: From matzew at apache.org Thu Nov 23 13:39:52 2017 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 23 Nov 2017 14:39:52 +0100 Subject: [feedhenry-dev] [aerogear-dev] Upstream Community Documentation In-Reply-To: References: <7da1aebd-2cdc-104a-a694-b9720d30647c@redhat.com> Message-ID: I personally don't have a problem with moving them together (e.g. move the UPS to FeedHenry). The name aerogear for most people was always attached to the Push Server. Perhaps we call the UPS -> FH AeroGear Push :) ? But the rest, especially the client modular libs,.. yeah - I don't have an opinion where they should live. On Thu, Nov 23, 2017 at 2:23 PM, John Frizelle wrote: > Hi All, > > I would like to get people's thoughts on the cost / benefit of continuing > to maintain both the feedhenry and aerogear communities (mailing lists, IRC > channels, web sites etc...). There seems to be a lot of cross over between > the two (the are both mobile focused communities backed primarily by Red > Hat) and I struggle to see what benefit we, or our community members, get > from having our work spread across these two communities... > > From my perspective, I would rather see one healthy, vibrant community > that we can all get behind instead of the current fractured status where it > is unclear what lives where and why. > > Just my 2 cents... > > Cheers, > John. > > > -- > John Frizelle > Chief Architect, Red Hat Mobile > Consulting Engineer > > mobile: *+353 87 290 1644 * > twitter:* @johnfriz* > skype: *john_frizelle* > mail: *jfrizell at redhat.com * > > > > > On 23 November 2017 at 13:09, Ali Ok wrote: > >> Hello, >> >> FYI, once I started this epic to improve and clean up AeroGear.org >> website: https://issues.jboss.org/browse/AEROGEAR-1760 >> >> If we would like to do it, we need to find out a group that takes >> ownership of the clean up. AeroGear people are now more spread than before. >> >> Cheers >> >> On Thu, Nov 23, 2017 at 9:13 AM, Matthias Wessendorf >> wrote: >> >>> Hi Paul, >>> >>> lot's of content on the AeroGear website is out of date, due to lack of >>> work in the past two years (see the planing page). >>> >>> Note: the sync was a prototype, for real-time sync; based on different >>> algorithms and papers in that area, but never went really anywere... >>> I guess it's dead now. >>> >>> Over the past two years we did work a bit on the AeroGear Push server, >>> and their libraries (e.g. mobile client-side lib and server-side >>> integrations for node/java). >>> >>> Regarding Digger - it's a standalone project, under the aerogear realm - >>> like push. Both bits can be used completely independent. >>> >>> >>> I think some content (e.g. sync) needs to be removed (while we can still >>> keep the repos), but we should be perhaps focusing on AeroGear UPS and >>> digger, for community offerings. >>> >>> ag.org/push (like is) >>> ag.org/digger (with backgrounds motivations, Laura's videos etc) >>> >>> >>> Regarding feedhenry / mcp , just one comment: it does integrate w/ AG >>> features, such as push or digger, and will IMO offer the integration parts >>> (e.g. APBs etc) >>> >>> >>> -Matthias >>> >>> >>> On Wed, Nov 22, 2017 at 2:59 PM, Paul Wright wrote: >>> >>>> Hi AeroGear, FeedHenry >>>> >>>> As part of a review of Digger (Build Farm) docs, I created a PR >>>> 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/) >>>> >>>> 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 over to >>>> digger doc on 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 >>>> >>>> _______________________________________________ >>>> 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/ >>> twitter: http://twitter.com/mwessendorf >>> >>> _______________________________________________ >>> feedhenry-dev mailing list >>> feedhenry-dev at redhat.com >>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>> >>> >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 11472 bytes Desc: not available URL: From wtrocki at redhat.com Thu Nov 23 14:15:20 2017 From: wtrocki at redhat.com (Wojciech Trocki) Date: Thu, 23 Nov 2017 14:15:20 +0000 Subject: [feedhenry-dev] [aerogear-dev] Upstream Community Documentation In-Reply-To: References: <7da1aebd-2cdc-104a-a694-b9720d30647c@redhat.com> Message-ID: > I would rather see one healthy, vibrant community that we can all get behind instead of the current fractured status where it is unclear what lives where and why. +1. Aerohenry ;) IMHO Best to have single website address (it can even have 2 communities, project labels etc) for all work we do. MCP will be the common element that will join all community projects together so it's make sense to aggregate them in one place. It may also help with all documentation efforts. Lots of people already maintaining projects for both communities. On Thu, Nov 23, 2017 at 1:39 PM, Matthias Wessendorf wrote: > I personally don't have a problem with moving them together (e.g. move the > UPS to FeedHenry). The name aerogear for most people was always attached to > the Push Server. Perhaps we call the UPS -> FH AeroGear Push :) ? > > But the rest, especially the client modular libs,.. yeah - I don't have an > opinion where they should live. > > On Thu, Nov 23, 2017 at 2:23 PM, John Frizelle > wrote: > >> Hi All, >> >> I would like to get people's thoughts on the cost / benefit of continuing >> to maintain both the feedhenry and aerogear communities (mailing lists, IRC >> channels, web sites etc...). There seems to be a lot of cross over between >> the two (the are both mobile focused communities backed primarily by Red >> Hat) and I struggle to see what benefit we, or our community members, get >> from having our work spread across these two communities... >> >> From my perspective, I would rather see one healthy, vibrant community >> that we can all get behind instead of the current fractured status where it >> is unclear what lives where and why. >> >> Just my 2 cents... >> >> Cheers, >> John. >> >> >> -- >> John Frizelle >> Chief Architect, Red Hat Mobile >> Consulting Engineer >> >> mobile: *+353 87 290 1644 * >> twitter:* @johnfriz* >> skype: *john_frizelle* >> mail: *jfrizell at redhat.com * >> >> >> >> >> On 23 November 2017 at 13:09, Ali Ok wrote: >> >>> Hello, >>> >>> FYI, once I started this epic to improve and clean up AeroGear.org >>> website: https://issues.jboss.org/browse/AEROGEAR-1760 >>> >>> If we would like to do it, we need to find out a group that takes >>> ownership of the clean up. AeroGear people are now more spread than before. >>> >>> Cheers >>> >>> On Thu, Nov 23, 2017 at 9:13 AM, Matthias Wessendorf >>> wrote: >>> >>>> Hi Paul, >>>> >>>> lot's of content on the AeroGear website is out of date, due to lack of >>>> work in the past two years (see the planing page). >>>> >>>> Note: the sync was a prototype, for real-time sync; based on different >>>> algorithms and papers in that area, but never went really anywere... >>>> I guess it's dead now. >>>> >>>> Over the past two years we did work a bit on the AeroGear Push server, >>>> and their libraries (e.g. mobile client-side lib and server-side >>>> integrations for node/java). >>>> >>>> Regarding Digger - it's a standalone project, under the aerogear realm >>>> - like push. Both bits can be used completely independent. >>>> >>>> >>>> I think some content (e.g. sync) needs to be removed (while we can >>>> still keep the repos), but we should be perhaps focusing on AeroGear UPS >>>> and digger, for community offerings. >>>> >>>> ag.org/push (like is) >>>> ag.org/digger (with backgrounds motivations, Laura's videos etc) >>>> >>>> >>>> Regarding feedhenry / mcp , just one comment: it does integrate w/ AG >>>> features, such as push or digger, and will IMO offer the integration parts >>>> (e.g. APBs etc) >>>> >>>> >>>> -Matthias >>>> >>>> >>>> On Wed, Nov 22, 2017 at 2:59 PM, Paul Wright >>>> wrote: >>>> >>>>> Hi AeroGear, FeedHenry >>>>> >>>>> As part of a review of Digger (Build Farm) docs, I created a PR >>>>> 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/) >>>>> >>>>> 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 over to >>>>> digger doc on 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 >>>>> >>>>> _______________________________________________ >>>>> 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/ >>>> twitter: http://twitter.com/mwessendorf >>>> >>>> _______________________________________________ >>>> feedhenry-dev mailing list >>>> feedhenry-dev at redhat.com >>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>> >>>> >>> >>> _______________________________________________ >>> feedhenry-dev mailing list >>> feedhenry-dev at redhat.com >>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>> >>> >> > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- WOJCIECH TROCKI Red Hat Mobile IM: wtrocki -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 11472 bytes Desc: not available URL: From weil at redhat.com Thu Nov 23 14:46:54 2017 From: weil at redhat.com (Wei Li) Date: Thu, 23 Nov 2017 14:46:54 +0000 Subject: [feedhenry-dev] [aerogear-dev] Upstream Community Documentation In-Reply-To: References: <7da1aebd-2cdc-104a-a694-b9720d30647c@redhat.com> Message-ID: +1. Maintaining 2 communities with similar objectives are just too confusing to a lot of people. I would like to see them merged as well. On Thu, Nov 23, 2017 at 1:23 PM, John Frizelle wrote: > Hi All, > > I would like to get people's thoughts on the cost / benefit of continuing > to maintain both the feedhenry and aerogear communities (mailing lists, IRC > channels, web sites etc...). There seems to be a lot of cross over between > the two (the are both mobile focused communities backed primarily by Red > Hat) and I struggle to see what benefit we, or our community members, get > from having our work spread across these two communities... > > From my perspective, I would rather see one healthy, vibrant community > that we can all get behind instead of the current fractured status where it > is unclear what lives where and why. > > Just my 2 cents... > > Cheers, > John. > > > -- > John Frizelle > Chief Architect, Red Hat Mobile > Consulting Engineer > > mobile: *+353 87 290 1644 * > twitter:* @johnfriz* > skype: *john_frizelle* > mail: *jfrizell at redhat.com * > > > > > On 23 November 2017 at 13:09, Ali Ok wrote: > >> Hello, >> >> FYI, once I started this epic to improve and clean up AeroGear.org >> website: https://issues.jboss.org/browse/AEROGEAR-1760 >> >> If we would like to do it, we need to find out a group that takes >> ownership of the clean up. AeroGear people are now more spread than before. >> >> Cheers >> >> On Thu, Nov 23, 2017 at 9:13 AM, Matthias Wessendorf >> wrote: >> >>> Hi Paul, >>> >>> lot's of content on the AeroGear website is out of date, due to lack of >>> work in the past two years (see the planing page). >>> >>> Note: the sync was a prototype, for real-time sync; based on different >>> algorithms and papers in that area, but never went really anywere... >>> I guess it's dead now. >>> >>> Over the past two years we did work a bit on the AeroGear Push server, >>> and their libraries (e.g. mobile client-side lib and server-side >>> integrations for node/java). >>> >>> Regarding Digger - it's a standalone project, under the aerogear realm - >>> like push. Both bits can be used completely independent. >>> >>> >>> I think some content (e.g. sync) needs to be removed (while we can still >>> keep the repos), but we should be perhaps focusing on AeroGear UPS and >>> digger, for community offerings. >>> >>> ag.org/push (like is) >>> ag.org/digger (with backgrounds motivations, Laura's videos etc) >>> >>> >>> Regarding feedhenry / mcp , just one comment: it does integrate w/ AG >>> features, such as push or digger, and will IMO offer the integration parts >>> (e.g. APBs etc) >>> >>> >>> -Matthias >>> >>> >>> On Wed, Nov 22, 2017 at 2:59 PM, Paul Wright wrote: >>> >>>> Hi AeroGear, FeedHenry >>>> >>>> As part of a review of Digger (Build Farm) docs, I created a PR >>>> 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/) >>>> >>>> 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 over to >>>> digger doc on 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 >>>> >>>> _______________________________________________ >>>> 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/ >>> twitter: http://twitter.com/mwessendorf >>> >>> _______________________________________________ >>> feedhenry-dev mailing list >>> feedhenry-dev at redhat.com >>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>> >>> >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- WEI LI SENIOR SOFTWARE ENGINEER Red Hat Mobile weil at redhat.com M: +353862393272 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 11472 bytes Desc: not available URL: From mwessend at redhat.com Thu Nov 23 20:49:24 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Thu, 23 Nov 2017 21:49:24 +0100 Subject: [feedhenry-dev] keycloak-apb issue: create auth token Message-ID: Hi, I need help with the keycloak-apb. I've changed it to consume 3.4.0: https://github.com/feedhenry/keycloak-apb/pull/29 and when provisioning it brings up the image correctly, I keep getting errors with this task: "Generate keycloak auth token": https://github.com/matzew/keycloak-apb/blob/2d2cfec2c1c5e7452e7537a7509d91642604e46a/roles/provision-keycloak-apb/tasks/main.yml#L61-L70 See: ``` FAILED - RETRYING: Generate keycloak auth token (344 retries left). FAILED - RETRYING: Generate keycloak auth token (343 retries left). FAILED - RETRYING: Generate keycloak auth token (342 retries left). FAILED - RETRYING: Generate keycloak auth token (341 retries left). FAILED - RETRYING: Generate keycloak auth token (340 retries left). FAILED - RETRYING: Generate keycloak auth token (339 retries left). FAILED - RETRYING: Generate keycloak auth token (338 retries left). FAILED - RETRYING: Generate keycloak auth token (337 retries left). FAILED - RETRYING: Generate keycloak auth token (336 retries left). FAILED - RETRYING: Generate keycloak auth token (335 retries left). FAILED - RETRYING: Generate keycloak auth token (334 retries left). FAILED - RETRYING: Generate keycloak auth token (333 retries left). FAILED - RETRYING: Generate keycloak auth token (332 retries left). FAILED - RETRYING: Generate keycloak auth token (331 retries left). FAILED - RETRYING: Generate keycloak auth token (330 retries left). FAILED - RETRYING: Generate keycloak auth token (329 retries left). FAILED - RETRYING: Generate keycloak auth token (328 retries left). FAILED - RETRYING: Generate keycloak auth token (327 retries left). FAILED - RETRYING: Generate keycloak auth token (326 retries left). FAILED - RETRYING: Generate keycloak auth token (325 retries left). FAILED - RETRYING: Generate keycloak auth token (324 retries left). ``` The weird thing is... translating that translating this into a vanilla CURL... it all works: ``` curl -v --data "grant_type=password&client_id=admin-cli&username=${USER}&password=${PASS}" http://keycloak-testapp.192.168.37.1.nip.io/auth/realms/master/protocol/openid-connect/token ``` I get a JSON {access_token":"......... Now,.... I've tried the same, with the old 2.5.4 image from Jimmi - and I get the same "FAILED - RETRYING: Generate keycloak auth token (338 retries left)" ... I've double checked, and ssh'ed into the pod, checking the contents of the actions - and yes, the pod now is 2.5.4 ... :-( So... perhaps... there is something wrong ? I use apb:latest (from upstream - not feedhenry) - and of course our MCP master (Origin v3.7.0-rc-0) Can one try the PR and see if that works for him ? (make apb_build && make apb_push) PS: you need to give the developer the 'cluster-admin' role, in order to push ... Phil and I ran into that earlier this week ... Thanks! -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Thu Nov 23 21:08:14 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Thu, 23 Nov 2017 22:08:14 +0100 Subject: [feedhenry-dev] local apb development Message-ID: Hi, when wanting to do 'apb push' (e.g. via our Makefile), as the 'developer' on openshift, you need to (locally) grant him 'cluster-admin' role. Phil and I ran into some issues earlier this week, and w/ the #asbroker folks we sorted it. Here is how: ``` oc login -u system:admin oc adm policy add-cluster-role-to-user cluster-admin developer ``` This at least does apply to the ''docker.io/ansibleplaybookbundle/apb:latest" image and our master (running 139.1 ASB on Openshift 370-rc0) Anyone similar experience? Cheers, Matthias -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From davmarti at redhat.com Fri Nov 24 09:24:19 2017 From: davmarti at redhat.com (David Martin) Date: Fri, 24 Nov 2017 09:24:19 +0000 Subject: [feedhenry-dev] local apb development In-Reply-To: References: Message-ID: I've seen errors at the end running of the 3scale apb 'make'. This sounds like the exact problem I saw. It didn't block me as the apb image was already pushed to my docker hub repository, but I did need to manually redeploy the asb (and re-create the etcd pv) to pick up on the change. If the role is added to 'developer', will that mean the broker will get updated with the new apb image locally when doing a 'make' ? On 23 November 2017 at 21:08, Matthias Wessendorf wrote: > Hi, > > when wanting to do 'apb push' (e.g. via our Makefile), as the 'developer' > on openshift, you need to (locally) grant him 'cluster-admin' role. > > Phil and I ran into some issues earlier this week, and w/ the #asbroker > folks we sorted it. > > Here is how: > ``` > oc login -u system:admin > oc adm policy add-cluster-role-to-user cluster-admin developer > ``` > > This at least does apply to the ''docker.io/ansibleplaybookbundle/apb: > latest" image and our master (running 139.1 ASB on Openshift 370-rc0) > > Anyone similar experience? > > Cheers, > Matthias > > > -- > Project lead AeroGear.org > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From davmarti at redhat.com Fri Nov 24 09:30:43 2017 From: davmarti at redhat.com (David Martin) Date: Fri, 24 Nov 2017 09:30:43 +0000 Subject: [feedhenry-dev] keycloak-apb issue: create auth token In-Reply-To: References: Message-ID: Hey Matthias, I have seen this happen (on someone elses machine). It turned out to be missing firewall rules as the pod couldn't reach the keycloak pod/network Might be worth checking your rules agains the docs https://github.com/feedhenry/mcp-standalone/blob/master/ docs/walkthroughs/local-setup.adoc#firewall-requirements-required On linux (Fedora 25), here's my rules firewall-cmd --info-zone dockerc dockerc (active) target: default icmp-block-inversion: no interfaces: sources: 172.17.0.0/16 services: ports: 443/tcp 53/udp 80/tcp 8443/tcp 8053/udp 5353/udp 8080/tcp protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: selinux may play a part either, so you could try disabling temporarily to see if that works around the problem. On 23 November 2017 at 20:49, Matthias Wessendorf wrote: > Hi, > > I need help with the keycloak-apb. I've changed it to consume 3.4.0: > > https://github.com/feedhenry/keycloak-apb/pull/29 > > and when provisioning it brings up the image correctly, I keep getting > errors with this task: > > "Generate keycloak auth token": > https://github.com/matzew/keycloak-apb/blob/2d2cfec2c1c5e7452e7537a7509d91 > 642604e46a/roles/provision-keycloak-apb/tasks/main.yml#L61-L70 > > See: > > ``` > FAILED - RETRYING: Generate keycloak auth token (344 retries left). > FAILED - RETRYING: Generate keycloak auth token (343 retries left). > FAILED - RETRYING: Generate keycloak auth token (342 retries left). > FAILED - RETRYING: Generate keycloak auth token (341 retries left). > FAILED - RETRYING: Generate keycloak auth token (340 retries left). > FAILED - RETRYING: Generate keycloak auth token (339 retries left). > FAILED - RETRYING: Generate keycloak auth token (338 retries left). > FAILED - RETRYING: Generate keycloak auth token (337 retries left). > FAILED - RETRYING: Generate keycloak auth token (336 retries left). > FAILED - RETRYING: Generate keycloak auth token (335 retries left). > FAILED - RETRYING: Generate keycloak auth token (334 retries left). > FAILED - RETRYING: Generate keycloak auth token (333 retries left). > FAILED - RETRYING: Generate keycloak auth token (332 retries left). > FAILED - RETRYING: Generate keycloak auth token (331 retries left). > FAILED - RETRYING: Generate keycloak auth token (330 retries left). > FAILED - RETRYING: Generate keycloak auth token (329 retries left). > FAILED - RETRYING: Generate keycloak auth token (328 retries left). > FAILED - RETRYING: Generate keycloak auth token (327 retries left). > FAILED - RETRYING: Generate keycloak auth token (326 retries left). > FAILED - RETRYING: Generate keycloak auth token (325 retries left). > FAILED - RETRYING: Generate keycloak auth token (324 retries left). > ``` > > The weird thing is... translating that translating this into a vanilla > CURL... it all works: > > ``` > curl -v --data "grant_type=password&client_id=admin-cli&username=${USER}&password=${PASS}" > http://keycloak-testapp.192.168.37.1.nip.io/auth/realms/ > master/protocol/openid-connect/token > ``` > > I get a JSON {access_token":"......... > > > > Now,.... I've tried the same, with the old 2.5.4 image from Jimmi - and I > get the same "FAILED - RETRYING: Generate keycloak auth token (338 retries > left)" ... I've double checked, and ssh'ed into the pod, checking the > contents of the actions - and yes, the pod now is 2.5.4 ... :-( > > > So... perhaps... there is something wrong ? > > I use apb:latest (from upstream - not feedhenry) - and of course our MCP > master (Origin v3.7.0-rc-0) > > > > Can one try the PR and see if that works for him ? > (make apb_build && make apb_push) > > PS: you need to give the developer the 'cluster-admin' role, in order to > push ... Phil and I ran into that earlier this week ... > > > Thanks! > > > > > > -- > Project lead AeroGear.org > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbrookes at redhat.com Fri Nov 24 09:53:50 2017 From: pbrookes at redhat.com (Phil Brookes) Date: Fri, 24 Nov 2017 09:53:50 +0000 Subject: [feedhenry-dev] local apb development In-Reply-To: References: Message-ID: Hey Dave, Yeah if the apb push works then your local catalog get?s the updated apb.yml metadata without having to respin the entire local cluster. Regards, Phil. ? On Fri, Nov 24, 2017 at 9:24 AM, David Martin wrote: > I've seen errors at the end running of the 3scale apb 'make'. > This sounds like the exact problem I saw. > It didn't block me as the apb image was already pushed to my docker hub > repository, > but I did need to manually redeploy the asb (and re-create the etcd pv) to > pick up on the change. > > If the role is added to 'developer', will that mean the broker will get > updated with the new apb image locally when doing a 'make' ? > > On 23 November 2017 at 21:08, Matthias Wessendorf > wrote: > >> Hi, >> >> when wanting to do 'apb push' (e.g. via our Makefile), as the 'developer' >> on openshift, you need to (locally) grant him 'cluster-admin' role. >> >> Phil and I ran into some issues earlier this week, and w/ the #asbroker >> folks we sorted it. >> >> Here is how: >> ``` >> oc login -u system:admin >> oc adm policy add-cluster-role-to-user cluster-admin developer >> ``` >> >> This at least does apply to the ''docker.io/ansibleplaybookbun >> dle/apb:latest" image and our master (running 139.1 ASB on Openshift >> 370-rc0) >> >> Anyone similar experience? >> >> Cheers, >> Matthias >> >> >> -- >> Project lead AeroGear.org >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > > -- > David Martin > Red Hat Mobile > Twitter: @irldavem > IRC: @irldavem (feedhenry, mobile-internal) > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Fri Nov 24 11:33:58 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Fri, 24 Nov 2017 12:33:58 +0100 Subject: [feedhenry-dev] local apb development In-Reply-To: References: Message-ID: it works instantly :-) On Fri, Nov 24, 2017 at 10:53 AM, Phil Brookes wrote: > Hey Dave, > > Yeah if the apb push works then your local catalog get?s the updated > apb.yml metadata without having to respin the entire local cluster. > > Regards, > Phil. > ? > > On Fri, Nov 24, 2017 at 9:24 AM, David Martin wrote: > >> I've seen errors at the end running of the 3scale apb 'make'. >> This sounds like the exact problem I saw. >> It didn't block me as the apb image was already pushed to my docker hub >> repository, >> but I did need to manually redeploy the asb (and re-create the etcd pv) >> to pick up on the change. >> >> If the role is added to 'developer', will that mean the broker will get >> updated with the new apb image locally when doing a 'make' ? >> >> On 23 November 2017 at 21:08, Matthias Wessendorf >> wrote: >> >>> Hi, >>> >>> when wanting to do 'apb push' (e.g. via our Makefile), as the >>> 'developer' on openshift, you need to (locally) grant him 'cluster-admin' >>> role. >>> >>> Phil and I ran into some issues earlier this week, and w/ the #asbroker >>> folks we sorted it. >>> >>> Here is how: >>> ``` >>> oc login -u system:admin >>> oc adm policy add-cluster-role-to-user cluster-admin developer >>> ``` >>> >>> This at least does apply to the ''docker.io/ansibleplaybookbun >>> dle/apb:latest" image and our master (running 139.1 ASB on Openshift >>> 370-rc0) >>> >>> Anyone similar experience? >>> >>> Cheers, >>> Matthias >>> >>> >>> -- >>> Project lead AeroGear.org >>> >>> _______________________________________________ >>> feedhenry-dev mailing list >>> feedhenry-dev at redhat.com >>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>> >>> >> >> >> -- >> David Martin >> Red Hat Mobile >> Twitter: @irldavem >> IRC: @irldavem (feedhenry, mobile-internal) >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From davmarti at redhat.com Fri Nov 24 12:11:43 2017 From: davmarti at redhat.com (David Martin) Date: Fri, 24 Nov 2017 12:11:43 +0000 Subject: [feedhenry-dev] Demo Video of Alternative Mobile UI in OpenShift, and going without a mobile server Message-ID: Interested in peoples thoughts on this approach. 6 mins: https://youtu.be/MTGt2upKcMs I forked the origin-web-console for this demo. Changes here https://github.com/david-martin/origin-web-console/tree/mobile-service-integrations-poc This change is intended to go hand in hand with a kubernetes plugin approach for a 'mobile cli' (should be able to share something on that soon) For the -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbrookes at redhat.com Fri Nov 24 12:58:25 2017 From: pbrookes at redhat.com (Phil Brookes) Date: Fri, 24 Nov 2017 12:58:25 +0000 Subject: [feedhenry-dev] Demo Video of Alternative Mobile UI in OpenShift, and going without a mobile server In-Reply-To: References: Message-ID: That was a great demonstration, thanks Dave, I?m very impressed with what can be achieved with only front-end code. ? On Fri, Nov 24, 2017 at 12:11 PM, David Martin wrote: > Interested in peoples thoughts on this approach. > > 6 mins: https://youtu.be/MTGt2upKcMs > > I forked the origin-web-console for this demo. > Changes here https://github.com/david-martin/origin-web-console/ > tree/mobile-service-integrations-poc > > This change is intended to go hand in hand with a kubernetes plugin > approach for a 'mobile cli' (should be able to share something on that soon) > > > > For the > -- > David Martin > Red Hat Mobile > Twitter: @irldavem > IRC: @irldavem (feedhenry, mobile-internal) > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Fri Nov 24 20:30:12 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Fri, 24 Nov 2017 21:30:12 +0100 Subject: [feedhenry-dev] Demo Video of Alternative Mobile UI in OpenShift, and going without a mobile server In-Reply-To: References: Message-ID: Nice one! I have to say, I really like it! Also, removing the 'Mobile' on the left nav panel may have benefits to keep Openshift plain and vanilla - great job! On Fri, Nov 24, 2017 at 1:11 PM, David Martin wrote: > Interested in peoples thoughts on this approach. > > 6 mins: https://youtu.be/MTGt2upKcMs > > I forked the origin-web-console for this demo. > Changes here https://github.com/david-martin/origin-web-console/ > tree/mobile-service-integrations-poc > > This change is intended to go hand in hand with a kubernetes plugin > approach for a 'mobile cli' (should be able to share something on that soon) > > > > For the > -- > David Martin > Red Hat Mobile > Twitter: @irldavem > IRC: @irldavem (feedhenry, mobile-internal) > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Mon Nov 27 08:36:40 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Mon, 27 Nov 2017 09:36:40 +0100 Subject: [feedhenry-dev] keycloak-apb issue: create auth token In-Reply-To: References: Message-ID: Hey Dave, it used to work, but checking I see I had a few ports less than you: ports: 8443/tcp 53/udp 8053/udp 443/tcp updating now, and trying it all again On Fri, Nov 24, 2017 at 10:30 AM, David Martin wrote: > Hey Matthias, > > > I have seen this happen (on someone elses machine). > It turned out to be missing firewall rules as the pod couldn't reach the > keycloak pod/network > > Might be worth checking your rules agains the docs > https://github.com/feedhenry/mcp-standalone/blob/master/docs > /walkthroughs/local-setup.adoc#firewall-requirements-required > > On linux (Fedora 25), here's my rules > > firewall-cmd --info-zone dockerc > dockerc (active) > target: default > icmp-block-inversion: no > interfaces: > sources: 172.17.0.0/16 > services: > ports: 443/tcp 53/udp 80/tcp 8443/tcp 8053/udp 5353/udp 8080/tcp > protocols: > masquerade: no > forward-ports: > source-ports: > icmp-blocks: > rich rules: > > selinux may play a part either, so you could try disabling temporarily to > see if that works around the problem. > > > On 23 November 2017 at 20:49, Matthias Wessendorf > wrote: > >> Hi, >> >> I need help with the keycloak-apb. I've changed it to consume 3.4.0: >> >> https://github.com/feedhenry/keycloak-apb/pull/29 >> >> and when provisioning it brings up the image correctly, I keep getting >> errors with this task: >> >> "Generate keycloak auth token": >> https://github.com/matzew/keycloak-apb/blob/2d2cfec2c1c5e745 >> 2e7537a7509d91642604e46a/roles/provision-keycloak-apb/ >> tasks/main.yml#L61-L70 >> >> See: >> >> ``` >> FAILED - RETRYING: Generate keycloak auth token (344 retries left). >> FAILED - RETRYING: Generate keycloak auth token (343 retries left). >> FAILED - RETRYING: Generate keycloak auth token (342 retries left). >> FAILED - RETRYING: Generate keycloak auth token (341 retries left). >> FAILED - RETRYING: Generate keycloak auth token (340 retries left). >> FAILED - RETRYING: Generate keycloak auth token (339 retries left). >> FAILED - RETRYING: Generate keycloak auth token (338 retries left). >> FAILED - RETRYING: Generate keycloak auth token (337 retries left). >> FAILED - RETRYING: Generate keycloak auth token (336 retries left). >> FAILED - RETRYING: Generate keycloak auth token (335 retries left). >> FAILED - RETRYING: Generate keycloak auth token (334 retries left). >> FAILED - RETRYING: Generate keycloak auth token (333 retries left). >> FAILED - RETRYING: Generate keycloak auth token (332 retries left). >> FAILED - RETRYING: Generate keycloak auth token (331 retries left). >> FAILED - RETRYING: Generate keycloak auth token (330 retries left). >> FAILED - RETRYING: Generate keycloak auth token (329 retries left). >> FAILED - RETRYING: Generate keycloak auth token (328 retries left). >> FAILED - RETRYING: Generate keycloak auth token (327 retries left). >> FAILED - RETRYING: Generate keycloak auth token (326 retries left). >> FAILED - RETRYING: Generate keycloak auth token (325 retries left). >> FAILED - RETRYING: Generate keycloak auth token (324 retries left). >> ``` >> >> The weird thing is... translating that translating this into a vanilla >> CURL... it all works: >> >> ``` >> curl -v --data "grant_type=password&client_id >> =admin-cli&username=${USER}&password=${PASS}" >> http://keycloak-testapp.192.168.37.1.nip.io/auth/realms/mast >> er/protocol/openid-connect/token >> ``` >> >> I get a JSON {access_token":"......... >> >> >> >> Now,.... I've tried the same, with the old 2.5.4 image from Jimmi - and I >> get the same "FAILED - RETRYING: Generate keycloak auth token (338 retries >> left)" ... I've double checked, and ssh'ed into the pod, checking the >> contents of the actions - and yes, the pod now is 2.5.4 ... :-( >> >> >> So... perhaps... there is something wrong ? >> >> I use apb:latest (from upstream - not feedhenry) - and of course our MCP >> master (Origin v3.7.0-rc-0) >> >> >> >> Can one try the PR and see if that works for him ? >> (make apb_build && make apb_push) >> >> PS: you need to give the developer the 'cluster-admin' role, in order to >> push ... Phil and I ran into that earlier this week ... >> >> >> Thanks! >> >> >> >> >> >> -- >> Project lead AeroGear.org >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > > -- > David Martin > Red Hat Mobile > Twitter: @irldavem > IRC: @irldavem (feedhenry, mobile-internal) > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From cbrookes at redhat.com Mon Nov 27 09:44:35 2017 From: cbrookes at redhat.com (Craig Brookes) Date: Mon, 27 Nov 2017 09:44:35 +0000 Subject: [feedhenry-dev] mobile client or mobile app Message-ID: Was thinking about terminology . We have been using the term mobile app, but I wonder would it be clearer to use the term mobile client instead. The main reason for this is that app can mean a server side component (in OpenShift there is the new-app command for example). I think it would make a clearer distinction. Another example is around the word build. When you do an app build in OpenShift it normally produces a docker image and a running server / app. I think using the the term mobile client build makes it clearer what is happening. Just a thought for a Monday morning. -- Craig Brookes RHMAP @maleck13 Github -------------- next part -------------- An HTML attachment was scrubbed... URL: From wtrocki at redhat.com Mon Nov 27 09:56:04 2017 From: wtrocki at redhat.com (Wojciech Trocki) Date: Mon, 27 Nov 2017 09:56:04 +0000 Subject: [feedhenry-dev] mobile client or mobile app In-Reply-To: References: Message-ID: +1 for using mobile client. Creating mobile apps on OpenShift sounds vague. On Mon, Nov 27, 2017 at 9:44 AM, Craig Brookes wrote: > Was thinking about terminology . We have been using the term mobile app, > but I wonder would it be clearer to use the term mobile client instead. > The main reason for this is that app can mean a server side component (in > OpenShift there is the new-app command for example). I think it would make > a clearer distinction. Another example is around the word build. When you > do an app build in OpenShift it normally produces a docker image and a > running server / app. I think using the the term mobile client build makes > it clearer what is happening. > > Just a thought for a Monday morning. > > -- > Craig Brookes > RHMAP > @maleck13 Github > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- WOJCIECH TROCKI Red Hat Mobile IM: wtrocki -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmadigan at redhat.com Mon Nov 27 11:03:33 2017 From: jmadigan at redhat.com (Jason Madigan) Date: Mon, 27 Nov 2017 11:03:33 +0000 Subject: [feedhenry-dev] mobile client or mobile app In-Reply-To: References: Message-ID: Deep thoughts this early in the week. App is quite a loaded term alright, particularly in an OpenShift context, so I think Mobile Client may be a clearer distinction. Looping in our wordsmith Paul who may have other ideas. On Mon, Nov 27, 2017 at 9:44 AM, Craig Brookes wrote: > Was thinking about terminology . We have been using the term mobile app, > but I wonder would it be clearer to use the term mobile client instead. > The main reason for this is that app can mean a server side component (in > OpenShift there is the new-app command for example). I think it would make > a clearer distinction. Another example is around the word build. When you > do an app build in OpenShift it normally produces a docker image and a > running server / app. I think using the the term mobile client build makes > it clearer what is happening. > > Just a thought for a Monday morning. > > -- > Craig Brookes > RHMAP > @maleck13 Github > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- Jason Madigan Engineering Manager, Red Hat Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwright at redhat.com Mon Nov 27 11:49:56 2017 From: pwright at redhat.com (Paul Wright) Date: Mon, 27 Nov 2017 11:49:56 +0000 Subject: [feedhenry-dev] mobile client or mobile app In-Reply-To: References: Message-ID: It seems to me that to tackle the mobile market, we should embrace the lingua franca, and the one word that unites mobile,cell phone, smartphone, handys, etc is 'App' Paul my original draft reply: Mondays... Let's fix everything I'm not against this change, but would like to throw in a note of caution: 1. I don't think OpenShift are really pushing the term apps. Sure, there's a command, and even some doc references (https://access.redhat.com/documentation/en-us/openshift_enterprise/3.2/html/installation_and_configuration/install-config-imagestreams-templates#creating-instantapp-templates), but would like to check with them before assuming that's deliberate. In my mind, their term of choice is Application, a bit more of an enterprisey term. 2. Does "Mobile Clients" solve a problem? we already have a generation of ppl saying "there's an app for that", do we want to embrace that or swim upstream? what about when there's a web ui to something, we used to bundle mobile and web into the term 'client app'. On 11/27/2017 11:03 AM, Jason Madigan wrote: > Deep thoughts this early in the week. App is quite a loaded term > alright, particularly in an OpenShift context, so I think Mobile > Client may be a clearer distinction. > > Looping in our wordsmith Paul who may have other ideas. > > On Mon, Nov 27, 2017 at 9:44 AM, Craig Brookes > wrote: > > Was thinking about terminology . We have been using the term > mobile app, but I wonder would it be clearer to use the term > mobile client instead. > The main reason for this is that app can mean a server side > component (in OpenShift there is the new-app command for example). > I think it would make a clearer distinction. Another example is > around the word build. When you do an app build in OpenShift it > normally produces a docker image and a running server / app. I > think using the the term mobile client build makes it clearer what > is happening. > > Just a thought for a Monday morning. > > -- > Craig Brookes > RHMAP > @maleck13 Github > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > > > > > -- > Jason Madigan > Engineering Manager, Red Hat Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: From lfitzger at redhat.com Mon Nov 27 12:35:50 2017 From: lfitzger at redhat.com (Laura Fitzgerald) Date: Mon, 27 Nov 2017 12:35:50 +0000 Subject: [feedhenry-dev] [aerogear-dev] Upstream Community Documentation In-Reply-To: References: <7da1aebd-2cdc-104a-a694-b9720d30647c@redhat.com> Message-ID: +1 on merging. From my experience having multiple locations where we are documenting the same project has created some unnecessary difficulties in terms of maintaining/managing documentation. Also Paul and John raised some valid points here in terms of building community/engagement in use of the product. It's never a fun experience when the documentation on a project is not good and it doesn't give a good impression to start. On Mon, Nov 27, 2017 at 12:17 PM, Wojciech Trocki wrote: > > ---------- Forwarded message ---------- > From: Wei Li > Date: Thu, Nov 23, 2017 at 2:46 PM > Subject: Re: [feedhenry-dev] [aerogear-dev] Upstream Community > Documentation > To: John Frizelle > Cc: AeroGear Developer Mailing List , > Matthias Wessendorf , feedhenry-dev at redhat.com > > > +1. Maintaining 2 communities with similar objectives are just too > confusing to a lot of people. I would like to see them merged as well. > > On Thu, Nov 23, 2017 at 1:23 PM, John Frizelle > wrote: > >> Hi All, >> >> I would like to get people's thoughts on the cost / benefit of continuing >> to maintain both the feedhenry and aerogear communities (mailing lists, IRC >> channels, web sites etc...). There seems to be a lot of cross over between >> the two (the are both mobile focused communities backed primarily by Red >> Hat) and I struggle to see what benefit we, or our community members, get >> from having our work spread across these two communities... >> >> From my perspective, I would rather see one healthy, vibrant community >> that we can all get behind instead of the current fractured status where it >> is unclear what lives where and why. >> >> Just my 2 cents... >> >> Cheers, >> John. >> >> >> -- >> John Frizelle >> Chief Architect, Red Hat Mobile >> Consulting Engineer >> >> mobile: *+353 87 290 1644 * >> twitter:* @johnfriz* >> skype: *john_frizelle* >> mail: *jfrizell at redhat.com * >> >> >> >> >> On 23 November 2017 at 13:09, Ali Ok wrote: >> >>> Hello, >>> >>> FYI, once I started this epic to improve and clean up AeroGear.org >>> website: https://issues.jboss.org/browse/AEROGEAR-1760 >>> >>> If we would like to do it, we need to find out a group that takes >>> ownership of the clean up. AeroGear people are now more spread than before. >>> >>> Cheers >>> >>> On Thu, Nov 23, 2017 at 9:13 AM, Matthias Wessendorf >>> wrote: >>> >>>> Hi Paul, >>>> >>>> lot's of content on the AeroGear website is out of date, due to lack of >>>> work in the past two years (see the planing page). >>>> >>>> Note: the sync was a prototype, for real-time sync; based on different >>>> algorithms and papers in that area, but never went really anywere... >>>> I guess it's dead now. >>>> >>>> Over the past two years we did work a bit on the AeroGear Push server, >>>> and their libraries (e.g. mobile client-side lib and server-side >>>> integrations for node/java). >>>> >>>> Regarding Digger - it's a standalone project, under the aerogear realm >>>> - like push. Both bits can be used completely independent. >>>> >>>> >>>> I think some content (e.g. sync) needs to be removed (while we can >>>> still keep the repos), but we should be perhaps focusing on AeroGear UPS >>>> and digger, for community offerings. >>>> >>>> ag.org/push (like is) >>>> ag.org/digger (with backgrounds motivations, Laura's videos etc) >>>> >>>> >>>> Regarding feedhenry / mcp , just one comment: it does integrate w/ AG >>>> features, such as push or digger, and will IMO offer the integration parts >>>> (e.g. APBs etc) >>>> >>>> >>>> -Matthias >>>> >>>> >>>> On Wed, Nov 22, 2017 at 2:59 PM, Paul Wright >>>> wrote: >>>> >>>>> Hi AeroGear, FeedHenry >>>>> >>>>> As part of a review of Digger (Build Farm) docs, I created a PR >>>>> 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/) >>>>> >>>>> 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 over to >>>>> digger doc on 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 >>>>> >>>>> _______________________________________________ >>>>> 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/ >>>> twitter: http://twitter.com/mwessendorf >>>> >>>> _______________________________________________ >>>> feedhenry-dev mailing list >>>> feedhenry-dev at redhat.com >>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>> >>>> >>> >>> _______________________________________________ >>> feedhenry-dev mailing list >>> feedhenry-dev at redhat.com >>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>> >>> >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > > -- > > WEI LI > > SENIOR SOFTWARE ENGINEER > > Red Hat Mobile > > weil at redhat.com M: +353862393272 > > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > > > > -- > > WOJCIECH TROCKI > > Red Hat Mobile > > IM: wtrocki > > -- LAURA FITZGERALD Red Hat Mobile Communications House, Cork Road Waterford City, Ireland X91NY33 lfitzger at redhat.com IM: lfitzgerald -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 11472 bytes Desc: not available URL: From cbrookes at redhat.com Wed Nov 29 09:38:04 2017 From: cbrookes at redhat.com (Craig Brookes) Date: Wed, 29 Nov 2017 09:38:04 +0000 Subject: [feedhenry-dev] mobile client or mobile app In-Reply-To: References: Message-ID: Spoke with Paul offline. And he thought we were referring to mobile app through out our docs. So to clarify I meant with the context of the mcp UI and CLI. On Mon, Nov 27, 2017 at 11:49 AM, Paul Wright wrote: > It seems to me that to tackle the mobile market, we should embrace the > lingua franca, and the one word that unites mobile,cell phone, smartphone, > handys, etc is 'App' > > Paul > my original draft reply: > > Mondays... > > Let's fix everything > > I'm not against this change, but would like to throw in a note of caution: > > 1. I don't think OpenShift are really pushing the term apps. Sure, there's > a command, and even some doc references (https://access.redhat.com/ > documentation/en-us/openshift_enterprise/3.2/html/installation_and_ > configuration/install-config-imagestreams-templates# > creating-instantapp-templates), but would like to check with them before > assuming that's deliberate. In my mind, their term of choice is > Application, a bit more of an enterprisey term. > > 2. Does "Mobile Clients" solve a problem? we already have a generation of > ppl saying "there's an app for that", do we want to embrace that or swim > upstream? what about when there's a web ui to something, we used to bundle > mobile and web into the term 'client app'. > > > > > > On 11/27/2017 11:03 AM, Jason Madigan wrote: > > Deep thoughts this early in the week. App is quite a loaded term alright, > particularly in an OpenShift context, so I think Mobile Client may be a > clearer distinction. > > Looping in our wordsmith Paul who may have other ideas. > > On Mon, Nov 27, 2017 at 9:44 AM, Craig Brookes > wrote: > >> Was thinking about terminology . We have been using the term mobile app, >> but I wonder would it be clearer to use the term mobile client instead. >> The main reason for this is that app can mean a server side component (in >> OpenShift there is the new-app command for example). I think it would make >> a clearer distinction. Another example is around the word build. When you >> do an app build in OpenShift it normally produces a docker image and a >> running server / app. I think using the the term mobile client build makes >> it clearer what is happening. >> >> Just a thought for a Monday morning. >> >> -- >> Craig Brookes >> RHMAP >> @maleck13 Github >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > > -- > Jason Madigan > Engineering Manager, Red Hat Mobile > > > -- Craig Brookes RHMAP @maleck13 Github -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwright at redhat.com Wed Nov 29 09:42:01 2017 From: pwright at redhat.com (Paul Wright) Date: Wed, 29 Nov 2017 09:42:01 +0000 Subject: [feedhenry-dev] mobile client or mobile app In-Reply-To: References: Message-ID: and that conversation makes me think we need to be more descriptive, eg Mobile App Resource Client (MARC) Paul On 11/29/2017 09:38 AM, Craig Brookes wrote: > Spoke with Paul offline. And he thought we were referring to mobile > app through out our docs. So to clarify I meant with the context of > the mcp UI and CLI. > > On Mon, Nov 27, 2017 at 11:49 AM, Paul Wright > wrote: > > It seems to me that to tackle the mobile market, we should embrace > the lingua franca, and the one word that unites mobile,cell phone, > smartphone, handys, etc is 'App' > > Paul > > my original draft reply: > > Mondays... > > Let's fix everything > > I'm not against this change, but would like to throw in a note of > caution: > > 1. I don't think OpenShift are really pushing the term apps. Sure, > there's a command, and even some doc references > (https://access.redhat.com/documentation/en-us/openshift_enterprise/3.2/html/installation_and_configuration/install-config-imagestreams-templates#creating-instantapp-templates > ), > but would like to check with them before assuming that's > deliberate. In my mind, their term of choice is Application, a bit > more of an enterprisey term. > > 2. Does "Mobile Clients" solve a problem? we already have a > generation of ppl saying "there's an app for that", do we want to > embrace that or swim upstream? what about when there's a web ui to > something, we used to bundle mobile and web into the term 'client > app'. > > > > > > On 11/27/2017 11:03 AM, Jason Madigan wrote: >> Deep thoughts this early in the week. App is quite a loaded term >> alright, particularly in an OpenShift context, so I think Mobile >> Client may be a clearer distinction. >> >> Looping in our wordsmith Paul who may have other ideas. >> >> On Mon, Nov 27, 2017 at 9:44 AM, Craig Brookes >> > wrote: >> >> Was thinking about terminology . We have been using the term >> mobile app, but I wonder would it be clearer to use the term >> mobile client instead. >> The main reason for this is that app can mean a server side >> component (in OpenShift there is the new-app command for >> example). I think it would make a clearer distinction. >> Another example is around the word build. When you do an app >> build in OpenShift it normally produces a docker image and a >> running server / app. I think using the the term mobile >> client build makes it clearer what is happening. >> >> Just a thought for a Monday morning. >> >> -- >> Craig Brookes >> RHMAP >> @maleck13 Github >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> >> >> >> >> -- >> Jason Madigan >> Engineering Manager, Red Hat Mobile > > > > > -- > Craig Brookes > RHMAP > @maleck13 Github -------------- next part -------------- An HTML attachment was scrubbed... URL: From wtrocki at redhat.com Wed Nov 29 11:16:03 2017 From: wtrocki at redhat.com (Wojciech Trocki) Date: Wed, 29 Nov 2017 11:16:03 +0000 Subject: [feedhenry-dev] Github organization personal thoughts Message-ID: Feedhenry organization has ~200 repositories at the moment from different projects, templates and samples with MCP projects along with them. IMHO it will be easier to promote, organize and collaborate on the organization that will have only MCP related repositories like service templates. I might be missing a lots of details so feel free to kill this idea. In some of the cases we cannot avoid linking do other organizations (like digger), but I think it's nice to clean things up and split some initiatives in order to not confuse potential developers and users. It's essential to separate some initiatives and avoid people to get confused between old feedhenry projects and MCP. We doing great job by flagging this at the moment like here: https://github.com/feedhenry/fh-sync-server , but separate organization will be even cleaner approach where we can collect documentation, website and all the resources we need. It will be easier to do it now with some limited number of MCP repositories and developers working on it. WDYT? Regards -- WOJCIECH TROCKI Red Hat Mobile IM: wtrocki -------------- next part -------------- An HTML attachment was scrubbed... URL: From supittma at redhat.com Wed Nov 29 14:14:56 2017 From: supittma at redhat.com (Summers Pittman) Date: Wed, 29 Nov 2017 09:14:56 -0500 Subject: [feedhenry-dev] Upstream Community Documentation In-Reply-To: References: <7da1aebd-2cdc-104a-a694-b9720d30647c@redhat.com> Message-ID: On Wed, Nov 22, 2017 at 10:02 AM, Wojciech Trocki wrote: > Thanks for raising that question - I think it's really important to talk > about it. > I think we had the similar conversation 6 months ago when kickstarting > RainCatcher docs. > > Personally I think is essential for every project to have his own landing > sub page (with documentation,demo video etc.) that can be accessed easily > from feedhenry, aerogear main web pages. > In RainCatcher we went even further and created separate web page (that is > linked in feedhenry.org). > This works pretty well as documentation, getting started etc. is exposed > directly on the main page. > > I think that feedhenry.org has really good layout itself when listing all > projects. We could just provide less information so people looking for > something specific will not need to scroll too much. > Spring (any many other aggregating communities) do the same. For example: > https://spring.io/docs/reference > > We can apply similar list to aerogear website - however I'm not aware of > the impact or challenges in that area) > > On Wed, Nov 22, 2017 at 1:59 PM, Paul Wright wrote: > >> Hi AeroGear, FeedHenry >> >> As part of a review of Digger (Build Farm) docs, I created a PR >> 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/) >> >> 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 over to >> digger doc on 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 >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > Bumping this a bit. Over the summer the community team put together a backlog of items to update the feedhenry sdk page, automate some documentation and blogging aggregation, and begin to plan on how we would keep docs, demos, etc up to date from a community perspective. https://issues.jboss.org/secure/PortfolioPlanView.jspa?id=28&sid=30#backlog (if that isn't working let me know). While we didn't look at the aerogear community as we were focusing on "feedhenry" it may be a good opportunity to spin the team back up and bring Aerogear into its fold. This will mean either maintaining two websites and brands or combining them into a single landing page for docs and community to feed into the mobile upstream. MCP plays an important role in this because it is pulling together a lot of the strings from AeroGear, Wildfly, node.js, jboss, feedhenry, etc into a single "launchpad". > > -- > > WOJCIECH TROCKI > > Red Hat Mobile > > IM: wtrocki > > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aliok at redhat.com Wed Nov 29 14:21:44 2017 From: aliok at redhat.com (Ali Ok) Date: Wed, 29 Nov 2017 17:21:44 +0300 Subject: [feedhenry-dev] Upstream Community Documentation In-Reply-To: References: <7da1aebd-2cdc-104a-a694-b9720d30647c@redhat.com> Message-ID: Hello, We were talking about this in our team and wanted to give some feedback as we (RHMAP core team) are the ones who perhaps interact with AeroGear and FeedHenry communities/organizations more often than other people. Wojciech, Paolo and their team has a spent a very good time on thinking about how to improve FeedHenry community and build/expand RainCatcher community. I think moving things to FeedHenry and calling UPS "FH AG Push" sounds good. I won't go and do a full assessment of both communities/organizations but if we're doing this, we should definitely move these things from AeroGear to FeedHenry side and make sure they don't break in the future at least the current AeroGear things where things are working nicely: * Stable processes (release, JIRA workflow, etc.) * Open source first mentality (100% community releases, etc.) * Somewhat active non Red Hat community members One of the problems that I am having right now is finding people that should be the owners for AeroGear things, such as the website, aerogear.org. If we are going to do this merger, we should clarify the owners of components. I would like to say that we, as RHMAP core/onprem team, are interested in owning the transition work (not any new components explicitly, but the transition work!) from AeroGear to FeedHenry collaborating with community leaders and members from the both side as well as MCP people. RHMAP docs team is another group of people that interact with AG and FH quite often and they told me they're here for help whatever direction we go. Cheers, Ali On Wed, Nov 29, 2017 at 5:14 PM, Summers Pittman wrote: > > > On Wed, Nov 22, 2017 at 10:02 AM, Wojciech Trocki > wrote: > >> Thanks for raising that question - I think it's really important to talk >> about it. >> I think we had the similar conversation 6 months ago when kickstarting >> RainCatcher docs. >> >> Personally I think is essential for every project to have his own landing >> sub page (with documentation,demo video etc.) that can be accessed easily >> from feedhenry, aerogear main web pages. >> In RainCatcher we went even further and created separate web page (that >> is linked in feedhenry.org). >> This works pretty well as documentation, getting started etc. is exposed >> directly on the main page. >> >> I think that feedhenry.org has really good layout itself when listing >> all projects. We could just provide less information so people looking for >> something specific will not need to scroll too much. >> Spring (any many other aggregating communities) do the same. For example: >> https://spring.io/docs/reference >> >> We can apply similar list to aerogear website - however I'm not aware of >> the impact or challenges in that area) >> >> On Wed, Nov 22, 2017 at 1:59 PM, Paul Wright wrote: >> >>> Hi AeroGear, FeedHenry >>> >>> As part of a review of Digger (Build Farm) docs, I created a PR >>> 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/) >>> >>> 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 over to >>> digger doc on 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 >>> >>> _______________________________________________ >>> feedhenry-dev mailing list >>> feedhenry-dev at redhat.com >>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>> >>> >> > Bumping this a bit. > > Over the summer the community team put together a backlog of items to > update the feedhenry sdk page, automate some documentation and blogging > aggregation, and begin to plan on how we would keep docs, demos, etc up to > date from a community perspective. > > https://issues.jboss.org/secure/PortfolioPlanView.jspa? > id=28&sid=30#backlog (if that isn't working let me know). > > While we didn't look at the aerogear community as we were focusing on > "feedhenry" it may be a good opportunity to spin the team back up and bring > Aerogear into its fold. This will mean either maintaining two websites and > brands or combining them into a single landing page for docs and community > to feed into the mobile upstream. > > MCP plays an important role in this because it is pulling together a lot > of the strings from AeroGear, Wildfly, node.js, jboss, feedhenry, etc into > a single "launchpad". > > > > >> >> -- >> >> WOJCIECH TROCKI >> >> Red Hat Mobile >> >> IM: wtrocki >> >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwright at redhat.com Wed Nov 29 15:08:11 2017 From: pwright at redhat.com (Paul Wright) Date: Wed, 29 Nov 2017 15:08:11 +0000 Subject: [feedhenry-dev] Upstream Community Documentation In-Reply-To: References: <7da1aebd-2cdc-104a-a694-b9720d30647c@redhat.com> Message-ID: <856979e0-cfcd-3265-3043-e1e52e93abad@redhat.com> Inline On 11/29/2017 02:14 PM, Summers Pittman wrote: > > > On Wed, Nov 22, 2017 at 10:02 AM, Wojciech Trocki > wrote: > > Thanks for raising that question - I think it's really important > to talk about it. > I think we had the similar conversation 6 months ago when > kickstarting RainCatcher docs. > > Personally I think is essential for every project to have his own > landing sub page (with documentation,demo video etc.) that can be > accessed easily from feedhenry, aerogear main web pages. > Project?? sync, push, raincatcher, digger - after that I'm not sure, is each sdk a project or not? Do the users care what we consider to be a project? I'm thinking for mobile.next, the end user might start by considering MCP, but then later think about sync, then later think about the ios sdk. I thinkthis needs further exploration, but Raincatcher is a good example of things working well. > In RainCatcher we went even further and created separate web page > (that is linked in feedhenry.org ). > This works pretty well as documentation, getting started etc. is > exposed directly on the main page. > Yea, I like that there's a feature associated with a set of repos, and one doc repo to tie the functionality together. We could set the homepage for all the associated repos to the published version of the doc repo to tie them together. > > > I think that feedhenry.org has really good > layout itself when listing all projects. We could just provide > less information so people looking for something specific will not > need to scroll too much. > Spring (any many other aggregating communities) do the same. For > example: https://spring.io/docs/reference > > > We can apply similar list to aerogear website - however I'm not > aware of the impact or challenges in that area) > Here's the big one: Would it help to redirect aerogear.org to feedhenry.org and host everything there? I think that's been hinted at, but not asked explicitly up to now. For me the advantages are: * one website is easier than two (process, tooling, communications, etc) * addition is easier than subtraction, easier to add digger/push to feedhenry.org, than to extract dead material from aerogear * not having to deal with jekyll/plugins ;) Paul > > On Wed, Nov 22, 2017 at 1:59 PM, Paul Wright > wrote: > > Hi AeroGear, FeedHenry > > As part of a review of Digger (Build Farm) docs,? I created a > PR 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/ > ) > > 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 > over to digger doc on 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 > > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > > > > Bumping this a bit. > > Over the summer the community team put together a backlog of items to > update the feedhenry sdk page, automate some documentation and > blogging aggregation, and begin to plan on how we would keep docs, > demos, etc up to date from a community perspective. > > https://issues.jboss.org/secure/PortfolioPlanView.jspa?id=28&sid=30#backlog > (if that isn't working let me know). > > While we didn't look at the aerogear community as we were focusing on > "feedhenry" it may be a good opportunity to spin the team back up and > bring Aerogear into its fold.? This will mean either maintaining two > websites and brands or combining them into a single landing page for > docs and community to feed into the mobile upstream. > > MCP plays an important role in this because it is pulling together a > lot of the strings from AeroGear, Wildfly, node.js, jboss, feedhenry, > etc into a single "launchpad". > > > > > > -- > > WOJCIECH TROCKI > > Red Hat Mobile > > IM: wtrocki > > > > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gryan at redhat.com Wed Nov 29 15:25:11 2017 From: gryan at redhat.com (Gerard Ryan) Date: Wed, 29 Nov 2017 15:25:11 +0000 Subject: [feedhenry-dev] Upstream Community Documentation In-Reply-To: (Ali Ok's message of "Wed, 29 Nov 2017 17:21:44 +0300") References: <7da1aebd-2cdc-104a-a694-b9720d30647c@redhat.com> Message-ID: <87fu8xf6p4.fsf@w541.grdryn> Ali Ok writes: > I won't go and do a full assessment of both communities/organizations but > if we're doing this, we should definitely move these things from AeroGear > to FeedHenry side and make sure they don't break in the future at least the > current AeroGear things where things are working nicely: > * Stable processes (release, JIRA workflow, etc.) > * Open source first mentality (100% community releases, etc.) > * Somewhat active non Red Hat community members So at least the last point there (and maybe the second point also?) would in my opinion be reasons to move everything *to* the AeroGear community, rather than *from* it to the FeedHenry community. I don't think it makes a huge difference either way for those of us who work for Red Hat, since we're involved in / aware of both communities as they are; but it could be potentially disruptive to the more established AeroGear open source community. Since I'm not really involved in that community, I'd like to hear what matzew or other long-time members of that community think. Maybe it's no big deal, but I think it's worth thinking about! From davmarti at redhat.com Thu Nov 30 09:49:11 2017 From: davmarti at redhat.com (David Martin) Date: Thu, 30 Nov 2017 09:49:11 +0000 Subject: [feedhenry-dev] Upstream Community Documentation In-Reply-To: <87fu8xf6p4.fsf@w541.grdryn> References: <7da1aebd-2cdc-104a-a694-b9720d30647c@redhat.com> <87fu8xf6p4.fsf@w541.grdryn> Message-ID: TLDR; Let's do all Mobile.next()/5.x development as the Aerogear community I would see the FeedHenry community being strongly linked to RHMAP (Red Hat Mobile App Platform). There are large parts of that community that are tied into having access to a an RHMAP cluster e.g. SDKs & templates (There are some exceptions, which I'll call out later). The RHMAP MBaaS is available on github, but it is not very useful without an RHMAP Core. The RHMAP Core is only available via a RH subscription. I would NOT see the Aerogear community as being strongly tied to RHMAP. The 2 main Aerogear projects are Unified Push Server & Digger (Build Farm). Both of these are standalone services that have been developed in an open manner from their inception. See Ger's points for more about what the Aerogear community is doing well. Building the Aerogear community as the upstream for mobile in Red Hat would draw a line between what's RHMAP 3.x/4.x and the future (5.x). Steps from here: * move the fh-sync-server project into the Aerogear community as the 'Aerogear Data Sync Service' * move mobile.next()/5.x collateral (that's still relevant after the POC) to the Aerogear community * progress development of mobile.next()/5.x as the Aerogear community * update https://aerogear.org ** update UPS documentation (it reference OpenShift 2! There's been great work done on updating UPS for decoupling keycloak & running on OpenShift 3 via APB) ** add Aerogear Data Sync Service documentation ** add Aerogear Digger/Build Farm documentation ** add Aerogear mobile.next() (name TBD) documentation I'm sure there's things I've missed, and would welcome other peoples thoughts on this idea. On 29 November 2017 at 15:25, Gerard Ryan wrote: > Ali Ok writes: > > > I won't go and do a full assessment of both communities/organizations but > > if we're doing this, we should definitely move these things from AeroGear > > to FeedHenry side and make sure they don't break in the future at least > the > > current AeroGear things where things are working nicely: > > * Stable processes (release, JIRA workflow, etc.) > > * Open source first mentality (100% community releases, etc.) > > * Somewhat active non Red Hat community members > > So at least the last point there (and maybe the second point also?) > would in my opinion be reasons to move everything *to* the AeroGear > community, rather than *from* it to the FeedHenry community. > > I don't think it makes a huge difference either way for those of us who > work for Red Hat, since we're involved in / aware of both communities as > they are; but it could be potentially disruptive to the more established > AeroGear open source community. > > Since I'm not really involved in that community, I'd like to hear what > matzew or other long-time members of that community think. Maybe it's no > big deal, but I think it's worth thinking about! > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From davmarti at redhat.com Thu Nov 30 10:11:00 2017 From: davmarti at redhat.com (David Martin) Date: Thu, 30 Nov 2017 10:11:00 +0000 Subject: [feedhenry-dev] mobile client or mobile app In-Reply-To: References: Message-ID: The term 'Resource' may not suit as it has a meaning in the Kubernetes world. Any object that kubernetes exposes an API for is a resource e.g. Secrets, Pods, Deployments are all resources. In UPS, there's the idea of a 'Push Application', defined here [1] "PushApplication A logical construct that represents an overall mobile application" I don't see any problem with giving it a name like 'Mobile Client' and calling it out in terminology in a similar manner "MobileClient A logical construct that represents an overall mobile application" [1] https://aerogear.org/docs/unifiedpush/ups_userguide/index/#_useful_terminology On 29 November 2017 at 09:42, Paul Wright wrote: > and that conversation makes me think we need to be more descriptive, eg > > Mobile App Resource Client (MARC) > > Paul > > On 11/29/2017 09:38 AM, Craig Brookes wrote: > > Spoke with Paul offline. And he thought we were referring to mobile app > through out our docs. So to clarify I meant with the context of the mcp UI > and CLI. > > On Mon, Nov 27, 2017 at 11:49 AM, Paul Wright wrote: > >> It seems to me that to tackle the mobile market, we should embrace the >> lingua franca, and the one word that unites mobile,cell phone, smartphone, >> handys, etc is 'App' >> >> Paul >> my original draft reply: >> >> Mondays... >> >> Let's fix everything >> >> I'm not against this change, but would like to throw in a note of caution: >> >> 1. I don't think OpenShift are really pushing the term apps. Sure, >> there's a command, and even some doc references ( >> https://access.redhat.com/documentation/en-us/openshift_ent >> erprise/3.2/html/installation_and_configuration/install- >> config-imagestreams-templates#creating-instantapp-templates), but would >> like to check with them before assuming that's deliberate. In my mind, >> their term of choice is Application, a bit more of an enterprisey term. >> >> 2. Does "Mobile Clients" solve a problem? we already have a generation of >> ppl saying "there's an app for that", do we want to embrace that or swim >> upstream? what about when there's a web ui to something, we used to bundle >> mobile and web into the term 'client app'. >> >> >> >> >> >> On 11/27/2017 11:03 AM, Jason Madigan wrote: >> >> Deep thoughts this early in the week. App is quite a loaded term alright, >> particularly in an OpenShift context, so I think Mobile Client may be a >> clearer distinction. >> >> Looping in our wordsmith Paul who may have other ideas. >> >> On Mon, Nov 27, 2017 at 9:44 AM, Craig Brookes >> wrote: >> >>> Was thinking about terminology . We have been using the term mobile app, >>> but I wonder would it be clearer to use the term mobile client instead. >>> The main reason for this is that app can mean a server side component >>> (in OpenShift there is the new-app command for example). I think it would >>> make a clearer distinction. Another example is around the word build. When >>> you do an app build in OpenShift it normally produces a docker image and a >>> running server / app. I think using the the term mobile client build makes >>> it clearer what is happening. >>> >>> Just a thought for a Monday morning. >>> >>> -- >>> Craig Brookes >>> RHMAP >>> @maleck13 Github >>> >>> _______________________________________________ >>> feedhenry-dev mailing list >>> feedhenry-dev at redhat.com >>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>> >>> >> >> >> -- >> Jason Madigan >> Engineering Manager, Red Hat Mobile >> >> >> > > > -- > Craig Brookes > RHMAP > @maleck13 Github > > > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Thu Nov 30 10:26:49 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Thu, 30 Nov 2017 11:26:49 +0100 Subject: [feedhenry-dev] mobile client or mobile app In-Reply-To: References: Message-ID: +1 on something like "logical construct / logical representation" - and right UPS has also had some naming struggles :) On Thu, Nov 30, 2017 at 11:11 AM, David Martin wrote: > The term 'Resource' may not suit as it has a meaning in the Kubernetes > world. > Any object that kubernetes exposes an API for is a resource e.g. Secrets, > Pods, Deployments are all resources. > > In UPS, there's the idea of a 'Push Application', defined here [1] > "PushApplication > A logical construct that represents an overall mobile application" > > I don't see any problem with giving it a name like 'Mobile Client' and > calling it out in terminology in a similar manner > "MobileClient > A logical construct that represents an overall mobile application" > > [1] https://aerogear.org/docs/unifiedpush/ups_userguide/ > index/#_useful_terminology > > On 29 November 2017 at 09:42, Paul Wright wrote: > >> and that conversation makes me think we need to be more descriptive, eg >> >> Mobile App Resource Client (MARC) >> >> Paul >> >> On 11/29/2017 09:38 AM, Craig Brookes wrote: >> >> Spoke with Paul offline. And he thought we were referring to mobile app >> through out our docs. So to clarify I meant with the context of the mcp UI >> and CLI. >> >> On Mon, Nov 27, 2017 at 11:49 AM, Paul Wright wrote: >> >>> It seems to me that to tackle the mobile market, we should embrace the >>> lingua franca, and the one word that unites mobile,cell phone, smartphone, >>> handys, etc is 'App' >>> >>> Paul >>> my original draft reply: >>> >>> Mondays... >>> >>> Let's fix everything >>> >>> I'm not against this change, but would like to throw in a note of >>> caution: >>> >>> 1. I don't think OpenShift are really pushing the term apps. Sure, >>> there's a command, and even some doc references ( >>> https://access.redhat.com/documentation/en-us/openshift_ent >>> erprise/3.2/html/installation_and_configuration/install-conf >>> ig-imagestreams-templates#creating-instantapp-templates), but would >>> like to check with them before assuming that's deliberate. In my mind, >>> their term of choice is Application, a bit more of an enterprisey term. >>> >>> 2. Does "Mobile Clients" solve a problem? we already have a generation >>> of ppl saying "there's an app for that", do we want to embrace that or swim >>> upstream? what about when there's a web ui to something, we used to bundle >>> mobile and web into the term 'client app'. >>> >>> >>> >>> >>> >>> On 11/27/2017 11:03 AM, Jason Madigan wrote: >>> >>> Deep thoughts this early in the week. App is quite a loaded term >>> alright, particularly in an OpenShift context, so I think Mobile Client may >>> be a clearer distinction. >>> >>> Looping in our wordsmith Paul who may have other ideas. >>> >>> On Mon, Nov 27, 2017 at 9:44 AM, Craig Brookes >>> wrote: >>> >>>> Was thinking about terminology . We have been using the term mobile >>>> app, but I wonder would it be clearer to use the term mobile client >>>> instead. >>>> The main reason for this is that app can mean a server side component >>>> (in OpenShift there is the new-app command for example). I think it would >>>> make a clearer distinction. Another example is around the word build. When >>>> you do an app build in OpenShift it normally produces a docker image and a >>>> running server / app. I think using the the term mobile client build makes >>>> it clearer what is happening. >>>> >>>> Just a thought for a Monday morning. >>>> >>>> -- >>>> Craig Brookes >>>> RHMAP >>>> @maleck13 Github >>>> >>>> _______________________________________________ >>>> feedhenry-dev mailing list >>>> feedhenry-dev at redhat.com >>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>> >>>> >>> >>> >>> -- >>> Jason Madigan >>> Engineering Manager, Red Hat Mobile >>> >>> >>> >> >> >> -- >> Craig Brookes >> RHMAP >> @maleck13 Github >> >> >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > > -- > David Martin > Red Hat Mobile > Twitter: @irldavem > IRC: @irldavem (feedhenry, mobile-internal) > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwright at redhat.com Thu Nov 30 11:05:31 2017 From: pwright at redhat.com (Paul Wright) Date: Thu, 30 Nov 2017 11:05:31 +0000 Subject: [feedhenry-dev] mobile client or mobile app In-Reply-To: References: Message-ID: <4cd1277c-7043-2770-4b2c-8e1df071b49e@redhat.com> last comment, then I'll stop (promise): Let's go with MobileClient, as discussed below, but take a bit more time about the definition. I think the definition for PushApplication is great in the context of UPS, but with MCP, we're trying to explain an item that is front and center, and that the user might misunderstand, or not act as expected. Can we be more explicit and give an example? - MobileClient: A container configuration that represents the overall mobile application on OpenShift (eg MobileHR) Paul On 11/30/2017 10:26 AM, Matthias Wessendorf wrote: > +1 on something like "logical construct / logical representation"? ?- > and right UPS has also had some naming struggles :) > > On Thu, Nov 30, 2017 at 11:11 AM, David Martin > wrote: > > The term 'Resource' may not suit as it has a meaning in the > Kubernetes world. > Any object that kubernetes exposes an API for is a resource e.g. > Secrets, Pods, Deployments are all resources. > > In UPS, there's the idea of a 'Push Application', defined here [1] > "PushApplication > A logical construct that represents an overall mobile application" > > I don't see any problem with giving it a name like 'Mobile Client' > and calling it out in terminology in a similar manner > "MobileClient > A logical construct that represents an overall mobile application" > > [1] > https://aerogear.org/docs/unifiedpush/ups_userguide/index/#_useful_terminology > > > On 29 November 2017 at 09:42, Paul Wright > wrote: > > and that conversation makes me think we need to be more > descriptive, eg > > Mobile App Resource Client (MARC) > > Paul > > > On 11/29/2017 09:38 AM, Craig Brookes wrote: >> Spoke with Paul offline. And he thought we were referring to >> mobile app through out our docs. So to clarify I meant with >> the context of the mcp UI and CLI. >> >> On Mon, Nov 27, 2017 at 11:49 AM, Paul Wright >> > wrote: >> >> It seems to me that to tackle the mobile market, we >> should embrace the lingua franca, and the one word that >> unites mobile,cell phone, smartphone, handys, etc is 'App' >> >> Paul >> >> my original draft reply: >> >> Mondays... >> >> Let's fix everything >> >> I'm not against this change, but would like to throw in a >> note of caution: >> >> 1. I don't think OpenShift are really pushing the term >> apps. Sure, there's a command, and even some doc >> references >> (https://access.redhat.com/documentation/en-us/openshift_enterprise/3.2/html/installation_and_configuration/install-config-imagestreams-templates#creating-instantapp-templates >> ), >> but would like to check with them before assuming that's >> deliberate. In my mind, their term of choice is >> Application, a bit more of an enterprisey term. >> >> 2. Does "Mobile Clients" solve a problem? we already have >> a generation of ppl saying "there's an app for that", do >> we want to embrace that or swim upstream? what about when >> there's a web ui to something, we used to bundle mobile >> and web into the term 'client app'. >> >> >> >> >> >> On 11/27/2017 11:03 AM, Jason Madigan wrote: >>> Deep thoughts this early in the week. App is quite a >>> loaded term alright, particularly in an OpenShift >>> context, so I think Mobile Client may be a clearer >>> distinction. >>> >>> Looping in our wordsmith Paul who may have other ideas. >>> >>> On Mon, Nov 27, 2017 at 9:44 AM, Craig Brookes >>> > wrote: >>> >>> Was thinking about terminology . We have been using >>> the term mobile app, but I wonder would it be >>> clearer to use the term mobile client instead. >>> The main reason for this is that app can mean a >>> server side component (in OpenShift there is the >>> new-app command for example). I think it would make >>> a clearer distinction. Another example is around the >>> word build. When you do an app build in OpenShift it >>> normally produces a docker image and a running >>> server / app. I think using the the term mobile >>> client build makes it clearer what is happening. >>> >>> Just a thought for a Monday morning. >>> >>> -- >>> Craig Brookes >>> RHMAP >>> @maleck13 Github >>> >>> _______________________________________________ >>> feedhenry-dev mailing list >>> feedhenry-dev at redhat.com >>> >>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>> >>> >>> >>> >>> >>> -- >>> Jason Madigan >>> Engineering Manager, Red Hat Mobile >> >> >> >> >> -- >> Craig Brookes >> RHMAP >> @maleck13 Github > > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > > > > > -- > David Martin > Red Hat Mobile > Twitter: @irldavem > IRC: @irldavem (feedhenry, mobile-internal) > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > > > > > -- > Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From weil at redhat.com Thu Nov 30 11:36:15 2017 From: weil at redhat.com (Wei Li) Date: Thu, 30 Nov 2017 11:36:15 +0000 Subject: [feedhenry-dev] Upstream Community Documentation In-Reply-To: References: <7da1aebd-2cdc-104a-a694-b9720d30647c@redhat.com> <87fu8xf6p4.fsf@w541.grdryn> Message-ID: +1 on Dave's idea to move mobile.next work to the AG community. I would also add that: * Rethink/Rebrand the objective of the AG project. I think it should be something that is close to what we have for mobile.next * In the meantime, make it clear that the FH community will still be maintained, but it will only cover for the existing RHMAP projects. Hopefully this will avoid future confusing around which community is for what purpose. It will also allow us to continue support the AG community that (I think) have more community users than FH. Thanks. On Thu, Nov 30, 2017 at 9:49 AM, David Martin wrote: > TLDR; Let's do all Mobile.next()/5.x development as the Aerogear community > > > I would see the FeedHenry community being strongly linked to RHMAP (Red > Hat Mobile App Platform). There are large parts of that community that are > tied into having access to a an RHMAP cluster e.g. SDKs & templates (There > are some exceptions, which I'll call out later). The RHMAP MBaaS is > available on github, but it is not very useful without an RHMAP Core. The > RHMAP Core is only available via a RH subscription. > > I would NOT see the Aerogear community as being strongly tied to RHMAP. > The 2 main Aerogear projects are Unified Push Server & Digger (Build Farm). > Both of these are standalone services that have been developed in an open > manner from their inception. > See Ger's points for more about what the Aerogear community is doing well. > > Building the Aerogear community as the upstream for mobile in Red Hat > would draw a line between what's RHMAP 3.x/4.x and the future (5.x). > > Steps from here: > * move the fh-sync-server project into the Aerogear community as the > 'Aerogear Data Sync Service' > * move mobile.next()/5.x collateral (that's still relevant after the POC) > to the Aerogear community > * progress development of mobile.next()/5.x as the Aerogear community > * update https://aerogear.org > ** update UPS documentation (it reference OpenShift 2! There's been great > work done on updating UPS for decoupling keycloak & running on OpenShift 3 > via APB) > ** add Aerogear Data Sync Service documentation > ** add Aerogear Digger/Build Farm documentation > ** add Aerogear mobile.next() (name TBD) documentation > > > I'm sure there's things I've missed, and would welcome other peoples > thoughts on this idea. > > On 29 November 2017 at 15:25, Gerard Ryan wrote: > >> Ali Ok writes: >> >> > I won't go and do a full assessment of both communities/organizations >> but >> > if we're doing this, we should definitely move these things from >> AeroGear >> > to FeedHenry side and make sure they don't break in the future at least >> the >> > current AeroGear things where things are working nicely: >> > * Stable processes (release, JIRA workflow, etc.) >> > * Open source first mentality (100% community releases, etc.) >> > * Somewhat active non Red Hat community members >> >> So at least the last point there (and maybe the second point also?) >> would in my opinion be reasons to move everything *to* the AeroGear >> community, rather than *from* it to the FeedHenry community. >> >> I don't think it makes a huge difference either way for those of us who >> work for Red Hat, since we're involved in / aware of both communities as >> they are; but it could be potentially disruptive to the more established >> AeroGear open source community. >> >> Since I'm not really involved in that community, I'd like to hear what >> matzew or other long-time members of that community think. Maybe it's no >> big deal, but I think it's worth thinking about! >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> > > > > -- > David Martin > Red Hat Mobile > Twitter: @irldavem > IRC: @irldavem (feedhenry, mobile-internal) > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- WEI LI SENIOR SOFTWARE ENGINEER Red Hat Mobile weil at redhat.com M: +353862393272 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Thu Nov 30 11:48:09 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Thu, 30 Nov 2017 12:48:09 +0100 Subject: [feedhenry-dev] mobile client or mobile app In-Reply-To: <4cd1277c-7043-2770-4b2c-8e1df071b49e@redhat.com> References: <4cd1277c-7043-2770-4b2c-8e1df071b49e@redhat.com> Message-ID: On Thu, Nov 30, 2017 at 12:05 PM, Paul Wright wrote: > last comment, then I'll stop (promise): > > Let's go with MobileClient, as discussed below, but take a bit more time > about the definition. > > I think the definition for PushApplication is great in the context of UPS, > but with MCP, we're trying to explain an item that is front and center, and > that the user might misunderstand, or not act as expected. > > Can we be more explicit and give an example? > > - MobileClient: A container configuration that represents the overall > mobile application on OpenShift (eg MobileHR) > container ... hrm - not sure - that's also misleading... ?! > > > Paul > > On 11/30/2017 10:26 AM, Matthias Wessendorf wrote: > > +1 on something like "logical construct / logical representation" - and > right UPS has also had some naming struggles :) > > On Thu, Nov 30, 2017 at 11:11 AM, David Martin > wrote: > >> The term 'Resource' may not suit as it has a meaning in the Kubernetes >> world. >> Any object that kubernetes exposes an API for is a resource e.g. Secrets, >> Pods, Deployments are all resources. >> >> In UPS, there's the idea of a 'Push Application', defined here [1] >> "PushApplication >> A logical construct that represents an overall mobile application" >> >> I don't see any problem with giving it a name like 'Mobile Client' and >> calling it out in terminology in a similar manner >> "MobileClient >> A logical construct that represents an overall mobile application" >> >> [1] https://aerogear.org/docs/unifiedpush/ups_userguide/inde >> x/#_useful_terminology >> >> On 29 November 2017 at 09:42, Paul Wright wrote: >> >>> and that conversation makes me think we need to be more descriptive, eg >>> >>> Mobile App Resource Client (MARC) >>> >>> Paul >>> >>> On 11/29/2017 09:38 AM, Craig Brookes wrote: >>> >>> Spoke with Paul offline. And he thought we were referring to mobile app >>> through out our docs. So to clarify I meant with the context of the mcp UI >>> and CLI. >>> >>> On Mon, Nov 27, 2017 at 11:49 AM, Paul Wright >>> wrote: >>> >>>> It seems to me that to tackle the mobile market, we should embrace the >>>> lingua franca, and the one word that unites mobile,cell phone, smartphone, >>>> handys, etc is 'App' >>>> >>>> Paul >>>> my original draft reply: >>>> >>>> Mondays... >>>> >>>> Let's fix everything >>>> >>>> I'm not against this change, but would like to throw in a note of >>>> caution: >>>> >>>> 1. I don't think OpenShift are really pushing the term apps. Sure, >>>> there's a command, and even some doc references ( >>>> https://access.redhat.com/documentation/en-us/openshift_ent >>>> erprise/3.2/html/installation_and_configuration/install-conf >>>> ig-imagestreams-templates#creating-instantapp-templates), but would >>>> like to check with them before assuming that's deliberate. In my mind, >>>> their term of choice is Application, a bit more of an enterprisey term. >>>> >>>> 2. Does "Mobile Clients" solve a problem? we already have a generation >>>> of ppl saying "there's an app for that", do we want to embrace that or swim >>>> upstream? what about when there's a web ui to something, we used to bundle >>>> mobile and web into the term 'client app'. >>>> >>>> >>>> >>>> >>>> >>>> On 11/27/2017 11:03 AM, Jason Madigan wrote: >>>> >>>> Deep thoughts this early in the week. App is quite a loaded term >>>> alright, particularly in an OpenShift context, so I think Mobile Client may >>>> be a clearer distinction. >>>> >>>> Looping in our wordsmith Paul who may have other ideas. >>>> >>>> On Mon, Nov 27, 2017 at 9:44 AM, Craig Brookes >>>> wrote: >>>> >>>>> Was thinking about terminology . We have been using the term mobile >>>>> app, but I wonder would it be clearer to use the term mobile client >>>>> instead. >>>>> The main reason for this is that app can mean a server side component >>>>> (in OpenShift there is the new-app command for example). I think it would >>>>> make a clearer distinction. Another example is around the word build. When >>>>> you do an app build in OpenShift it normally produces a docker image and a >>>>> running server / app. I think using the the term mobile client build makes >>>>> it clearer what is happening. >>>>> >>>>> Just a thought for a Monday morning. >>>>> >>>>> -- >>>>> Craig Brookes >>>>> RHMAP >>>>> @maleck13 Github >>>>> >>>>> _______________________________________________ >>>>> feedhenry-dev mailing list >>>>> feedhenry-dev at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>>> >>>>> >>>> >>>> >>>> -- >>>> Jason Madigan >>>> Engineering Manager, Red Hat Mobile >>>> >>>> >>>> >>> >>> >>> -- >>> Craig Brookes >>> RHMAP >>> @maleck13 Github >>> >>> >>> >>> _______________________________________________ >>> feedhenry-dev mailing list >>> feedhenry-dev at redhat.com >>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>> >>> >> >> >> -- >> David Martin >> Red Hat Mobile >> Twitter: @irldavem >> IRC: @irldavem (feedhenry, mobile-internal) >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > > -- > Project lead AeroGear.org > > > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From wtrocki at redhat.com Thu Nov 30 12:04:31 2017 From: wtrocki at redhat.com (Wojciech Trocki) Date: Thu, 30 Nov 2017 12:04:31 +0000 Subject: [feedhenry-dev] Upstream Community Documentation In-Reply-To: References: <7da1aebd-2cdc-104a-a694-b9720d30647c@redhat.com> <87fu8xf6p4.fsf@w541.grdryn> Message-ID: > TLDR; Let's do all Mobile.next()/5.x development as the Aerogear community +1 > update https://aerogear.org IMHO it's worth also to update page layout and engine (to resolve issues mentioned by Paul) and improve user experience. On Thu, Nov 30, 2017 at 11:36 AM, Wei Li wrote: > +1 on Dave's idea to move mobile.next work to the AG community. I would > also add that: > > * Rethink/Rebrand the objective of the AG project. I think it should be > something that is close to what we have for mobile.next > * In the meantime, make it clear that the FH community will still be > maintained, but it will only cover for the existing RHMAP projects. > > Hopefully this will avoid future confusing around which community is for > what purpose. It will also allow us to continue support the AG community > that (I think) have more community users than FH. > > Thanks. > > On Thu, Nov 30, 2017 at 9:49 AM, David Martin wrote: > >> TLDR; Let's do all Mobile.next()/5.x development as the Aerogear community >> >> >> I would see the FeedHenry community being strongly linked to RHMAP (Red >> Hat Mobile App Platform). There are large parts of that community that are >> tied into having access to a an RHMAP cluster e.g. SDKs & templates (There >> are some exceptions, which I'll call out later). The RHMAP MBaaS is >> available on github, but it is not very useful without an RHMAP Core. The >> RHMAP Core is only available via a RH subscription. >> >> I would NOT see the Aerogear community as being strongly tied to RHMAP. >> The 2 main Aerogear projects are Unified Push Server & Digger (Build Farm). >> Both of these are standalone services that have been developed in an open >> manner from their inception. >> See Ger's points for more about what the Aerogear community is doing well. >> >> Building the Aerogear community as the upstream for mobile in Red Hat >> would draw a line between what's RHMAP 3.x/4.x and the future (5.x). >> >> Steps from here: >> * move the fh-sync-server project into the Aerogear community as the >> 'Aerogear Data Sync Service' >> * move mobile.next()/5.x collateral (that's still relevant after the POC) >> to the Aerogear community >> * progress development of mobile.next()/5.x as the Aerogear community >> * update https://aerogear.org >> ** update UPS documentation (it reference OpenShift 2! There's been great >> work done on updating UPS for decoupling keycloak & running on OpenShift 3 >> via APB) >> ** add Aerogear Data Sync Service documentation >> ** add Aerogear Digger/Build Farm documentation >> ** add Aerogear mobile.next() (name TBD) documentation >> >> >> I'm sure there's things I've missed, and would welcome other peoples >> thoughts on this idea. >> >> On 29 November 2017 at 15:25, Gerard Ryan wrote: >> >>> Ali Ok writes: >>> >>> > I won't go and do a full assessment of both communities/organizations >>> but >>> > if we're doing this, we should definitely move these things from >>> AeroGear >>> > to FeedHenry side and make sure they don't break in the future at >>> least the >>> > current AeroGear things where things are working nicely: >>> > * Stable processes (release, JIRA workflow, etc.) >>> > * Open source first mentality (100% community releases, etc.) >>> > * Somewhat active non Red Hat community members >>> >>> So at least the last point there (and maybe the second point also?) >>> would in my opinion be reasons to move everything *to* the AeroGear >>> community, rather than *from* it to the FeedHenry community. >>> >>> I don't think it makes a huge difference either way for those of us who >>> work for Red Hat, since we're involved in / aware of both communities as >>> they are; but it could be potentially disruptive to the more established >>> AeroGear open source community. >>> >>> Since I'm not really involved in that community, I'd like to hear what >>> matzew or other long-time members of that community think. Maybe it's no >>> big deal, but I think it's worth thinking about! >>> >>> _______________________________________________ >>> feedhenry-dev mailing list >>> feedhenry-dev at redhat.com >>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>> >> >> >> >> -- >> David Martin >> Red Hat Mobile >> Twitter: @irldavem >> IRC: @irldavem (feedhenry, mobile-internal) >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > > -- > > WEI LI > > SENIOR SOFTWARE ENGINEER > > Red Hat Mobile > > weil at redhat.com M: +353862393272 > > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- WOJCIECH TROCKI Red Hat Mobile IM: wtrocki -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfrizell at redhat.com Thu Nov 30 13:21:36 2017 From: jfrizell at redhat.com (John Frizelle) Date: Thu, 30 Nov 2017 13:21:36 +0000 Subject: [feedhenry-dev] Upstream Community Documentation In-Reply-To: References: <7da1aebd-2cdc-104a-a694-b9720d30647c@redhat.com> <87fu8xf6p4.fsf@w541.grdryn> Message-ID: Hi All, I am meeting with OSAS (the Open Source and Standards group) on Monday to discuss our Open Source strategy and plans and where OSAS might be able to assist. In this meeting I would like to be to give them a definitive answer on where the future of our community lies. To that end, I would like to ask y'all to take 30 seconds to answer this one question poll - https://goo.gl/forms/k5GsxMbeu2AY632P2 The poll will remain open for *the next 24 hours.* Please take the time to cast your vote in this democratic process :-) Cheers, John. -- John Frizelle Chief Architect, Red Hat Mobile Consulting Engineer mobile: *+353 87 290 1644 * twitter:* @johnfriz* skype: *john_frizelle* mail: *jfrizell at redhat.com * On 30 November 2017 at 11:36, Wei Li wrote: > +1 on Dave's idea to move mobile.next work to the AG community. I would > also add that: > > * Rethink/Rebrand the objective of the AG project. I think it should be > something that is close to what we have for mobile.next > * In the meantime, make it clear that the FH community will still be > maintained, but it will only cover for the existing RHMAP projects. > > Hopefully this will avoid future confusing around which community is for > what purpose. It will also allow us to continue support the AG community > that (I think) have more community users than FH. > > Thanks. > > On Thu, Nov 30, 2017 at 9:49 AM, David Martin wrote: > >> TLDR; Let's do all Mobile.next()/5.x development as the Aerogear community >> >> >> I would see the FeedHenry community being strongly linked to RHMAP (Red >> Hat Mobile App Platform). There are large parts of that community that are >> tied into having access to a an RHMAP cluster e.g. SDKs & templates (There >> are some exceptions, which I'll call out later). The RHMAP MBaaS is >> available on github, but it is not very useful without an RHMAP Core. The >> RHMAP Core is only available via a RH subscription. >> >> I would NOT see the Aerogear community as being strongly tied to RHMAP. >> The 2 main Aerogear projects are Unified Push Server & Digger (Build Farm). >> Both of these are standalone services that have been developed in an open >> manner from their inception. >> See Ger's points for more about what the Aerogear community is doing well. >> >> Building the Aerogear community as the upstream for mobile in Red Hat >> would draw a line between what's RHMAP 3.x/4.x and the future (5.x). >> >> Steps from here: >> * move the fh-sync-server project into the Aerogear community as the >> 'Aerogear Data Sync Service' >> * move mobile.next()/5.x collateral (that's still relevant after the POC) >> to the Aerogear community >> * progress development of mobile.next()/5.x as the Aerogear community >> * update https://aerogear.org >> ** update UPS documentation (it reference OpenShift 2! There's been great >> work done on updating UPS for decoupling keycloak & running on OpenShift 3 >> via APB) >> ** add Aerogear Data Sync Service documentation >> ** add Aerogear Digger/Build Farm documentation >> ** add Aerogear mobile.next() (name TBD) documentation >> >> >> I'm sure there's things I've missed, and would welcome other peoples >> thoughts on this idea. >> >> On 29 November 2017 at 15:25, Gerard Ryan wrote: >> >>> Ali Ok writes: >>> >>> > I won't go and do a full assessment of both communities/organizations >>> but >>> > if we're doing this, we should definitely move these things from >>> AeroGear >>> > to FeedHenry side and make sure they don't break in the future at >>> least the >>> > current AeroGear things where things are working nicely: >>> > * Stable processes (release, JIRA workflow, etc.) >>> > * Open source first mentality (100% community releases, etc.) >>> > * Somewhat active non Red Hat community members >>> >>> So at least the last point there (and maybe the second point also?) >>> would in my opinion be reasons to move everything *to* the AeroGear >>> community, rather than *from* it to the FeedHenry community. >>> >>> I don't think it makes a huge difference either way for those of us who >>> work for Red Hat, since we're involved in / aware of both communities as >>> they are; but it could be potentially disruptive to the more established >>> AeroGear open source community. >>> >>> Since I'm not really involved in that community, I'd like to hear what >>> matzew or other long-time members of that community think. Maybe it's no >>> big deal, but I think it's worth thinking about! >>> >>> _______________________________________________ >>> feedhenry-dev mailing list >>> feedhenry-dev at redhat.com >>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>> >> >> >> >> -- >> David Martin >> Red Hat Mobile >> Twitter: @irldavem >> IRC: @irldavem (feedhenry, mobile-internal) >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > > -- > > WEI LI > > SENIOR SOFTWARE ENGINEER > > Red Hat Mobile > > weil at redhat.com M: +353862393272 > > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 11472 bytes Desc: not available URL: From jfrizell at redhat.com Thu Nov 30 13:23:34 2017 From: jfrizell at redhat.com (John Frizelle) Date: Thu, 30 Nov 2017 13:23:34 +0000 Subject: [feedhenry-dev] mobile client or mobile app In-Reply-To: References: <4cd1277c-7043-2770-4b2c-8e1df071b49e@redhat.com> Message-ID: perhaps "construct" instead of "container configuration" MobileClient: A construct that represents the overall mobile application on OpenShift (eg MobileHR) -- John Frizelle Chief Architect, Red Hat Mobile Consulting Engineer mobile: *+353 87 290 1644 * twitter:* @johnfriz* skype: *john_frizelle* mail: *jfrizell at redhat.com * On 30 November 2017 at 11:48, Matthias Wessendorf wrote: > > > On Thu, Nov 30, 2017 at 12:05 PM, Paul Wright wrote: > >> last comment, then I'll stop (promise): >> >> Let's go with MobileClient, as discussed below, but take a bit more time >> about the definition. >> >> I think the definition for PushApplication is great in the context of >> UPS, but with MCP, we're trying to explain an item that is front and >> center, and that the user might misunderstand, or not act as expected. >> >> Can we be more explicit and give an example? >> >> - MobileClient: A container configuration that represents the overall >> mobile application on OpenShift (eg MobileHR) >> > > container ... hrm - not sure - that's also misleading... ?! > > > >> >> >> Paul >> >> On 11/30/2017 10:26 AM, Matthias Wessendorf wrote: >> >> +1 on something like "logical construct / logical representation" - >> and right UPS has also had some naming struggles :) >> >> On Thu, Nov 30, 2017 at 11:11 AM, David Martin >> wrote: >> >>> The term 'Resource' may not suit as it has a meaning in the Kubernetes >>> world. >>> Any object that kubernetes exposes an API for is a resource e.g. >>> Secrets, Pods, Deployments are all resources. >>> >>> In UPS, there's the idea of a 'Push Application', defined here [1] >>> "PushApplication >>> A logical construct that represents an overall mobile application" >>> >>> I don't see any problem with giving it a name like 'Mobile Client' and >>> calling it out in terminology in a similar manner >>> "MobileClient >>> A logical construct that represents an overall mobile application" >>> >>> [1] https://aerogear.org/docs/unifiedpush/ups_userguide/inde >>> x/#_useful_terminology >>> >>> On 29 November 2017 at 09:42, Paul Wright wrote: >>> >>>> and that conversation makes me think we need to be more descriptive, eg >>>> >>>> Mobile App Resource Client (MARC) >>>> >>>> Paul >>>> >>>> On 11/29/2017 09:38 AM, Craig Brookes wrote: >>>> >>>> Spoke with Paul offline. And he thought we were referring to mobile app >>>> through out our docs. So to clarify I meant with the context of the mcp UI >>>> and CLI. >>>> >>>> On Mon, Nov 27, 2017 at 11:49 AM, Paul Wright >>>> wrote: >>>> >>>>> It seems to me that to tackle the mobile market, we should embrace the >>>>> lingua franca, and the one word that unites mobile,cell phone, smartphone, >>>>> handys, etc is 'App' >>>>> >>>>> Paul >>>>> my original draft reply: >>>>> >>>>> Mondays... >>>>> >>>>> Let's fix everything >>>>> >>>>> I'm not against this change, but would like to throw in a note of >>>>> caution: >>>>> >>>>> 1. I don't think OpenShift are really pushing the term apps. Sure, >>>>> there's a command, and even some doc references ( >>>>> https://access.redhat.com/documentation/en-us/openshift_ent >>>>> erprise/3.2/html/installation_and_configuration/install-conf >>>>> ig-imagestreams-templates#creating-instantapp-templates), but would >>>>> like to check with them before assuming that's deliberate. In my mind, >>>>> their term of choice is Application, a bit more of an enterprisey term. >>>>> >>>>> 2. Does "Mobile Clients" solve a problem? we already have a generation >>>>> of ppl saying "there's an app for that", do we want to embrace that or swim >>>>> upstream? what about when there's a web ui to something, we used to bundle >>>>> mobile and web into the term 'client app'. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 11/27/2017 11:03 AM, Jason Madigan wrote: >>>>> >>>>> Deep thoughts this early in the week. App is quite a loaded term >>>>> alright, particularly in an OpenShift context, so I think Mobile Client may >>>>> be a clearer distinction. >>>>> >>>>> Looping in our wordsmith Paul who may have other ideas. >>>>> >>>>> On Mon, Nov 27, 2017 at 9:44 AM, Craig Brookes >>>>> wrote: >>>>> >>>>>> Was thinking about terminology . We have been using the term mobile >>>>>> app, but I wonder would it be clearer to use the term mobile client >>>>>> instead. >>>>>> The main reason for this is that app can mean a server side component >>>>>> (in OpenShift there is the new-app command for example). I think it would >>>>>> make a clearer distinction. Another example is around the word build. When >>>>>> you do an app build in OpenShift it normally produces a docker image and a >>>>>> running server / app. I think using the the term mobile client build makes >>>>>> it clearer what is happening. >>>>>> >>>>>> Just a thought for a Monday morning. >>>>>> >>>>>> -- >>>>>> Craig Brookes >>>>>> RHMAP >>>>>> @maleck13 Github >>>>>> >>>>>> _______________________________________________ >>>>>> feedhenry-dev mailing list >>>>>> feedhenry-dev at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Jason Madigan >>>>> Engineering Manager, Red Hat Mobile >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Craig Brookes >>>> RHMAP >>>> @maleck13 Github >>>> >>>> >>>> >>>> _______________________________________________ >>>> feedhenry-dev mailing list >>>> feedhenry-dev at redhat.com >>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>> >>>> >>> >>> >>> -- >>> David Martin >>> Red Hat Mobile >>> Twitter: @irldavem >>> IRC: @irldavem (feedhenry, mobile-internal) >>> >>> _______________________________________________ >>> feedhenry-dev mailing list >>> feedhenry-dev at redhat.com >>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>> >>> >> >> >> -- >> Project lead AeroGear.org >> >> >> > > > -- > Project lead AeroGear.org > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 11472 bytes Desc: not available URL: From pwright at redhat.com Thu Nov 30 13:44:47 2017 From: pwright at redhat.com (Paul Wright) Date: Thu, 30 Nov 2017 13:44:47 +0000 Subject: [feedhenry-dev] mobile client or mobile app In-Reply-To: References: <4cd1277c-7043-2770-4b2c-8e1df071b49e@redhat.com> Message-ID: <52bf58a7-041e-76c6-6a07-2b8fa228cec6@redhat.com> That works for me: * it's something you're going to see in OpenShift * there's an example that kinda helps relate the scope * it's not the 'Mobile App' Paul On 11/30/2017 01:23 PM, John Frizelle wrote: > perhaps "construct" instead of "container configuration" > > MobileClient: A construct that represents the overall mobile > application on OpenShift (eg MobileHR) > > > -- > John Frizelle > Chief Architect, Red Hat Mobile > Consulting Engineer > > mobile:*+353 87 290 1644 * > twitter:*?@johnfriz* > skype: *john_frizelle* > mail: *jfrizell at redhat.com * > > > > > On 30 November 2017 at 11:48, Matthias Wessendorf > wrote: > > > > On Thu, Nov 30, 2017 at 12:05 PM, Paul Wright > wrote: > > last comment, then I'll stop (promise): > > Let's go with MobileClient, as discussed below, but take a bit > more time about the definition. > > I think the definition for PushApplication is great in the > context of UPS, but with MCP, we're trying to explain an item > that is front and center, and that the user might > misunderstand, or not act as expected. > > Can we be more explicit and give an example? > > - MobileClient: A container configuration that represents the > overall mobile application on OpenShift (eg MobileHR) > > > container ... hrm - not sure -? that's also misleading... ?! > > > > Paul > > > On 11/30/2017 10:26 AM, Matthias Wessendorf wrote: >> +1 on something like "logical construct / logical >> representation" ?- and right UPS has also had some naming >> struggles :) >> >> On Thu, Nov 30, 2017 at 11:11 AM, David Martin >> > wrote: >> >> The term 'Resource' may not suit as it has a meaning in >> the Kubernetes world. >> Any object that kubernetes exposes an API for is a >> resource e.g. Secrets, Pods, Deployments are all resources. >> >> In UPS, there's the idea of a 'Push Application', defined >> here [1] >> "PushApplication >> A logical construct that represents an overall mobile >> application" >> >> I don't see any problem with giving it a name like >> 'Mobile Client' and calling it out in terminology in a >> similar manner >> "MobileClient >> A logical construct that represents an overall mobile >> application" >> >> [1] >> https://aerogear.org/docs/unifiedpush/ups_userguide/index/#_useful_terminology >> >> >> On 29 November 2017 at 09:42, Paul Wright >> > wrote: >> >> and that conversation makes me think we need to be >> more descriptive, eg >> >> Mobile App Resource Client (MARC) >> >> Paul >> >> >> On 11/29/2017 09:38 AM, Craig Brookes wrote: >>> Spoke with Paul offline. And he thought we were >>> referring to mobile app through out our docs. So to >>> clarify I meant with the context of the mcp UI and CLI. >>> >>> On Mon, Nov 27, 2017 at 11:49 AM, Paul Wright >>> > wrote: >>> >>> It seems to me that to tackle the mobile market, >>> we should embrace the lingua franca, and the one >>> word that unites mobile,cell phone, smartphone, >>> handys, etc is 'App' >>> >>> Paul >>> >>> my original draft reply: >>> >>> Mondays... >>> >>> Let's fix everything >>> >>> I'm not against this change, but would like to >>> throw in a note of caution: >>> >>> 1. I don't think OpenShift are really pushing >>> the term apps. Sure, there's a command, and even >>> some doc references >>> (https://access.redhat.com/documentation/en-us/openshift_enterprise/3.2/html/installation_and_configuration/install-config-imagestreams-templates#creating-instantapp-templates >>> ), >>> but would like to check with them before >>> assuming that's deliberate. In my mind, their >>> term of choice is Application, a bit more of an >>> enterprisey term. >>> >>> 2. Does "Mobile Clients" solve a problem? we >>> already have a generation of ppl saying "there's >>> an app for that", do we want to embrace that or >>> swim upstream? what about when there's a web ui >>> to something, we used to bundle mobile and web >>> into the term 'client app'. >>> >>> >>> >>> >>> >>> On 11/27/2017 11:03 AM, Jason Madigan wrote: >>>> Deep thoughts this early in the week. App is >>>> quite a loaded term alright, particularly in an >>>> OpenShift context, so I think Mobile Client may >>>> be a clearer distinction. >>>> >>>> Looping in our wordsmith Paul who may have >>>> other ideas. >>>> >>>> On Mon, Nov 27, 2017 at 9:44 AM, Craig Brookes >>>> >>> > wrote: >>>> >>>> Was thinking about terminology . We have >>>> been using the term mobile app, but I >>>> wonder would it be clearer to use the term >>>> mobile client instead. >>>> The main reason for this is that app can >>>> mean a server side component (in OpenShift >>>> there is the new-app command for example). >>>> I think it would make a clearer >>>> distinction. Another example is around the >>>> word build. When you do an app build in >>>> OpenShift it normally produces a docker >>>> image and a running server / app. I think >>>> using the the term mobile client build >>>> makes it clearer what is happening. >>>> >>>> Just a thought for a Monday morning. >>>> >>>> -- >>>> Craig Brookes >>>> RHMAP >>>> @maleck13 Github >>>> >>>> _______________________________________________ >>>> feedhenry-dev mailing list >>>> feedhenry-dev at redhat.com >>>> >>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Jason Madigan >>>> Engineering Manager, Red Hat Mobile >>> >>> >>> >>> >>> -- >>> Craig Brookes >>> RHMAP >>> @maleck13 Github >> >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> >> >> >> >> -- >> David Martin >> Red Hat Mobile >> Twitter: @irldavem >> IRC: @irldavem (feedhenry, mobile-internal) >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> >> >> >> >> -- >> Project lead AeroGear.org > > > > > -- > Project lead AeroGear.org > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 11472 bytes Desc: not available URL: From mwessend at redhat.com Thu Nov 30 14:13:15 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Thu, 30 Nov 2017 15:13:15 +0100 Subject: [feedhenry-dev] mobile client or mobile app In-Reply-To: References: <4cd1277c-7043-2770-4b2c-8e1df071b49e@redhat.com> Message-ID: I like that - and is similar to UPS terminology :) On Thu, Nov 30, 2017 at 2:23 PM, John Frizelle wrote: > perhaps "construct" instead of "container configuration" > > MobileClient: A construct that represents the overall mobile application > on OpenShift (eg MobileHR) > > > -- > John Frizelle > Chief Architect, Red Hat Mobile > Consulting Engineer > > mobile: *+353 87 290 1644 * > twitter:* @johnfriz* > skype: *john_frizelle* > mail: *jfrizell at redhat.com * > > > > > On 30 November 2017 at 11:48, Matthias Wessendorf > wrote: > >> >> >> On Thu, Nov 30, 2017 at 12:05 PM, Paul Wright wrote: >> >>> last comment, then I'll stop (promise): >>> >>> Let's go with MobileClient, as discussed below, but take a bit more time >>> about the definition. >>> >>> I think the definition for PushApplication is great in the context of >>> UPS, but with MCP, we're trying to explain an item that is front and >>> center, and that the user might misunderstand, or not act as expected. >>> >>> Can we be more explicit and give an example? >>> >>> - MobileClient: A container configuration that represents the overall >>> mobile application on OpenShift (eg MobileHR) >>> >> >> container ... hrm - not sure - that's also misleading... ?! >> >> >> >>> >>> >>> Paul >>> >>> On 11/30/2017 10:26 AM, Matthias Wessendorf wrote: >>> >>> +1 on something like "logical construct / logical representation" - >>> and right UPS has also had some naming struggles :) >>> >>> On Thu, Nov 30, 2017 at 11:11 AM, David Martin >>> wrote: >>> >>>> The term 'Resource' may not suit as it has a meaning in the Kubernetes >>>> world. >>>> Any object that kubernetes exposes an API for is a resource e.g. >>>> Secrets, Pods, Deployments are all resources. >>>> >>>> In UPS, there's the idea of a 'Push Application', defined here [1] >>>> "PushApplication >>>> A logical construct that represents an overall mobile application" >>>> >>>> I don't see any problem with giving it a name like 'Mobile Client' and >>>> calling it out in terminology in a similar manner >>>> "MobileClient >>>> A logical construct that represents an overall mobile application" >>>> >>>> [1] https://aerogear.org/docs/unifiedpush/ups_userguide/inde >>>> x/#_useful_terminology >>>> >>>> On 29 November 2017 at 09:42, Paul Wright wrote: >>>> >>>>> and that conversation makes me think we need to be more descriptive, eg >>>>> >>>>> Mobile App Resource Client (MARC) >>>>> >>>>> Paul >>>>> >>>>> On 11/29/2017 09:38 AM, Craig Brookes wrote: >>>>> >>>>> Spoke with Paul offline. And he thought we were referring to mobile >>>>> app through out our docs. So to clarify I meant with the context of the mcp >>>>> UI and CLI. >>>>> >>>>> On Mon, Nov 27, 2017 at 11:49 AM, Paul Wright >>>>> wrote: >>>>> >>>>>> It seems to me that to tackle the mobile market, we should embrace >>>>>> the lingua franca, and the one word that unites mobile,cell phone, >>>>>> smartphone, handys, etc is 'App' >>>>>> >>>>>> Paul >>>>>> my original draft reply: >>>>>> >>>>>> Mondays... >>>>>> >>>>>> Let's fix everything >>>>>> >>>>>> I'm not against this change, but would like to throw in a note of >>>>>> caution: >>>>>> >>>>>> 1. I don't think OpenShift are really pushing the term apps. Sure, >>>>>> there's a command, and even some doc references ( >>>>>> https://access.redhat.com/documentation/en-us/openshift_ent >>>>>> erprise/3.2/html/installation_and_configuration/install-conf >>>>>> ig-imagestreams-templates#creating-instantapp-templates), but would >>>>>> like to check with them before assuming that's deliberate. In my mind, >>>>>> their term of choice is Application, a bit more of an enterprisey term. >>>>>> >>>>>> 2. Does "Mobile Clients" solve a problem? we already have a >>>>>> generation of ppl saying "there's an app for that", do we want to embrace >>>>>> that or swim upstream? what about when there's a web ui to something, we >>>>>> used to bundle mobile and web into the term 'client app'. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 11/27/2017 11:03 AM, Jason Madigan wrote: >>>>>> >>>>>> Deep thoughts this early in the week. App is quite a loaded term >>>>>> alright, particularly in an OpenShift context, so I think Mobile Client may >>>>>> be a clearer distinction. >>>>>> >>>>>> Looping in our wordsmith Paul who may have other ideas. >>>>>> >>>>>> On Mon, Nov 27, 2017 at 9:44 AM, Craig Brookes >>>>>> wrote: >>>>>> >>>>>>> Was thinking about terminology . We have been using the term mobile >>>>>>> app, but I wonder would it be clearer to use the term mobile client >>>>>>> instead. >>>>>>> The main reason for this is that app can mean a server side >>>>>>> component (in OpenShift there is the new-app command for example). I think >>>>>>> it would make a clearer distinction. Another example is around the word >>>>>>> build. When you do an app build in OpenShift it normally produces a docker >>>>>>> image and a running server / app. I think using the the term mobile client >>>>>>> build makes it clearer what is happening. >>>>>>> >>>>>>> Just a thought for a Monday morning. >>>>>>> >>>>>>> -- >>>>>>> Craig Brookes >>>>>>> RHMAP >>>>>>> @maleck13 Github >>>>>>> >>>>>>> _______________________________________________ >>>>>>> feedhenry-dev mailing list >>>>>>> feedhenry-dev at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Jason Madigan >>>>>> Engineering Manager, Red Hat Mobile >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Craig Brookes >>>>> RHMAP >>>>> @maleck13 Github >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> feedhenry-dev mailing list >>>>> feedhenry-dev at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>>> >>>>> >>>> >>>> >>>> -- >>>> David Martin >>>> Red Hat Mobile >>>> Twitter: @irldavem >>>> IRC: @irldavem (feedhenry, mobile-internal) >>>> >>>> _______________________________________________ >>>> feedhenry-dev mailing list >>>> feedhenry-dev at redhat.com >>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>> >>>> >>> >>> >>> -- >>> Project lead AeroGear.org >>> >>> >>> >> >> >> -- >> Project lead AeroGear.org >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 11472 bytes Desc: not available URL: