From dpassos at redhat.com Tue Jan 2 16:45:51 2018 From: dpassos at redhat.com (Daniel Passos) Date: Tue, 2 Jan 2018 14:45:51 -0200 Subject: [feedhenry-dev] AeroGear repos moved to the attic org In-Reply-To: References: Message-ID: Hi I still working on deprecate old project and move to the AeroGear Attic[1] Here is a new list of project deprecated/moved: Security - aerogear-security-hawk - aerogear-security-picketlink - aerogear-security-picketbox - aerogear-security - aerogear-security-shiro - aerogear-jaxrs-demo Controller - aerogear-controller Simplepush - aerogear-simplepush-quickstart aerogear-simplepush-unifiedpush-quickstart Others - TODO - aerogear-haml - kitchensink-torquebox-mobile - jboss-keynote-2012 [1] http://github.com/aerogear-attic ? On Mon, Dec 18, 2017 at 1:17 PM, Matthias Wessendorf wrote: > +1 > > On Mon, Dec 18, 2017 at 3:37 PM, Daniel Passos wrote: > >> Hi, >> >> I have moved all archive/no longer maintained Android[1], iOS[2] and >> Cordova[3] libraries to the aerogear-attic[4] repo and deleted those from >> the aerogear[5] >> >> [1] https://github.com/aerogear-attic?utf8=?&q=android >> [2] https://github.com/aerogear-attic?utf8=?&q=ios >> [3] https://github.com/aerogear-attic?utf8=?&q=cordova >> [4] https://github.com/aerogear-attic >> [5] https://github.com/aerogear >> >> >> -- >> -- Passos >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > > -- > Project lead AeroGear.org > -- -- Passos -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpassos at redhat.com Tue Jan 2 17:14:44 2018 From: dpassos at redhat.com (Daniel Passos) Date: Tue, 2 Jan 2018 15:14:44 -0200 Subject: [feedhenry-dev] AeroGear Windows Libraries support In-Reply-To: References: Message-ID: Hey Nano, I was talking about AeroGear libraries not Feedhenry one. On Mon, Dec 18, 2017 at 1:05 PM, Nano Gough wrote: > We are in the process of marking these as deprecated with view to formally > removing support for windows. > > On 18 December 2017 at 14:38, Daniel Passos wrote: > >> Hi, >> >> Should we still supporting Windows libraries? >> >> Here is the list of the libraries we have for the Windows platform, there >> is no update for these for a long time >> >> * aerogear-windows-oauth2 >> * aerogear-windows-push >> * aerogear-windows-otp >> >> -- >> -- Passos >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > > -- > Nano Gough > > Senior Principal Product Manager > RedHat Mobile > > Tel (mob): +353 (0) 86 3651465 <+353%2086%20365%201465> > > ngough at redhat.com > -- -- Passos -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpassos at redhat.com Tue Jan 2 17:16:14 2018 From: dpassos at redhat.com (Daniel Passos) Date: Tue, 2 Jan 2018 15:16:14 -0200 Subject: [feedhenry-dev] AeroGear Github projects Message-ID: Hi I wanna create some Github projects to help us to organize repos on AeroGear organization. Wdyt? I was thinking about create 2 types of projects: 1. Platforms 2. Features Some examples in my mind: Platforms Android iOS JS Xamarin Cordova Feature Website Core Http Push OAuth2 Database Security Sync PS: A repo can be in more than one project. ? -- -- Passos -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwright at redhat.com Tue Jan 2 17:40:07 2018 From: pwright at redhat.com (Paul Wright) Date: Tue, 2 Jan 2018 17:40:07 +0000 Subject: [feedhenry-dev] AeroGear Github projects In-Reply-To: References: Message-ID: <0836c5f2-70ce-cfd3-193a-4b312eb0de35@redhat.com> Hi Daniel, can you outline why you think it will help? If there are projects for all platforms and features, won't we end up wrangling projects as well as repos? Note: I'm saying this with true ignorance, I have no idea whether that's true or not ;) Paul On 01/02/2018 05:16 PM, Daniel Passos wrote: > > Hi > > I wanna create some Github projects to help us to organize repos on > AeroGear organization. Wdyt? > > I was thinking about create 2 types of projects: > > 1. Platforms > 2. Features > > Some examples in my mind: > > > Platforms > > Android > iOS > JS > Xamarin > Cordova > > > Feature > > Website > Core > Http > Push > OAuth2 > Database > Security > Sync > > PS: A repo can be in more than one project. > > ? > -- > -- Passos > > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev -- Paul Wright Mobile Docs (github: finp) -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpassos at redhat.com Tue Jan 2 17:47:23 2018 From: dpassos at redhat.com (Daniel Passos) Date: Tue, 2 Jan 2018 15:47:23 -0200 Subject: [feedhenry-dev] AeroGear Github projects In-Reply-To: <0836c5f2-70ce-cfd3-193a-4b312eb0de35@redhat.com> References: <0836c5f2-70ce-cfd3-193a-4b312eb0de35@redhat.com> Message-ID: Hi Paul, Nevermind, I'd like to create a project to group repos, like: Project X aerogear-android-x aerogear-ios-x But, GH do it in a different way. Just realized GH project is per repo not per org My mistake. Sorry about that. On Tue, Jan 2, 2018 at 3:40 PM, Paul Wright wrote: > Hi Daniel, > > can you outline why you think it will help? > > If there are projects for all platforms and features, won't we end up > wrangling projects as well as repos? > > Note: I'm saying this with true ignorance, I have no idea whether that's > true or not ;) > > Paul > > On 01/02/2018 05:16 PM, Daniel Passos wrote: > > Hi > > I wanna create some Github projects to help us to organize repos on > AeroGear organization. Wdyt? > > I was thinking about create 2 types of projects: > > 1. Platforms > 2. Features > > Some examples in my mind: > Platforms > > Android > iOS > JS > Xamarin > Cordova > Feature > > Website > Core > Http > Push > OAuth2 > Database > Security > Sync > > PS: A repo can be in more than one project. > ? > -- > -- Passos > > > _______________________________________________ > feedhenry-dev mailing listfeedhenry-dev at redhat.comhttps://www.redhat.com/mailman/listinfo/feedhenry-dev > > > -- > Paul Wright > Mobile Docs (github: finp) > > -- -- Passos -------------- next part -------------- An HTML attachment was scrubbed... URL: From weil at redhat.com Tue Jan 2 21:22:21 2018 From: weil at redhat.com (Wei Li) Date: Tue, 2 Jan 2018 21:22:21 +0000 Subject: [feedhenry-dev] AeroGear Github projects In-Reply-To: References: <0836c5f2-70ce-cfd3-193a-4b312eb0de35@redhat.com> Message-ID: You can have GH project per org - https://github.com/orgs/aerogear/projects. But I don't know why we need it given that we already have Trello & Jira? On Tue, Jan 2, 2018 at 5:47 PM, Daniel Passos wrote: > Hi Paul, > > Nevermind, > > I'd like to create a project to group repos, like: > > Project X > > aerogear-android-x > aerogear-ios-x > > But, GH do it in a different way. Just realized GH project is per repo not > per org > > My mistake. Sorry about that. > > > On Tue, Jan 2, 2018 at 3:40 PM, Paul Wright wrote: > >> Hi Daniel, >> >> can you outline why you think it will help? >> >> If there are projects for all platforms and features, won't we end up >> wrangling projects as well as repos? >> >> Note: I'm saying this with true ignorance, I have no idea whether that's >> true or not ;) >> >> Paul >> >> On 01/02/2018 05:16 PM, Daniel Passos wrote: >> >> Hi >> >> I wanna create some Github projects to help us to organize repos on >> AeroGear organization. Wdyt? >> >> I was thinking about create 2 types of projects: >> >> 1. Platforms >> 2. Features >> >> Some examples in my mind: >> Platforms >> >> Android >> iOS >> JS >> Xamarin >> Cordova >> Feature >> >> Website >> Core >> Http >> Push >> OAuth2 >> Database >> Security >> Sync >> >> PS: A repo can be in more than one project. >> ? >> -- >> -- Passos >> >> >> _______________________________________________ >> feedhenry-dev mailing listfeedhenry-dev at redhat.comhttps://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> >> -- >> Paul Wright >> Mobile Docs (github: finp) >> >> > > > -- > -- Passos > > _______________________________________________ > 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 dpassos at redhat.com Tue Jan 2 22:08:39 2018 From: dpassos at redhat.com (Daniel Passos) Date: Tue, 2 Jan 2018 20:08:39 -0200 Subject: [feedhenry-dev] AeroGear Github projects In-Reply-To: References: <0836c5f2-70ce-cfd3-193a-4b312eb0de35@redhat.com> Message-ID: I was thinking about have a project to group the repos with the same feature/platform, but that is not the GH idea. I thought project will give us something like https://github.com/aerogear/projects/sync and this link will list all sync repos As I sad, nevermind! On Tue, Jan 2, 2018 at 7:22 PM, Wei Li wrote: > You can have GH project per org - https://github.com/orgs/ > aerogear/projects. But I don't know why we need it given that we already > have Trello & Jira? > > On Tue, Jan 2, 2018 at 5:47 PM, Daniel Passos wrote: > >> Hi Paul, >> >> Nevermind, >> >> I'd like to create a project to group repos, like: >> >> Project X >> >> aerogear-android-x >> aerogear-ios-x >> >> But, GH do it in a different way. Just realized GH project is per repo >> not per org >> >> My mistake. Sorry about that. >> >> >> On Tue, Jan 2, 2018 at 3:40 PM, Paul Wright wrote: >> >>> Hi Daniel, >>> >>> can you outline why you think it will help? >>> >>> If there are projects for all platforms and features, won't we end up >>> wrangling projects as well as repos? >>> >>> Note: I'm saying this with true ignorance, I have no idea whether that's >>> true or not ;) >>> >>> Paul >>> >>> On 01/02/2018 05:16 PM, Daniel Passos wrote: >>> >>> Hi >>> >>> I wanna create some Github projects to help us to organize repos on >>> AeroGear organization. Wdyt? >>> >>> I was thinking about create 2 types of projects: >>> >>> 1. Platforms >>> 2. Features >>> >>> Some examples in my mind: >>> Platforms >>> >>> Android >>> iOS >>> JS >>> Xamarin >>> Cordova >>> Feature >>> >>> Website >>> Core >>> Http >>> Push >>> OAuth2 >>> Database >>> Security >>> Sync >>> >>> PS: A repo can be in more than one project. >>> ? >>> -- >>> -- Passos >>> >>> >>> _______________________________________________ >>> feedhenry-dev mailing listfeedhenry-dev at redhat.comhttps://www.redhat.com/mailman/listinfo/feedhenry-dev >>> >>> >>> -- >>> Paul Wright >>> Mobile Docs (github: finp) >>> >>> >> >> >> -- >> -- Passos >> >> _______________________________________________ >> 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 > > -- -- Passos -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgallaso at redhat.com Wed Jan 3 09:08:09 2018 From: jgallaso at redhat.com (Jose Miguel Gallas Olmedo) Date: Wed, 3 Jan 2018 10:08:09 +0100 Subject: [feedhenry-dev] [aerogear-dev] AeroGear Github projects In-Reply-To: <0836c5f2-70ce-cfd3-193a-4b312eb0de35@redhat.com> References: <0836c5f2-70ce-cfd3-193a-4b312eb0de35@redhat.com> Message-ID: I thought "projects" was meant to be a Kanban like Trello. Is it normally used to organise repos as well? Because it might cause some confusion as well. JOSE MIGUEL GALLAS OLMEDO ASSOCIATE QE, mobile Red Hat M: +34618488633 On 2 January 2018 at 18:40, Paul Wright wrote: > Hi Daniel, > > can you outline why you think it will help? > > If there are projects for all platforms and features, won't we end up > wrangling projects as well as repos? > > Note: I'm saying this with true ignorance, I have no idea whether that's > true or not ;) > > Paul > > On 01/02/2018 05:16 PM, Daniel Passos wrote: > > Hi > > I wanna create some Github projects to help us to organize repos on > AeroGear organization. Wdyt? > > I was thinking about create 2 types of projects: > > 1. Platforms > 2. Features > > Some examples in my mind: > Platforms > > Android > iOS > JS > Xamarin > Cordova > Feature > > Website > Core > Http > Push > OAuth2 > Database > Security > Sync > > PS: A repo can be in more than one project. > ? > -- > -- Passos > > > _______________________________________________ > feedhenry-dev mailing listfeedhenry-dev at redhat.comhttps://www.redhat.com/mailman/listinfo/feedhenry-dev > > > -- > Paul Wright > Mobile Docs (github: finp) > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwright at redhat.com Wed Jan 3 10:13:57 2018 From: pwright at redhat.com (Paul Wright) Date: Wed, 3 Jan 2018 10:13:57 +0000 Subject: [feedhenry-dev] AeroGear Github projects In-Reply-To: References: <0836c5f2-70ce-cfd3-193a-4b312eb0de35@redhat.com> Message-ID: <9fcf9341-8c30-50f5-3b81-c50e8df95e87@redhat.com> Hi Daniel, I like the idea (I think this is how the docs organization should be driven), how about: As a developer or contributor, I'd like to know what repos are associated with the feature/platform I'm planning to develop for. I think this was the original intention behind the 'Modules' pulldown on aerogear.org which, for example, links to https://aerogear.org/sync/.? Unfortunately, the repos link doesn't work as expected for me. (and I'm not sure if changing the link to https://github.com/search?q=org%3Aaerogear+sync is a good solution) As I've said earlier [1], I find aerogear.org difficult to maintain (it's now a mishmash of html/markdown/asciidoc, with dependencies I seem to have difficulty following [2]. If there isn't an appetite for changing to asciibinder, I can still help reorganize, update and publish documentation, and this seems as good an issue as any to start with. How about doing this collation on the wiki (using asciidoc): https://github.com/aerogear/aerogear.org/wiki WDYT? Paul [1] https://www.redhat.com/archives/feedhenry-dev/2017-December/msg00091.html [2] https://github.com/aerogear/aerogear.org/pull/714 On 01/02/2018 10:08 PM, Daniel Passos wrote: > I was thinking about have a project to group the repos with the same > feature/platform, but that is not the GH idea. > > I thought project will give us something like > https://github.com/aerogear/projects/sync and this link will list all > sync repos > > As I sad, nevermind! > > On Tue, Jan 2, 2018 at 7:22 PM, Wei Li > wrote: > > You can have GH project per org - > https://github.com/orgs/aerogear/projects > . But I don't know why > we need it given that we already have Trello & Jira? > > On Tue, Jan 2, 2018 at 5:47 PM, Daniel Passos > wrote: > > Hi Paul, > > Nevermind, > > I'd like to create a project to group repos, like: > > Project X > > aerogear-android-x > aerogear-ios-x > > But, GH do it in a different way. Just realized GH project is > per repo not per org > > My mistake. Sorry about that. > > > On Tue, Jan 2, 2018 at 3:40 PM, Paul Wright > > wrote: > > Hi Daniel, > > can you outline why you think it will help? > > If there are projects for all platforms and features, > won't we end up wrangling projects as well as repos? > > Note: I'm saying this with true ignorance, I have no idea > whether that's true or not ;) > > Paul > > > On 01/02/2018 05:16 PM, Daniel Passos wrote: >> >> Hi >> >> I wanna create some Github projects to help us to >> organize repos on AeroGear organization. Wdyt? >> >> I was thinking about create 2 types of projects: >> >> 1. Platforms >> 2. Features >> >> Some examples in my mind: >> >> >> Platforms >> >> Android >> iOS >> JS >> Xamarin >> Cordova >> >> >> Feature >> >> Website >> Core >> Http >> Push >> OAuth2 >> Database >> Security >> Sync >> >> PS: A repo can be in more than one project. >> >> ? >> -- >> -- Passos >> >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> > > -- > Paul Wright > Mobile Docs (github: finp) > > > > > -- > -- Passos > > _______________________________________________ > 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 > > > > > > > > -- > -- Passos -- Paul Wright Mobile Docs (github: finp) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgallaso at redhat.com Wed Jan 3 10:44:29 2018 From: jgallaso at redhat.com (Jose Miguel Gallas Olmedo) Date: Wed, 3 Jan 2018 11:44:29 +0100 Subject: [feedhenry-dev] [aerogear-dev] GSOC 2018 - 2 AeroGear Digger ideas In-Reply-To: References: Message-ID: Xamarin support FTW! JOSE MIGUEL GALLAS OLMEDO ASSOCIATE QE, mobile Red Hat M: +34618488633 On 21 December 2017 at 11:39, Ali Ok wrote: > Hi, > > We have 2 ideas for GSoC 2018 with AeroGear Digger. > > - AeroGear Digger - Xamarin support > - AeroGear Digger - CI/CD workflows on AeroGear Digger with advanced > testing cases > > > https://developer.jboss.org/wiki/GSoC2018Ideas > > Any feedback is appreciated. > > Or, let us know if you're interested as students :) > > Cheers, > Ali > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpassos at redhat.com Wed Jan 3 11:22:42 2018 From: dpassos at redhat.com (Daniel Passos) Date: Wed, 3 Jan 2018 09:22:42 -0200 Subject: [feedhenry-dev] [aerogear-dev] AeroGear Github projects In-Reply-To: References: <0836c5f2-70ce-cfd3-193a-4b312eb0de35@redhat.com> Message-ID: Yeap, GH projects is a Kanban board, I only realized that after sent the email. Nopz it's not to organize project. My fault :) On Wed, Jan 3, 2018 at 7:08 AM, Jose Miguel Gallas Olmedo < jgallaso at redhat.com> wrote: > I thought "projects" was meant to be a Kanban like Trello. Is it normally > used to organise repos as well? Because it might cause some confusion as > well. > > JOSE MIGUEL GALLAS OLMEDO > > ASSOCIATE QE, mobile > > Red Hat > > > > M: +34618488633 > > > > On 2 January 2018 at 18:40, Paul Wright wrote: > >> Hi Daniel, >> >> can you outline why you think it will help? >> >> If there are projects for all platforms and features, won't we end up >> wrangling projects as well as repos? >> >> Note: I'm saying this with true ignorance, I have no idea whether that's >> true or not ;) >> >> Paul >> >> On 01/02/2018 05:16 PM, Daniel Passos wrote: >> >> Hi >> >> I wanna create some Github projects to help us to organize repos on >> AeroGear organization. Wdyt? >> >> I was thinking about create 2 types of projects: >> >> 1. Platforms >> 2. Features >> >> Some examples in my mind: >> Platforms >> >> Android >> iOS >> JS >> Xamarin >> Cordova >> Feature >> >> Website >> Core >> Http >> Push >> OAuth2 >> Database >> Security >> Sync >> >> PS: A repo can be in more than one project. >> ? >> -- >> -- Passos >> >> >> _______________________________________________ >> feedhenry-dev mailing listfeedhenry-dev at redhat.comhttps://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> >> -- >> Paul Wright >> Mobile Docs (github: finp) >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > -- -- Passos -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpassos at redhat.com Wed Jan 3 11:31:29 2018 From: dpassos at redhat.com (Daniel Passos) Date: Wed, 3 Jan 2018 09:31:29 -0200 Subject: [feedhenry-dev] AeroGear Github projects In-Reply-To: <9fcf9341-8c30-50f5-3b81-c50e8df95e87@redhat.com> References: <0836c5f2-70ce-cfd3-193a-4b312eb0de35@redhat.com> <9fcf9341-8c30-50f5-3b81-c50e8df95e87@redhat.com> Message-ID: Hey Paul, On Wed, Jan 3, 2018 at 8:13 AM, Paul Wright wrote: > Hi Daniel, > > I like the idea (I think this is how the docs organization should be > driven), how about: > > As a developer or contributor, I'd like to know what repos are associated > with the feature/platform I'm planning to develop for. > > I think this was the original intention behind the 'Modules' pulldown on > aerogear.org which, for example, links to https://aerogear.org/sync/. > Unfortunately, the repos link > doesn't work as expected for me. (and I'm not sure if changing the link to > https://github.com/search?q=org%3Aaerogear+sync is a good solution) > q instead of search in your query string. Here is an example: You should use https://github.com/aerogear?q=sync > As I've said earlier [1], I find aerogear.org difficult to maintain (it's > now a mishmash of html/markdown/asciidoc, with dependencies I seem to have > difficulty following [2]. > I totally agree with you, I know that pain. There is a lot of history behind of this mess. I also don't like this. > If there isn't an appetite for changing to asciibinder, I can still help > reorganize, update and publish documentation, and this seems as good an > issue as any to start with. How about doing this collation on the wiki > (using asciidoc): > > https://github.com/aerogear/aerogear.org/wiki > I'm not a big fan of Asciidoctor, I usually prefer to use Markdown, because it is more simple and more community driven, but I'm not against to use any other thing, just wanna use only *one* thing :) I don't know that is the best approach to solve it. Not sure if a wiki in the aerogear.org or if we should move the documentation for wiki in each repo. I only know docs is a little outdated and maintain it is a hell. Anyway, whatever decision we made count me in to help to update/organize the docs. > WDYT? > > Paul > > [1] https://www.redhat.com/archives/feedhenry-dev/2017- > December/msg00091.html > > [2] https://github.com/aerogear/aerogear.org/pull/714 > > On 01/02/2018 10:08 PM, Daniel Passos wrote: > > I was thinking about have a project to group the repos with the same > feature/platform, but that is not the GH idea. > > I thought project will give us something like https://github.com/aerogear/ > projects/sync and this link will list all sync repos > > As I sad, nevermind! > > On Tue, Jan 2, 2018 at 7:22 PM, Wei Li wrote: > >> You can have GH project per org - https://github.com/orgs/aero >> gear/projects. But I don't know why we need it given that we already >> have Trello & Jira? >> >> On Tue, Jan 2, 2018 at 5:47 PM, Daniel Passos wrote: >> >>> Hi Paul, >>> >>> Nevermind, >>> >>> I'd like to create a project to group repos, like: >>> >>> Project X >>> >>> aerogear-android-x >>> aerogear-ios-x >>> >>> But, GH do it in a different way. Just realized GH project is per repo >>> not per org >>> >>> My mistake. Sorry about that. >>> >>> >>> On Tue, Jan 2, 2018 at 3:40 PM, Paul Wright wrote: >>> >>>> Hi Daniel, >>>> >>>> can you outline why you think it will help? >>>> >>>> If there are projects for all platforms and features, won't we end up >>>> wrangling projects as well as repos? >>>> >>>> Note: I'm saying this with true ignorance, I have no idea whether >>>> that's true or not ;) >>>> >>>> Paul >>>> >>>> On 01/02/2018 05:16 PM, Daniel Passos wrote: >>>> >>>> Hi >>>> >>>> I wanna create some Github projects to help us to organize repos on >>>> AeroGear organization. Wdyt? >>>> >>>> I was thinking about create 2 types of projects: >>>> >>>> 1. Platforms >>>> 2. Features >>>> >>>> Some examples in my mind: >>>> Platforms >>>> >>>> Android >>>> iOS >>>> JS >>>> Xamarin >>>> Cordova >>>> Feature >>>> >>>> Website >>>> Core >>>> Http >>>> Push >>>> OAuth2 >>>> Database >>>> Security >>>> Sync >>>> >>>> PS: A repo can be in more than one project. >>>> ? >>>> -- >>>> -- Passos >>>> >>>> >>>> _______________________________________________ >>>> feedhenry-dev mailing listfeedhenry-dev at redhat.comhttps://www.redhat.com/mailman/listinfo/feedhenry-dev >>>> >>>> >>>> -- >>>> Paul Wright >>>> Mobile Docs (github: finp) >>>> >>>> >>> >>> >>> -- >>> -- Passos >>> >>> _______________________________________________ >>> 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 >> >> > > > > -- > -- Passos > > > -- > Paul Wright > Mobile Docs (github: finp) > > -- -- Passos -------------- next part -------------- An HTML attachment was scrubbed... URL: From davmarti at redhat.com Thu Jan 4 10:34:41 2018 From: davmarti at redhat.com (David Martin) Date: Thu, 4 Jan 2018 10:34:41 +0000 Subject: [feedhenry-dev] 5.x/Mobile Comms Message-ID: Hi all, This email is moreso a formality so everyone knows how we have been communicating, but wanted to share so everyone is aware, particular with a lot of new team members working on 5.x. However, if you feel strongly against anything here, please lets discuss. TLDR; * Lets default to #aerogear for all chat, discussions etc.. * Lets use direct messages, email or #mobile-internal for private chat, discussions etc... Reasons * #aerogear on freenode is already active with 5.x chat & discussions, and has been for ~6 months (it's been active a lot longer than that for mobile things) * having a central place for chat increases the likelihood of getting help or feedback, particularly if people across different teams hit the same issues and have solved it already. It also increases visibility of work other teams are doing, which can avoid duplication & encourage collaboration * we are all part of 1 larger team working on the same goal. Lets not exclude or silo ourselves * #aerogear is public/open. 5.x development is all upstream/open. Removing any barriers to building an open community, which we are all the foundation of, makes sense -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (#aerogear) -------------- next part -------------- An HTML attachment was scrubbed... URL: From lzuccare at redhat.com Thu Jan 4 10:59:05 2018 From: lzuccare at redhat.com (Luigi Zuccarelli) Date: Thu, 4 Jan 2018 10:59:05 +0000 Subject: [feedhenry-dev] 5.x/Mobile Comms In-Reply-To: References: Message-ID: +1 - totally agree David. Remove all the chat clutter from my desktop :) On Thu, Jan 4, 2018 at 10:34 AM, David Martin wrote: > Hi all, > > This email is moreso a formality so everyone knows how we have been > communicating, but wanted to share so everyone is aware, particular with a > lot of new team members working on 5.x. > However, if you feel strongly against anything here, please lets discuss. > > TLDR; > * Lets default to #aerogear for all chat, discussions etc.. > * Lets use direct messages, email or #mobile-internal for private chat, > discussions etc... > > > Reasons > * #aerogear on freenode is already active with 5.x chat & discussions, and > has been for ~6 months (it's been active a lot longer than that for mobile > things) > * having a central place for chat increases the likelihood of getting help > or feedback, particularly if people across different teams hit the same > issues and have solved it already. It also increases visibility of work > other teams are doing, which can avoid duplication & encourage collaboration > * we are all part of 1 larger team working on the same goal. Lets not > exclude or silo ourselves > * #aerogear is public/open. 5.x development is all upstream/open. Removing > any barriers to building an open community, which we are all the foundation > of, makes sense > > -- > David Martin > Red Hat Mobile > Twitter: @irldavem > IRC: @irldavem (#aerogear) > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- LUIGI ZUCCARELLI Associate MANAGER ENGINEERING , REDHAT MOBILE Red Hat Mobile Communications House Ireland Cork Road Waterford City X91NY33 lzuccare at redhat.com M: +353852156995 IM: lzuccarelli TRIED. TESTED. TRUSTED. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbraun at redhat.com Tue Jan 9 15:13:39 2018 From: pbraun at redhat.com (Peter Braun) Date: Tue, 9 Jan 2018 16:13:39 +0100 Subject: [feedhenry-dev] Fwd: prometheus-apb has been renamed to metrics-apb References: <7D29511A-CCEB-4E90-8676-D49377F7F1CC@redhat.com> Message-ID: <64FC35B6-9B47-426C-BD1A-8963A2E68596@redhat.com> ? forward to feedhenry-dev and aerogear-dev Hi everybody, the prometheus-apb repository has been renamed to metrics-apb (https://github.com/aerogearcatalog/metrics-apb ). If you are working on it please update your fork and remotes. I will also push an updated image under the new name shortly. Regards, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From chfoley at redhat.com Wed Jan 10 11:44:44 2018 From: chfoley at redhat.com (Chris Foley) Date: Wed, 10 Jan 2018 11:44:44 +0000 Subject: [feedhenry-dev] Naming Convention for Mobile Services ? Message-ID: Hi All, I had a brief discussion with John around Naming Conventions and what may be worth putting in place which could be beneficial but not restrictive. I wanted to kick start discussion on this around what may be worthwhile. An important aspect of 5.x is the value add services and getting these in place and discoverable from Mobile Core. Should we be applying some naming convention or mandatory attributes to these services? Attributes / Properties of a Service, e.g. ; ---------------------------------------------- *Display Name*: Push Notifications *id / serviceName*: push *APB Label/Tag*: mobile-service Would it be any benefit if the APB tag (mobile-service) carried over and became a label on the OCP service (e.g. for the Core SDK to read what Mobile Services are available in a namespace)? *APB Integrations*: Some of the above may be agreed already! We should agree on the actual serviceNames (interested to hear the Mobile Service Teams view on what the names should be): Metrics = metrics Push Notifications = push Data Synchronisation = sync Security & Identity Management = keycloak Mobile Build Automation = build API Gateway = gateway Are there other naming aspects which could be worthwhile getting agreement on? Around the SDKs, as they are being designed now, it is probably worth considering also. All opinions welcome. Best Regards, Chris. -- CHRISTOPHER FOLEY BUSINESS SYSTEMS ANALYST, MOBILE Red Hat Ireland Communications House, Cork Road, Waterford City, Ireland X91NY33 chfoley at redhat.com TRIED. TESTED. TRUSTED. -------------- next part -------------- An HTML attachment was scrubbed... URL: From davmarti at redhat.com Wed Jan 10 12:37:11 2018 From: davmarti at redhat.com (David Martin) Date: Wed, 10 Jan 2018 12:37:11 +0000 Subject: [feedhenry-dev] Mobile Statistics using Grafana, Prometheus running on OpenShift In-Reply-To: References: Message-ID: Very nice Wojciech. I'd love to see/hear more about how it works from the Mobile App, if that piece is working. Did you populate stats using the App, or by just curling an endpoint? (Maybe you said and I missed that) On 10 January 2018 at 12:22, Wojciech Trocki wrote: > Forwarding to internal list as AeroGear list seems to be having problems > with mail delivery. > > ---------- Forwarded message ---------- > From: Wojciech Trocki > Date: Tue, Jan 9, 2018 at 7:55 PM > Subject: Mobile Statistics using Grafana, Prometheus running on OpenShift > To: AeroGear Developer Mailing List > > > Hi everyone > > I have been working today on investigation for enabling mobile application > statistics on top of OpenShift. > The main target was to enable mobile clients (using our SDK) to send > statistics payload to server. > For this purpose we were sending back mobile.next() SDK version from > different mobile clients and visualizing that data Grafana. > > *Demo: * > > https://www.youtube.com/watch?v=zC95jJr1kcc > > *Where is the value? * > > Grafana, can be used to showcase various statistics that mobile developers > will need without extended development effort. > > *How we can extend this:* > > - Investigate different ways to store data in Prometheus (using labels > etc.) > - Integrate with Keycloak to showcase SDK capabilities and permissions. > - Golang implementation for service > > Regards > -- > > WOJCIECH TROCKI > > Red Hat Mobile > > IM: wtrocki > > > -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (#aerogear) -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbrookes at redhat.com Wed Jan 10 12:38:12 2018 From: pbrookes at redhat.com (Phil Brookes) Date: Wed, 10 Jan 2018 12:38:12 +0000 Subject: [feedhenry-dev] Fwd: Minishift Mobile Core addon demo In-Reply-To: References: Message-ID: Forwarding to feedhenry-dev and mobile-dev due to technical issues on the aerogear-dev mailing list. ? ---------- Forwarded message ---------- From: Phil Brookes Date: Mon, Jan 8, 2018 at 4:21 PM Subject: Minishift Mobile Core addon demo To: AeroGear Developer Mailing List Hey Everyone, I have built an addon for Minishift which will install the Mobile Core into your Minishift local development cluster. You can see the demo here: https://youtu.be/jSCdw5Lpy6Y And the addon and accompanying readme is in this repo: https://github.com/aerogear/minishift-mobilecore-addon If you have any questions or comments, let me know. Thanks, Phil. -------------- next part -------------- An HTML attachment was scrubbed... URL: From weil at redhat.com Wed Jan 10 12:52:24 2018 From: weil at redhat.com (Wei Li) Date: Wed, 10 Jan 2018 12:52:24 +0000 Subject: [feedhenry-dev] Fwd: Minishift Mobile Core addon demo In-Reply-To: References: Message-ID: Great demo, Phil. This is really cool. Does this mean that we can either use the add-on or the installation script in mobile-core repo to setup the development environment? Is there big difference between the two? On Wed, Jan 10, 2018 at 12:38 PM, Phil Brookes wrote: > Forwarding to feedhenry-dev and mobile-dev due to technical issues on the > aerogear-dev mailing list. > ? > > ---------- Forwarded message ---------- > From: Phil Brookes > Date: Mon, Jan 8, 2018 at 4:21 PM > Subject: Minishift Mobile Core addon demo > To: AeroGear Developer Mailing List > > > Hey Everyone, > > I have built an addon for Minishift which will install the Mobile Core > into your Minishift local development cluster. > > You can see the demo here: > https://youtu.be/jSCdw5Lpy6Y > > And the addon and accompanying readme is in this repo: > https://github.com/aerogear/minishift-mobilecore-addon > > If you have any questions or comments, let me know. > > Thanks, > 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 cbrookes at redhat.com Wed Jan 10 13:04:01 2018 From: cbrookes at redhat.com (Craig Brookes) Date: Wed, 10 Jan 2018 13:04:01 +0000 Subject: [feedhenry-dev] Fwd: Minishift Mobile Core addon demo In-Reply-To: References: Message-ID: @Wei I imagine that you could use the minishift plugin for trying it out and propbaly for developing the CLI against, but not sure if you could use it for developing the UI, Phil might know more though On Wed, Jan 10, 2018 at 12:52 PM, Wei Li wrote: > Great demo, Phil. This is really cool. > > Does this mean that we can either use the add-on or the installation > script in mobile-core repo to setup the development environment? Is there > big difference between the two? > > On Wed, Jan 10, 2018 at 12:38 PM, Phil Brookes > wrote: > >> Forwarding to feedhenry-dev and mobile-dev due to technical issues on the >> aerogear-dev mailing list. >> ? >> >> ---------- Forwarded message ---------- >> From: Phil Brookes >> Date: Mon, Jan 8, 2018 at 4:21 PM >> Subject: Minishift Mobile Core addon demo >> To: AeroGear Developer Mailing List >> >> >> Hey Everyone, >> >> I have built an addon for Minishift which will install the Mobile Core >> into your Minishift local development cluster. >> >> You can see the demo here: >> https://youtu.be/jSCdw5Lpy6Y >> >> And the addon and accompanying readme is in this repo: >> https://github.com/aerogear/minishift-mobilecore-addon >> >> If you have any questions or comments, let me know. >> >> Thanks, >> 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 > > -- Craig Brookes RHMAP @maleck13 Github -------------- next part -------------- An HTML attachment was scrubbed... URL: From asaleh at redhat.com Wed Jan 10 13:10:06 2018 From: asaleh at redhat.com (Adam Saleh) Date: Wed, 10 Jan 2018 14:10:06 +0100 Subject: [feedhenry-dev] Fwd: Minishift Mobile Core addon demo In-Reply-To: References: Message-ID: As far as I understand the purpose for the Minishift addon, it should be mostly for evaluating of the platform, not development of i.e. mobile-core. Minishift wouldn't setup the automatic ui-rebuilding, for example. But if this was our primary evaluation method, it might be interesting to move most of our apb/service development against Minishift. What do you think? Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmacedo at redhat.com Wed Jan 10 14:29:20 2018 From: cmacedo at redhat.com (Camila Macedo) Date: Wed, 10 Jan 2018 14:29:20 +0000 Subject: [feedhenry-dev] Fwd: Minishift Mobile Core addon demo In-Reply-To: References: Message-ID: Hi folks, Really cool :-) *Camila Macedo | Red Hat Mobile* *IRC:* cmacedo Phone: +55 11 3529-6052 *Mobile: *+44 7853500035 [image: Red Hat] On Wed, Jan 10, 2018 at 1:10 PM, Adam Saleh wrote: > As far as I understand the purpose for the Minishift addon, it should be > mostly for evaluating of the platform, not development of i.e. mobile-core. > Minishift wouldn't setup the automatic ui-rebuilding, for example. > > But if this was our primary evaluation method, it might be interesting to > move most of our apb/service development against Minishift. > > What do you think? > > Adam > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wtrocki at redhat.com Wed Jan 10 14:48:38 2018 From: wtrocki at redhat.com (Wojciech Trocki) Date: Wed, 10 Jan 2018 14:48:38 +0000 Subject: [feedhenry-dev] Dropping forks from aerogearcatalog Message-ID: Do you guys think it's possible to remove forks from https://github.com/aerogearcatalog repositories? All repositories are now forked from private account. For example: https://github.com/aerogearcatalog/keycloak-apb is forked from: https://github.com/aidenkeating/keycloak-apb As result of that github it's not indexing them properly. It may be also confusing for community to know what upstream they should target with the changes. Regards -- WOJCIECH TROCKI Red Hat Mobile IM: wtrocki -------------- next part -------------- An HTML attachment was scrubbed... URL: From akeating at redhat.com Wed Jan 10 15:21:48 2018 From: akeating at redhat.com (Aiden Keating) Date: Wed, 10 Jan 2018 15:21:48 +0000 Subject: [feedhenry-dev] Dropping forks from aerogearcatalog In-Reply-To: References: Message-ID: I think this is a really good idea. The fork could be quite confusing at first glance for people. It sort of appears that you're not on the "correct" repo, even though you are. On Wed, Jan 10, 2018 at 2:48 PM, Wojciech Trocki wrote: > Do you guys think it's possible to remove forks from https://github.com/ > aerogearcatalog repositories? > All repositories are now forked from private account. For example: > > https://github.com/aerogearcatalog/keycloak-apb > > is forked from: > > https://github.com/aidenkeating/keycloak-apb > > As result of that github it's not indexing them properly. > It may be also confusing for community to know what upstream they should > target with the changes. > > Regards > -- > > 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 jfrizell at redhat.com Wed Jan 10 16:35:05 2018 From: jfrizell at redhat.com (John Frizelle) Date: Wed, 10 Jan 2018 16:35:05 +0000 Subject: [feedhenry-dev] Mitigating ML problems Message-ID: Hi All, Until such time as we get confirmation that the problems with delivery to the arergrear-dev ML have been fixed (or we migrate from mailman to a public google group for the ML), can I ask that ALL mail sent to the aerogear-dev ML is also sent to the other 2 MLs on this thread - feedhenry-dev and mobile-dev. I know this is a bit of a pain, but it's even more painful to not have mails delivered in a timely fashion. I know there has been suggestions made to move from mailman to Google Groups already, but not sure where these discussions are at... Is there anything preventing us making this jump - the mailman ML problem has been ongoing for quite some time now with no resolution in sight that I am aware of, so perhaps it's time to look at moving to Google Groups? 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 * -------------- 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 Jan 10 16:53:20 2018 From: cbrookes at redhat.com (Craig Brookes) Date: Wed, 10 Jan 2018 16:53:20 +0000 Subject: [feedhenry-dev] Mitigating ML problems In-Reply-To: References: Message-ID: Have no strong opinions on this whatever works is ok with me On Wed, Jan 10, 2018 at 4:35 PM, John Frizelle wrote: > Hi All, > > Until such time as we get confirmation that the problems with delivery to > the arergrear-dev ML have been fixed (or we migrate from mailman to a > public google group for the ML), can I ask that ALL mail sent to the > aerogear-dev ML is also sent to the other 2 MLs on this thread - > feedhenry-dev and mobile-dev. > > I know this is a bit of a pain, but it's even more painful to not have > mails delivered in a timely fashion. > > I know there has been suggestions made to move from mailman to Google > Groups already, but not sure where these discussions are at... Is there > anything preventing us making this jump - the mailman ML problem has been > ongoing for quite some time now with no resolution in sight that I am aware > of, so perhaps it's time to look at moving to Google Groups? > > 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 * > > > > -- Craig Brookes RHMAP @maleck13 Github -------------- 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 Wed Jan 10 17:44:58 2018 From: pwright at redhat.com (Paul Wright) Date: Wed, 10 Jan 2018 17:44:58 +0000 Subject: [feedhenry-dev] Proposal: Use Asciibinder for docs on aerogear.org In-Reply-To: <97ecaf5f-a312-3600-b486-3c10c75f28ea@redhat.com> References: <97ecaf5f-a312-3600-b486-3c10c75f28ea@redhat.com> Message-ID: Hi, In following up on my proposal (below), I met with Brian B (OSAS) today. He describes migrating the fedora docs to asciibinder, recording available from: https://bluejeans.com/s/yhmI1 On Fri, Jan 5, 2018 at 1:29 PM, Paul Wright wrote: > See https://github.com/finp/proposals/blob/470c9dc145e12e7baa2a49d5b8ddf5 > f1b946310b/aerogear-docs.adoc > > *PR at:* > > https://github.com/aerogear/proposals/pull/7 > > > -- > Paul Wright > Mobile Docs (github: finp) > > -- Paul Wright Senior Technical Writer Red Hat, Waterford, Ireland gitlab: finp -------------- next part -------------- An HTML attachment was scrubbed... URL: From wtrocki at redhat.com Wed Jan 10 18:05:42 2018 From: wtrocki at redhat.com (Wojciech Trocki) Date: Wed, 10 Jan 2018 18:05:42 +0000 Subject: [feedhenry-dev] Mitigating ML problems In-Reply-To: References: Message-ID: We can create google groups account and trail that for a while along with aerogear-dev by suppling both addresses. https://groups.google.com/a/redhat.com/forum/#!overview Possible problem with migration is that we may need to decide if we want to migrate some of the existing emails to this group. Additional risk is that google can retire this service but that is unlikely to happen. IMHO if we make this decision best to do it as soon as possible before we will have a lots of mobile.next emails on aerogear-dev group. On Wed, Jan 10, 2018 at 4:53 PM, Craig Brookes wrote: > Have no strong opinions on this whatever works is ok with me > > On Wed, Jan 10, 2018 at 4:35 PM, John Frizelle > wrote: > >> Hi All, >> >> Until such time as we get confirmation that the problems with delivery to >> the arergrear-dev ML have been fixed (or we migrate from mailman to a >> public google group for the ML), can I ask that ALL mail sent to the >> aerogear-dev ML is also sent to the other 2 MLs on this thread - >> feedhenry-dev and mobile-dev. >> >> I know this is a bit of a pain, but it's even more painful to not have >> mails delivered in a timely fashion. >> >> I know there has been suggestions made to move from mailman to Google >> Groups already, but not sure where these discussions are at... Is there >> anything preventing us making this jump - the mailman ML problem has been >> ongoing for quite some time now with no resolution in sight that I am aware >> of, so perhaps it's time to look at moving to Google Groups? >> >> 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 * >> >> >> >> > > > -- > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 11472 bytes Desc: not available URL: From eshortis at redhat.com Wed Jan 10 20:33:09 2018 From: eshortis at redhat.com (Evan Shortiss) Date: Wed, 10 Jan 2018 12:33:09 -0800 Subject: [feedhenry-dev] Fwd: Minishift Mobile Core addon demo In-Reply-To: References: Message-ID: This is awesome. Forgive my ignorance, but what Docker org should be used? Is it an RHMAP or AeroGear org, or something different? On Wed, Jan 10, 2018 at 6:29 AM, Camila Macedo wrote: > Hi folks, > > Really cool :-) > > *Camila Macedo | Red Hat Mobile* > *IRC:* cmacedo > Phone: +55 11 3529-6052 <+55%2011%203529-6052> > *Mobile: *+44 7853500035 <+44%207853%20500035> > [image: Red Hat] > > On Wed, Jan 10, 2018 at 1:10 PM, Adam Saleh wrote: > >> As far as I understand the purpose for the Minishift addon, it should be >> mostly for evaluating of the platform, not development of i.e. mobile-core. >> Minishift wouldn't setup the automatic ui-rebuilding, for example. >> >> But if this was our primary evaluation method, it might be interesting to >> move most of our apb/service development against Minishift. >> >> What do you think? >> >> Adam >> > > -- 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 cbrookes at redhat.com Wed Jan 10 20:35:35 2018 From: cbrookes at redhat.com (cbrookes at redhat.com) Date: Wed, 10 Jan 2018 20:35:35 +0000 Subject: [feedhenry-dev] Fwd: Minishift Mobile Core addon demo In-Reply-To: References: Message-ID: <51922E36-DE66-4B85-A97A-CB82D35AA6F8@redhat.com> aerogearcatalog Craig > On 10 Jan 2018, at 20:33, Evan Shortiss wrote: > > This is awesome. Forgive my ignorance, but what Docker org should be used? Is it an RHMAP or AeroGear org, or something different? > >> On Wed, Jan 10, 2018 at 6:29 AM, Camila Macedo wrote: >> Hi folks, >> >> Really cool :-) >> >> Camila Macedo | Red Hat Mobile >> IRC: cmacedo >> Phone: +55 11 3529-6052 >> Mobile: +44 7853500035 >> >> >>> On Wed, Jan 10, 2018 at 1:10 PM, Adam Saleh wrote: >>> As far as I understand the purpose for the Minishift addon, it should be mostly for evaluating of the platform, not development of i.e. mobile-core. >>> Minishift wouldn't setup the automatic ui-rebuilding, for example. >>> >>> But if this was our primary evaluation method, it might be interesting to move most of our apb/service development against Minishift. >>> >>> What do you think? >>> >>> Adam >> > > > > -- > 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 weil at redhat.com Wed Jan 10 20:53:16 2018 From: weil at redhat.com (Wei Li) Date: Wed, 10 Jan 2018 20:53:16 +0000 Subject: [feedhenry-dev] Dropping forks from aerogearcatalog In-Reply-To: References: Message-ID: +1 On Wed, Jan 10, 2018 at 3:21 PM, Aiden Keating wrote: > I think this is a really good idea. > > The fork could be quite confusing at first glance for people. > > It sort of appears that you're not on the "correct" repo, even though you > are. > > On Wed, Jan 10, 2018 at 2:48 PM, Wojciech Trocki > wrote: > >> Do you guys think it's possible to remove forks from >> https://github.com/aerogearcatalog repositories? >> All repositories are now forked from private account. For example: >> >> https://github.com/aerogearcatalog/keycloak-apb >> >> is forked from: >> >> https://github.com/aidenkeating/keycloak-apb >> >> As result of that github it's not indexing them properly. >> It may be also confusing for community to know what upstream they should >> target with the changes. >> >> Regards >> -- >> >> 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 > > -- WEI LI SENIOR SOFTWARE ENGINEER Red Hat Mobile weil at redhat.com M: +353862393272 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wtrocki at redhat.com Wed Jan 10 21:01:16 2018 From: wtrocki at redhat.com (Wojciech Trocki) Date: Wed, 10 Jan 2018 21:01:16 +0000 Subject: [feedhenry-dev] Dropping forks from aerogearcatalog In-Reply-To: References: Message-ID: Easiest way to remove forks will be to remove all upstream repositories. I have tested that on sample repository. After removing upstream all downstream repositories will no longer be there as forked. Indexing works as well. We can test that with https://github.com/aerogearcatalog/keycloak-apb On Wed, Jan 10, 2018 at 8:53 PM, Wei Li wrote: > +1 > > On Wed, Jan 10, 2018 at 3:21 PM, Aiden Keating > wrote: > >> I think this is a really good idea. >> >> The fork could be quite confusing at first glance for people. >> >> It sort of appears that you're not on the "correct" repo, even though >> you are. >> >> On Wed, Jan 10, 2018 at 2:48 PM, Wojciech Trocki >> wrote: >> >>> Do you guys think it's possible to remove forks from >>> https://github.com/aerogearcatalog repositories? >>> All repositories are now forked from private account. For example: >>> >>> https://github.com/aerogearcatalog/keycloak-apb >>> >>> is forked from: >>> >>> https://github.com/aidenkeating/keycloak-apb >>> >>> As result of that github it's not indexing them properly. >>> It may be also confusing for community to know what upstream they should >>> target with the changes. >>> >>> Regards >>> -- >>> >>> 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 >> >> > > > -- > > WEI LI > > SENIOR SOFTWARE ENGINEER > > Red Hat Mobile > > weil at redhat.com M: +353862393272 > > -- WOJCIECH TROCKI Red Hat Mobile IM: wtrocki -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Thu Jan 11 07:33:36 2018 From: mwessend at redhat.com (Matthias Wessendorf) Date: Thu, 11 Jan 2018 07:33:36 +0000 Subject: [feedhenry-dev] Dropping forks from aerogearcatalog In-Reply-To: References: Message-ID: +1 On Wed 10. Jan 2018 at 22:02, Wojciech Trocki wrote: > Easiest way to remove forks will be to remove all upstream repositories. > I have tested that on sample repository. > > After removing upstream all downstream repositories will no longer be > there as forked. > Indexing works as well. > We can test that with https://github.com/aerogearcatalog/keycloak-apb > > On Wed, Jan 10, 2018 at 8:53 PM, Wei Li wrote: > >> +1 >> >> On Wed, Jan 10, 2018 at 3:21 PM, Aiden Keating >> wrote: >> >>> I think this is a really good idea. >>> >>> The fork could be quite confusing at first glance for people. >>> >>> It sort of appears that you're not on the "correct" repo, even though >>> you are. >>> >>> On Wed, Jan 10, 2018 at 2:48 PM, Wojciech Trocki >>> wrote: >>> >>>> Do you guys think it's possible to remove forks from >>>> https://github.com/aerogearcatalog repositories? >>>> All repositories are now forked from private account. For example: >>>> >>>> https://github.com/aerogearcatalog/keycloak-apb >>>> >>>> is forked from: >>>> >>>> https://github.com/aidenkeating/keycloak-apb >>>> >>>> As result of that github it's not indexing them properly. >>>> It may be also confusing for community to know what upstream they >>>> should target with the changes. >>>> >>>> Regards >>>> -- >>>> >>>> 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 >>> >>> >> >> >> -- >> >> WEI LI >> >> SENIOR SOFTWARE ENGINEER >> >> Red Hat Mobile >> >> weil at redhat.com M: +353862393272 >> >> > > > > -- > > WOJCIECH TROCKI > > Red Hat Mobile > > IM: wtrocki > > _______________________________________________ > 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 Thu Jan 11 07:43:18 2018 From: mwessend at redhat.com (Matthias Wessendorf) Date: Thu, 11 Jan 2018 07:43:18 +0000 Subject: [feedhenry-dev] Naming Convention for Mobile Services ? In-Reply-To: References: Message-ID: On Wed 10. Jan 2018 at 12:45, Chris Foley wrote: > Hi All, > > I had a brief discussion with John around Naming Conventions and what may > be worth putting in place which could be beneficial but not restrictive. I > wanted to kick start discussion on this around what may be worthwhile. > > An important aspect of 5.x is the value add services and getting these in > place and discoverable from Mobile Core. Should we be applying some naming > convention or mandatory attributes to these services? > > Attributes / Properties of a Service, e.g. ; > ---------------------------------------------- > *Display Name*: Push Notifications > *id / serviceName*: push > *APB Label/Tag*: mobile-service > Would it be any benefit if the APB tag (mobile-service) carried over and > became a label on the OCP service (e.g. for the Core SDK to read what > Mobile Services are available in a namespace)? > *APB Integrations*: integrates with> > > Some of the above may be agreed already! > > We should agree on the actual serviceNames (interested to hear the Mobile > Service Teams view on what the names should be): > Metrics = metrics > Push Notifications = push > Data Synchronisation = sync > Security & Identity Management = keycloak > Mobile Build Automation = build > API Gateway = gateway > +1 they are short and easy (in contrast to previous fh-sync(-server) > Are there other naming aspects which could be worthwhile getting agreement > on? Around the SDKs, as they are being designed now, it is probably worth > considering also. > > All opinions welcome. > > Best Regards, > Chris. > -- > > CHRISTOPHER FOLEY > > BUSINESS SYSTEMS ANALYST, MOBILE > > Red Hat Ireland > > Communications House, Cork Road, > > Waterford City, Ireland X91NY33 > > chfoley at redhat.com > > TRIED. TESTED. TRUSTED. > _______________________________________________ > 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 Thu Jan 11 08:27:37 2018 From: mwessend at redhat.com (Matthias Wessendorf) Date: Thu, 11 Jan 2018 09:27:37 +0100 Subject: [feedhenry-dev] Naming Convention for Mobile Services ? In-Reply-To: References: Message-ID: hey chris, the aerogear list address is "aerogear-dev at lists.jboss.org" not @redhat On Wed, Jan 10, 2018 at 12:44 PM, Chris Foley wrote: > Hi All, > > I had a brief discussion with John around Naming Conventions and what may > be worth putting in place which could be beneficial but not restrictive. I > wanted to kick start discussion on this around what may be worthwhile. > > An important aspect of 5.x is the value add services and getting these in > place and discoverable from Mobile Core. Should we be applying some naming > convention or mandatory attributes to these services? > > Attributes / Properties of a Service, e.g. ; > ---------------------------------------------- > *Display Name*: Push Notifications > *id / serviceName*: push > *APB Label/Tag*: mobile-service > Would it be any benefit if the APB tag (mobile-service) carried over and > became a label on the OCP service (e.g. for the Core SDK to read what > Mobile Services are available in a namespace)? > *APB Integrations*: integrates with> > > Some of the above may be agreed already! > > We should agree on the actual serviceNames (interested to hear the Mobile > Service Teams view on what the names should be): > Metrics = metrics > Push Notifications = push > Data Synchronisation = sync > Security & Identity Management = keycloak > Mobile Build Automation = build > API Gateway = gateway > > Are there other naming aspects which could be worthwhile getting agreement > on? Around the SDKs, as they are being designed now, it is probably worth > considering also. > > All opinions welcome. > > Best Regards, > Chris. > -- > > CHRISTOPHER FOLEY > > BUSINESS SYSTEMS ANALYST, MOBILE > > Red Hat Ireland > > Communications House, Cork Road, > > Waterford City, Ireland X91NY33 > > chfoley at redhat.com > > TRIED. TESTED. TRUSTED. > > _______________________________________________ > 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 pbraun at redhat.com Thu Jan 11 09:30:51 2018 From: pbraun at redhat.com (Peter Braun) Date: Thu, 11 Jan 2018 10:30:51 +0100 Subject: [feedhenry-dev] Minishift Mobile Core addon demo In-Reply-To: References: Message-ID: That?s awesome! I think there are a ton of uses for Minishift, e.g. giving non-dev users an introduction to the platform, Tutorials and courses on Aerogear etc. > Am 10.01.2018 um 13:38 schrieb Phil Brookes : > > Forwarding to feedhenry-dev and mobile-dev due to technical issues on the aerogear-dev mailing list. > > > ---------- Forwarded message ---------- > From: Phil Brookes > > Date: Mon, Jan 8, 2018 at 4:21 PM > Subject: Minishift Mobile Core addon demo > To: AeroGear Developer Mailing List > > > > Hey Everyone, > > I have built an addon for Minishift which will install the Mobile Core into your Minishift local development cluster. > > You can see the demo here: > https://youtu.be/jSCdw5Lpy6Y > > And the addon and accompanying readme is in this repo: > https://github.com/aerogear/minishift-mobilecore-addon > > If you have any questions or comments, let me know. > > Thanks, > Phil. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwright at redhat.com Thu Jan 11 09:35:35 2018 From: pwright at redhat.com (Paul Wright) Date: Thu, 11 Jan 2018 09:35:35 +0000 Subject: [feedhenry-dev] Naming Convention for Mobile Services ? In-Reply-To: References: Message-ID: <5826bd41-e2b2-297d-958d-e5946399b275@redhat.com> Hi Chris, thanks for starting this discussion, can I object to one item: > Security & Identity Management = keycloak because this is likely to end up in downstream documentation, we should avoid names of upstream projects. In this case I hope we can use something like 'identity' instead? Paul On 01/10/2018 11:44 AM, Chris Foley wrote: > Hi All, > > I had a brief discussion with John around Naming Conventions and what > may be worth putting in place which could be beneficial but not > restrictive. I wanted to kick start discussion on this around what may > be worthwhile. > > An important aspect of 5.x is the value add services and getting these > in place and discoverable from Mobile Core. Should we be applying some > naming convention or mandatory attributes to these services? > > Attributes / Properties of a Service, e.g. ; > ---------------------------------------------- > *Display Name*: Push Notifications > *id / serviceName*: push > *APB Label/Tag*: mobile-service > Would it be any benefit if the APB tag (mobile-service) carried over > and became a label on the OCP service (e.g. for the Core SDK to read > what Mobile Services are available in a namespace)? > *APB Integrations*: integrates with> > > Some of the above may be agreed already! > > We should agree on the actual serviceNames (interested to hear the > Mobile Service Teams view on what the names should be): > Metrics = metrics > Push Notifications = push > Data Synchronisation = sync > Security & Identity Management = keycloak > Mobile Build Automation = build > API Gateway = gateway > > Are there other naming aspects which could be worthwhile getting > agreement on? Around the SDKs, as they are being designed now, it is > probably worth considering also. > > All opinions welcome. > > Best Regards, > Chris. > -- > > CHRISTOPHER FOLEY > > BUSINESS SYSTEMS ANALYST, MOBILE > > Red Hat Ireland > > Communications House, Cork Road, > > Waterford City, Ireland X91NY33 > > chfoley at redhat.com > > > TRIED. TESTED. TRUSTED. > > > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev -- Paul Wright Mobile Docs (github: finp) -------------- next part -------------- An HTML attachment was scrubbed... URL: From supittma at redhat.com Thu Jan 11 12:21:34 2018 From: supittma at redhat.com (Summers Pittman) Date: Thu, 11 Jan 2018 07:21:34 -0500 Subject: [feedhenry-dev] Dropping forks from aerogearcatalog In-Reply-To: References: Message-ID: +1. I think forking is generally better than making a branch in the main repo for projects with many contributors as well. On Thu, Jan 11, 2018 at 2:33 AM, Matthias Wessendorf wrote: > +1 > > On Wed 10. Jan 2018 at 22:02, Wojciech Trocki wrote: > >> Easiest way to remove forks will be to remove all upstream repositories. >> I have tested that on sample repository. >> >> After removing upstream all downstream repositories will no longer be >> there as forked. >> Indexing works as well. >> We can test that with https://github.com/aerogearcatalog/keycloak-apb >> >> On Wed, Jan 10, 2018 at 8:53 PM, Wei Li wrote: >> >>> +1 >>> >>> On Wed, Jan 10, 2018 at 3:21 PM, Aiden Keating >>> wrote: >>> >>>> I think this is a really good idea. >>>> >>>> The fork could be quite confusing at first glance for people. >>>> >>>> It sort of appears that you're not on the "correct" repo, even though >>>> you are. >>>> >>>> On Wed, Jan 10, 2018 at 2:48 PM, Wojciech Trocki >>>> wrote: >>>> >>>>> Do you guys think it's possible to remove forks from >>>>> https://github.com/aerogearcatalog repositories? >>>>> All repositories are now forked from private account. For example: >>>>> >>>>> https://github.com/aerogearcatalog/keycloak-apb >>>>> >>>>> is forked from: >>>>> >>>>> https://github.com/aidenkeating/keycloak-apb >>>>> >>>>> As result of that github it's not indexing them properly. >>>>> It may be also confusing for community to know what upstream they >>>>> should target with the changes. >>>>> >>>>> Regards >>>>> -- >>>>> >>>>> 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 >>>> >>>> >>> >>> >>> -- >>> >>> WEI LI >>> >>> SENIOR SOFTWARE ENGINEER >>> >>> Red Hat Mobile >>> >>> weil at redhat.com M: +353862393272 >>> >>> >> >> >> >> -- >> >> WOJCIECH TROCKI >> >> Red Hat Mobile >> >> IM: wtrocki >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> > -- > 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 jfrizell at redhat.com Thu Jan 11 14:28:00 2018 From: jfrizell at redhat.com (John Frizelle) Date: Thu, 11 Jan 2018 14:28:00 +0000 Subject: [feedhenry-dev] Naming Convention for Mobile Services ? In-Reply-To: <5826bd41-e2b2-297d-958d-e5946399b275@redhat.com> References: <5826bd41-e2b2-297d-958d-e5946399b275@redhat.com> Message-ID: Agree that "Security & Identity Management" should not be "keycloak" Suggest we use "auth" or "security" instead. @Joe - I would hope that we could come up with names that work both upstream and downstream. Which ones would you have questions/concerns about? -- 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 11 January 2018 at 09:35, Paul Wright wrote: > Hi Chris, > > thanks for starting this discussion, can I object to one item: > > Security & Identity Management = keycloak > > because this is likely to end up in downstream documentation, we should > avoid names of upstream projects. In this case I hope we can use something > like 'identity' instead? > > Paul > > On 01/10/2018 11:44 AM, Chris Foley wrote: > > Hi All, > > I had a brief discussion with John around Naming Conventions and what may > be worth putting in place which could be beneficial but not restrictive. I > wanted to kick start discussion on this around what may be worthwhile. > > An important aspect of 5.x is the value add services and getting these in > place and discoverable from Mobile Core. Should we be applying some naming > convention or mandatory attributes to these services? > > Attributes / Properties of a Service, e.g. ; > ---------------------------------------------- > *Display Name*: Push Notifications > *id / serviceName*: push > *APB Label/Tag*: mobile-service > Would it be any benefit if the APB tag (mobile-service) carried over and > became a label on the OCP service (e.g. for the Core SDK to read what > Mobile Services are available in a namespace)? > *APB Integrations*: integrates with> > > Some of the above may be agreed already! > > We should agree on the actual serviceNames (interested to hear the Mobile > Service Teams view on what the names should be): > Metrics = metrics > Push Notifications = push > Data Synchronisation = sync > Security & Identity Management = keycloak > Mobile Build Automation = build > API Gateway = gateway > > Are there other naming aspects which could be worthwhile getting agreement > on? Around the SDKs, as they are being designed now, it is probably worth > considering also. > > All opinions welcome. > > Best Regards, > Chris. > -- > > CHRISTOPHER FOLEY > > BUSINESS SYSTEMS ANALYST, MOBILE > > Red Hat Ireland > > Communications House, Cork Road, > > Waterford City, Ireland X91NY33 > > chfoley at redhat.com > > TRIED. TESTED. TRUSTED. > > > _______________________________________________ > feedhenry-dev mailing listfeedhenry-dev at redhat.comhttps://www.redhat.com/mailman/listinfo/feedhenry-dev > > > -- > Paul Wright > Mobile Docs (github: finp) > > > _______________________________________________ > 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 eshortis at redhat.com Thu Jan 11 17:00:23 2018 From: eshortis at redhat.com (Evan Shortiss) Date: Thu, 11 Jan 2018 09:00:23 -0800 Subject: [feedhenry-dev] Fwd: Minishift Mobile Core addon demo In-Reply-To: <51922E36-DE66-4B85-A97A-CB82D35AA6F8@redhat.com> References: <51922E36-DE66-4B85-A97A-CB82D35AA6F8@redhat.com> Message-ID: Thanks! On Wed, Jan 10, 2018 at 12:35 PM, cbrookes at redhat.com wrote: > aerogearcatalog > > Craig > > On 10 Jan 2018, at 20:33, Evan Shortiss wrote: > > This is awesome. Forgive my ignorance, but what Docker org should be used? > Is it an RHMAP or AeroGear org, or something different? > > On Wed, Jan 10, 2018 at 6:29 AM, Camila Macedo wrote: > >> Hi folks, >> >> Really cool :-) >> >> *Camila Macedo | Red Hat Mobile* >> *IRC:* cmacedo >> Phone: +55 11 3529-6052 <+55%2011%203529-6052> >> *Mobile: *+44 7853500035 <+44%207853%20500035> >> [image: Red Hat] >> >> On Wed, Jan 10, 2018 at 1:10 PM, Adam Saleh wrote: >> >>> As far as I understand the purpose for the Minishift addon, it should be >>> mostly for evaluating of the platform, not development of i.e. mobile-core. >>> Minishift wouldn't setup the automatic ui-rebuilding, for example. >>> >>> But if this was our primary evaluation method, it might be interesting >>> to move most of our apb/service development against Minishift. >>> >>> What do you think? >>> >>> Adam >>> >> >> > > > -- > > 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 > > > -- 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 weil at redhat.com Thu Jan 11 20:58:13 2018 From: weil at redhat.com (Wei Li) Date: Thu, 11 Jan 2018 20:58:13 +0000 Subject: [feedhenry-dev] Naming Convention for Mobile Services ? In-Reply-To: References: <5826bd41-e2b2-297d-958d-e5946399b275@redhat.com> Message-ID: +1. I prefer `auth` as `security` is too vague. On Thu, Jan 11, 2018 at 2:28 PM, John Frizelle wrote: > Agree that "Security & Identity Management" should not be "keycloak" > > Suggest we use "auth" or "security" instead. > > @Joe - I would hope that we could come up with names that work both > upstream and downstream. Which ones would you have questions/concerns about? > > -- > 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 11 January 2018 at 09:35, Paul Wright wrote: > >> Hi Chris, >> >> thanks for starting this discussion, can I object to one item: >> >> Security & Identity Management = keycloak >> >> because this is likely to end up in downstream documentation, we should >> avoid names of upstream projects. In this case I hope we can use something >> like 'identity' instead? >> >> Paul >> >> On 01/10/2018 11:44 AM, Chris Foley wrote: >> >> Hi All, >> >> I had a brief discussion with John around Naming Conventions and what may >> be worth putting in place which could be beneficial but not restrictive. I >> wanted to kick start discussion on this around what may be worthwhile. >> >> An important aspect of 5.x is the value add services and getting these in >> place and discoverable from Mobile Core. Should we be applying some naming >> convention or mandatory attributes to these services? >> >> Attributes / Properties of a Service, e.g. ; >> ---------------------------------------------- >> *Display Name*: Push Notifications >> *id / serviceName*: push >> *APB Label/Tag*: mobile-service >> Would it be any benefit if the APB tag (mobile-service) carried over and >> became a label on the OCP service (e.g. for the Core SDK to read what >> Mobile Services are available in a namespace)? >> *APB Integrations*: > integrates with> >> >> Some of the above may be agreed already! >> >> We should agree on the actual serviceNames (interested to hear the Mobile >> Service Teams view on what the names should be): >> Metrics = metrics >> Push Notifications = push >> Data Synchronisation = sync >> Security & Identity Management = keycloak >> Mobile Build Automation = build >> API Gateway = gateway >> >> Are there other naming aspects which could be worthwhile getting >> agreement on? Around the SDKs, as they are being designed now, it is >> probably worth considering also. >> >> All opinions welcome. >> >> Best Regards, >> Chris. >> -- >> >> CHRISTOPHER FOLEY >> >> BUSINESS SYSTEMS ANALYST, MOBILE >> >> Red Hat Ireland >> >> Communications House, Cork Road, >> >> Waterford City, Ireland X91NY33 >> >> chfoley at redhat.com >> >> TRIED. TESTED. TRUSTED. >> >> >> _______________________________________________ >> feedhenry-dev mailing listfeedhenry-dev at redhat.comhttps://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> >> -- >> Paul Wright >> Mobile Docs (github: finp) >> >> >> _______________________________________________ >> 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 matzew at apache.org Fri Jan 12 06:51:47 2018 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 12 Jan 2018 07:51:47 +0100 Subject: [feedhenry-dev] [aerogear-dev] Mitigating ML problems In-Reply-To: References: Message-ID: I am perfectly fine w/ moving toward google groups On Wed, Jan 10, 2018 at 5:35 PM, John Frizelle wrote: > Hi All, > > Until such time as we get confirmation that the problems with delivery to > the arergrear-dev ML have been fixed (or we migrate from mailman to a > public google group for the ML), can I ask that ALL mail sent to the > aerogear-dev ML is also sent to the other 2 MLs on this thread - > feedhenry-dev and mobile-dev. > > I know this is a bit of a pain, but it's even more painful to not have > mails delivered in a timely fashion. > > I know there has been suggestions made to move from mailman to Google > Groups already, but not sure where these discussions are at... Is there > anything preventing us making this jump - the mailman ML problem has been > ongoing for quite some time now with no resolution in sight that I am aware > of, so perhaps it's time to look at moving to Google Groups? > > 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 * > > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf github: https://github.com/matzew 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 pbrookes at redhat.com Fri Jan 12 10:26:27 2018 From: pbrookes at redhat.com (Phil Brookes) Date: Fri, 12 Jan 2018 10:26:27 +0000 Subject: [feedhenry-dev] Proposal for addition of --mobile flag to oc cluster up Message-ID: Hey Everyone, I have opened a proposal with the OpenShift team, hoping to start a discussion around the addition of a --mobile=true flag to the oc cluster up command. Running oc cluster up --mobile=true will start a local OpenShift cluster with all of the MCP features enabled. This would be a great way for us to gain some exposure for the Mobile Core and get it into the hands of developers more quickly and easily, so I?d love to see you share your thoughts on this idea. You can review / comment / support it here: https://github.com/openshift/origin/issues/18089 Thanks, Phil. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Fri Jan 12 10:36:20 2018 From: mwessend at redhat.com (Matthias Wessendorf) Date: Fri, 12 Jan 2018 11:36:20 +0100 Subject: [feedhenry-dev] Proposal for addition of --mobile flag to oc cluster up In-Reply-To: References: Message-ID: +9001 On Fri, Jan 12, 2018 at 11:26 AM, Phil Brookes wrote: > Hey Everyone, > > I have opened a proposal with the OpenShift team, hoping to start a > discussion around the addition of a --mobile=true flag to the oc cluster > up command. Running oc cluster up --mobile=true will start a local > OpenShift cluster with all of the MCP features enabled. > > This would be a great way for us to gain some exposure for the Mobile Core > and get it into the hands of developers more quickly and easily, so I?d > love to see you share your thoughts on this idea. You can review / comment > / support it here: > https://github.com/openshift/origin/issues/18089 > > Thanks, > Phil. > ? > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From aliok at redhat.com Fri Jan 12 10:51:38 2018 From: aliok at redhat.com (Ali Ok) Date: Fri, 12 Jan 2018 13:51:38 +0300 Subject: [feedhenry-dev] Demo: Prometheus auto discovery Message-ID: Hi, I created a video, demonstrating Prometheus auto discovery that is configured in metrics-apb[1]: https://www.youtube.com/watch?v=AC_Xet-B1fY This video is an educational video that doesn't use FH-Sync or any other FH-service as the metrics target. Instead, I wrote a very simple lightweight node application [2] that serves the purpose of experimenting with Prometheus on OpenShift better. This video is something I prepared very quickly in addition to the video that will be made soon featuring the metrics solution [3]. [1]: https://github.com/aerogearcatalog/metrics-apb [2]: https://github.com/aliok/node-app-with-prometheus-metrics [3]: https://issues.jboss.org/browse/AEROGEAR-1797 Cheers, Ali -------------- next part -------------- An HTML attachment was scrubbed... URL: From dffrench at redhat.com Fri Jan 12 10:51:42 2018 From: dffrench at redhat.com (David Ffrench) Date: Fri, 12 Jan 2018 10:51:42 +0000 Subject: [feedhenry-dev] Proposal for addition of --mobile flag to oc cluster up In-Reply-To: References: Message-ID: Fantastic Phil, This is 100% needed in my opinion. The mobile services need to be a first class citizen in OpenShift to ensure easy setup and adoption. DAVID FFRENCH senior software engineer, RED HAT MOBILE Red Hat Waterford Communications House, Cork Road Waterford, Ireland dffrench at redhat.com On Fri, Jan 12, 2018 at 10:36 AM, Matthias Wessendorf wrote: > +9001 > > On Fri, Jan 12, 2018 at 11:26 AM, Phil Brookes > wrote: > >> Hey Everyone, >> >> I have opened a proposal with the OpenShift team, hoping to start a >> discussion around the addition of a --mobile=true flag to the oc cluster >> up command. Running oc cluster up --mobile=true will start a local >> OpenShift cluster with all of the MCP features enabled. >> >> This would be a great way for us to gain some exposure for the Mobile >> Core and get it into the hands of developers more quickly and easily, so >> I?d love to see you share your thoughts on this idea. You can review / >> comment / support it here: >> https://github.com/openshift/origin/issues/18089 >> >> Thanks, >> Phil. >> ? >> > > > > -- > Project lead AeroGear.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mziccard at redhat.com Fri Jan 12 11:02:11 2018 From: mziccard at redhat.com (Massimiliano Ziccardi) Date: Fri, 12 Jan 2018 12:02:11 +0100 Subject: [feedhenry-dev] Naming Convention for Mobile Services ? In-Reply-To: References: <5826bd41-e2b2-297d-958d-e5946399b275@redhat.com> Message-ID: Agree with Wei for `auth` instead of `keycloak` or `security` On Thu, Jan 11, 2018 at 9:58 PM, Wei Li wrote: > +1. I prefer `auth` as `security` is too vague. > > On Thu, Jan 11, 2018 at 2:28 PM, John Frizelle > wrote: > >> Agree that "Security & Identity Management" should not be "keycloak" >> >> Suggest we use "auth" or "security" instead. >> >> @Joe - I would hope that we could come up with names that work both >> upstream and downstream. Which ones would you have questions/concerns about? >> >> -- >> 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 11 January 2018 at 09:35, Paul Wright wrote: >> >>> Hi Chris, >>> >>> thanks for starting this discussion, can I object to one item: >>> >>> Security & Identity Management = keycloak >>> >>> because this is likely to end up in downstream documentation, we should >>> avoid names of upstream projects. In this case I hope we can use something >>> like 'identity' instead? >>> >>> Paul >>> >>> On 01/10/2018 11:44 AM, Chris Foley wrote: >>> >>> Hi All, >>> >>> I had a brief discussion with John around Naming Conventions and what >>> may be worth putting in place which could be beneficial but not >>> restrictive. I wanted to kick start discussion on this around what may be >>> worthwhile. >>> >>> An important aspect of 5.x is the value add services and getting these >>> in place and discoverable from Mobile Core. Should we be applying some >>> naming convention or mandatory attributes to these services? >>> >>> Attributes / Properties of a Service, e.g. ; >>> ---------------------------------------------- >>> *Display Name*: Push Notifications >>> *id / serviceName*: push >>> *APB Label/Tag*: mobile-service >>> Would it be any benefit if the APB tag (mobile-service) carried over and >>> became a label on the OCP service (e.g. for the Core SDK to read what >>> Mobile Services are available in a namespace)? >>> *APB Integrations*: >> integrates with> >>> >>> Some of the above may be agreed already! >>> >>> We should agree on the actual serviceNames (interested to hear the >>> Mobile Service Teams view on what the names should be): >>> Metrics = metrics >>> Push Notifications = push >>> Data Synchronisation = sync >>> Security & Identity Management = keycloak >>> Mobile Build Automation = build >>> API Gateway = gateway >>> >>> Are there other naming aspects which could be worthwhile getting >>> agreement on? Around the SDKs, as they are being designed now, it is >>> probably worth considering also. >>> >>> All opinions welcome. >>> >>> Best Regards, >>> Chris. >>> -- >>> >>> CHRISTOPHER FOLEY >>> >>> BUSINESS SYSTEMS ANALYST, MOBILE >>> >>> Red Hat Ireland >>> >>> Communications House, Cork Road, >>> >>> Waterford City, Ireland X91NY33 >>> >>> chfoley at redhat.com >>> >>> TRIED. TESTED. TRUSTED. >>> >>> >>> _______________________________________________ >>> feedhenry-dev mailing listfeedhenry-dev at redhat.comhttps://www.redhat.com/mailman/listinfo/feedhenry-dev >>> >>> >>> -- >>> Paul Wright >>> Mobile Docs (github: finp) >>> >>> >>> _______________________________________________ >>> 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 > > -------------- 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 Fri Jan 12 11:08:57 2018 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 12 Jan 2018 12:08:57 +0100 Subject: [feedhenry-dev] [aerogear-dev] Demo: Prometheus auto discovery In-Reply-To: References: Message-ID: nice ! On Fri, Jan 12, 2018 at 11:51 AM, Ali Ok wrote: > Hi, > > I created a video, demonstrating Prometheus auto discovery that is > configured in metrics-apb[1]: https://www.youtube.com/watch?v=AC_Xet-B1fY > > This video is an educational video that doesn't use FH-Sync or any other > FH-service as the metrics target. Instead, I wrote a very simple > lightweight node application [2] that serves the purpose of experimenting > with Prometheus on OpenShift better. > > This video is something I prepared very quickly in addition to the video > that will be made soon featuring the metrics solution [3]. > > [1]: https://github.com/aerogearcatalog/metrics-apb > [2]: https://github.com/aliok/node-app-with-prometheus-metrics > [3]: https://issues.jboss.org/browse/AEROGEAR-1797 > > Cheers, > Ali > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf github: https://github.com/matzew twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: From wtrocki at redhat.com Fri Jan 12 11:21:32 2018 From: wtrocki at redhat.com (Wojciech Trocki) Date: Fri, 12 Jan 2018 11:21:32 +0000 Subject: [feedhenry-dev] Proposal for addition of --mobile flag to oc cluster up In-Reply-To: References: Message-ID: Mobile flag as it doesn't provide ability to change values and imposes some hard dependencies. That may be hard accept and maintain on upstream. Upstream works by generalization so if we want to contribute there it's best to pass something that can be used by many people. How about `oc cluster up --service-broker=true --service-broker-org=aerogearcatalog` and whatever else we need? That's easier to accept and contribute upstream. I have done changes for cluster up recently so if you need anything in that let me know - we can work on this together. Another idea is to specify oc cluster up pre/post actions (hooks) that will allow people to run ansible roles for things we need. That will be solid proposal that upstream may consider. Developers can still have simple command by doing alias: *alias oc-mobile-up=`oc cluster up --service-broker=true --service-broker-org=aerogearcatalog` * On Fri, Jan 12, 2018 at 10:51 AM, David Ffrench wrote: > Fantastic Phil, This is 100% needed in my opinion. The mobile services > need to be a first class citizen in OpenShift to ensure easy setup and > adoption. > > DAVID FFRENCH > > senior software engineer, RED HAT MOBILE > > Red Hat Waterford > > Communications House, Cork Road > > Waterford, Ireland > > dffrench at redhat.com > > > > On Fri, Jan 12, 2018 at 10:36 AM, Matthias Wessendorf > wrote: > >> +9001 >> >> On Fri, Jan 12, 2018 at 11:26 AM, Phil Brookes >> wrote: >> >>> Hey Everyone, >>> >>> I have opened a proposal with the OpenShift team, hoping to start a >>> discussion around the addition of a --mobile=true flag to the oc >>> cluster up command. Running oc cluster up --mobile=true will start a >>> local OpenShift cluster with all of the MCP features enabled. >>> >>> This would be a great way for us to gain some exposure for the Mobile >>> Core and get it into the hands of developers more quickly and easily, so >>> I?d love to see you share your thoughts on this idea. You can review / >>> comment / support it here: >>> https://github.com/openshift/origin/issues/18089 >>> >>> Thanks, >>> Phil. >>> ? >>> >> >> >> >> -- >> Project lead AeroGear.org >> > > > _______________________________________________ > 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 pbraun at redhat.com Fri Jan 12 11:30:15 2018 From: pbraun at redhat.com (Peter Braun) Date: Fri, 12 Jan 2018 12:30:15 +0100 Subject: [feedhenry-dev] Demo: Prometheus auto discovery In-Reply-To: References: Message-ID: <567403EF-DADB-4234-8618-F41DAD1B3FB1@redhat.com> great Demo! > Am 12.01.2018 um 11:51 schrieb Ali Ok : > > Hi, > > I created a video, demonstrating Prometheus auto discovery that is configured in metrics-apb[1]: https://www.youtube.com/watch?v=AC_Xet-B1fY > > This video is an educational video that doesn't use FH-Sync or any other FH-service as the metrics target. Instead, I wrote a very simple lightweight node application [2] that serves the purpose of experimenting with Prometheus on OpenShift better. > > This video is something I prepared very quickly in addition to the video that will be made soon featuring the metrics solution [3]. > > [1]: https://github.com/aerogearcatalog/metrics-apb > [2]: https://github.com/aliok/node-app-with-prometheus-metrics > [3]: https://issues.jboss.org/browse/AEROGEAR-1797 > > Cheers, > Ali > _______________________________________________ > 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 pbrookes at redhat.com Fri Jan 12 11:39:04 2018 From: pbrookes at redhat.com (Phil Brookes) Date: Fri, 12 Jan 2018 11:39:04 +0000 Subject: [feedhenry-dev] Proposal for addition of --mobile flag to oc cluster up In-Reply-To: References: Message-ID: Hey Wojciech, Thanks a lot for the feedback. If I have understood you correctly, you are suggesting splitting this task in to two discrete pieces of work: - Add parameters to oc cluster up, to be able to configure the ansible-service-broker with custom docker credentials and docker org to pull in the ASBs from. - Add the ?mobile flag to enable the Mobile-Core UI extension. With the intention of making this an easier change to adopt. If that is correct then I am happy to proceed this way and I can update the proposal to reflect this as a route to implementation. Maybe it would be best to bring this discussion to the proposal so that the OpenShift team also have access to it? Thanks, Phil. ? On Fri, Jan 12, 2018 at 11:21 AM, Wojciech Trocki wrote: > Mobile flag as it doesn't provide ability to change values and imposes > some hard dependencies. > That may be hard accept and maintain on upstream. > Upstream works by generalization so if we want to contribute there it's > best to pass something that can be used by many people. > > How about `oc cluster up --service-broker=true --service-broker-org=aerogearcatalog` > and whatever else we need? > That's easier to accept and contribute upstream. > I have done changes for cluster up recently so if you need anything in > that let me know - we can work on this together. > > Another idea is to specify oc cluster up pre/post actions (hooks) that > will allow people to run ansible roles for things we need. > That will be solid proposal that upstream may consider. > > Developers can still have simple command by doing alias: > > > *alias oc-mobile-up=`oc cluster up --service-broker=true > --service-broker-org=aerogearcatalog` * > > > On Fri, Jan 12, 2018 at 10:51 AM, David Ffrench > wrote: > >> Fantastic Phil, This is 100% needed in my opinion. The mobile services >> need to be a first class citizen in OpenShift to ensure easy setup and >> adoption. >> >> DAVID FFRENCH >> >> senior software engineer, RED HAT MOBILE >> >> Red Hat Waterford >> >> Communications House, Cork Road >> >> Waterford, Ireland >> >> dffrench at redhat.com >> >> >> >> On Fri, Jan 12, 2018 at 10:36 AM, Matthias Wessendorf < >> mwessend at redhat.com> wrote: >> >>> +9001 >>> >>> On Fri, Jan 12, 2018 at 11:26 AM, Phil Brookes >>> wrote: >>> >>>> Hey Everyone, >>>> >>>> I have opened a proposal with the OpenShift team, hoping to start a >>>> discussion around the addition of a --mobile=true flag to the oc >>>> cluster up command. Running oc cluster up --mobile=true will start a >>>> local OpenShift cluster with all of the MCP features enabled. >>>> >>>> This would be a great way for us to gain some exposure for the Mobile >>>> Core and get it into the hands of developers more quickly and easily, so >>>> I?d love to see you share your thoughts on this idea. You can review / >>>> comment / support it here: >>>> https://github.com/openshift/origin/issues/18089 >>>> >>>> Thanks, >>>> Phil. >>>> ? >>>> >>> >>> >>> >>> -- >>> Project lead AeroGear.org >>> >> >> >> _______________________________________________ >> 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 davmarti at redhat.com Fri Jan 12 11:40:02 2018 From: davmarti at redhat.com (David Martin) Date: Fri, 12 Jan 2018 11:40:02 +0000 Subject: [feedhenry-dev] Demo: Prometheus auto discovery In-Reply-To: <567403EF-DADB-4234-8618-F41DAD1B3FB1@redhat.com> References: <567403EF-DADB-4234-8618-F41DAD1B3FB1@redhat.com> Message-ID: Nice Video Ali! It really shows how easy it can be to start capturing metrics from your app. That's 1 of the main goals of the Metrics Service (The other main goal being the capture of metrics for mobile services like sync, push, keyclaok etc...) On 12 January 2018 at 11:30, Peter Braun wrote: > great Demo! > > Am 12.01.2018 um 11:51 schrieb Ali Ok : > > Hi, > > I created a video, demonstrating Prometheus auto discovery that is > configured in metrics-apb[1]: https://www.youtube.com/watch?v=AC_Xet-B1fY > > This video is an educational video that doesn't use FH-Sync or any other > FH-service as the metrics target. Instead, I wrote a very simple > lightweight node application [2] that serves the purpose of experimenting > with Prometheus on OpenShift better. > > This video is something I prepared very quickly in addition to the video > that will be made soon featuring the metrics solution [3]. > > [1]: https://github.com/aerogearcatalog/metrics-apb > [2]: https://github.com/aliok/node-app-with-prometheus-metrics > [3]: https://issues.jboss.org/browse/AEROGEAR-1797 > > Cheers, > Ali > _______________________________________________ > 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 (#aerogear) -------------- next part -------------- An HTML attachment was scrubbed... URL: From davmarti at redhat.com Fri Jan 12 11:46:05 2018 From: davmarti at redhat.com (David Martin) Date: Fri, 12 Jan 2018 11:46:05 +0000 Subject: [feedhenry-dev] Proposal for addition of --mobile flag to oc cluster up In-Reply-To: References: Message-ID: I think there's great value in --mobile flag. Its the same approach for metrics and logging (--metrics, --logging) It would do everything needed to enable the mobile extension and get the cluster into the state we want. Having to provide multiple flags would make it just that little more complex that it raises the barrier. I do think there's upstream value in allowing configuring a default org for the broker though, but I don't think it should be part of this proposal. On 12 January 2018 at 11:39, Phil Brookes wrote: > Hey Wojciech, > > Thanks a lot for the feedback. > > If I have understood you correctly, you are suggesting splitting this task > in to two discrete pieces of work: > > - Add parameters to oc cluster up, to be able to configure the > ansible-service-broker with custom docker credentials and docker org to > pull in the ASBs from. > - Add the ?mobile flag to enable the Mobile-Core UI extension. > > With the intention of making this an easier change to adopt. > > If that is correct then I am happy to proceed this way and I can update > the proposal to reflect this as a route to implementation. > > Maybe it would be best to bring this discussion to the proposal so that > the OpenShift team also have access to it? > > Thanks, > Phil. > ? > > On Fri, Jan 12, 2018 at 11:21 AM, Wojciech Trocki > wrote: > >> Mobile flag as it doesn't provide ability to change values and imposes >> some hard dependencies. >> That may be hard accept and maintain on upstream. >> Upstream works by generalization so if we want to contribute there it's >> best to pass something that can be used by many people. >> >> How about `oc cluster up --service-broker=true >> --service-broker-org=aerogearcatalog` and whatever else we need? >> That's easier to accept and contribute upstream. >> I have done changes for cluster up recently so if you need anything in >> that let me know - we can work on this together. >> >> Another idea is to specify oc cluster up pre/post actions (hooks) that >> will allow people to run ansible roles for things we need. >> That will be solid proposal that upstream may consider. >> >> Developers can still have simple command by doing alias: >> >> >> *alias oc-mobile-up=`oc cluster up --service-broker=true >> --service-broker-org=aerogearcatalog` * >> >> >> On Fri, Jan 12, 2018 at 10:51 AM, David Ffrench >> wrote: >> >>> Fantastic Phil, This is 100% needed in my opinion. The mobile services >>> need to be a first class citizen in OpenShift to ensure easy setup and >>> adoption. >>> >>> DAVID FFRENCH >>> >>> senior software engineer, RED HAT MOBILE >>> >>> Red Hat Waterford >>> >>> Communications House, Cork Road >>> >>> Waterford, Ireland >>> >>> dffrench at redhat.com >>> >>> >>> >>> On Fri, Jan 12, 2018 at 10:36 AM, Matthias Wessendorf < >>> mwessend at redhat.com> wrote: >>> >>>> +9001 >>>> >>>> On Fri, Jan 12, 2018 at 11:26 AM, Phil Brookes >>>> wrote: >>>> >>>>> Hey Everyone, >>>>> >>>>> I have opened a proposal with the OpenShift team, hoping to start a >>>>> discussion around the addition of a --mobile=true flag to the oc >>>>> cluster up command. Running oc cluster up --mobile=true will start a >>>>> local OpenShift cluster with all of the MCP features enabled. >>>>> >>>>> This would be a great way for us to gain some exposure for the Mobile >>>>> Core and get it into the hands of developers more quickly and easily, so >>>>> I?d love to see you share your thoughts on this idea. You can review / >>>>> comment / support it here: >>>>> https://github.com/openshift/origin/issues/18089 >>>>> >>>>> Thanks, >>>>> Phil. >>>>> ? >>>>> >>>> >>>> >>>> >>>> -- >>>> Project lead AeroGear.org >>>> >>> >>> >>> _______________________________________________ >>> feedhenry-dev mailing list >>> feedhenry-dev at redhat.com >>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>> >>> >> >> >> -- >> >> WOJCIECH TROCKI >> >> Red Hat Mobile >> >> IM: wtrocki >> >> > > -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (#aerogear) -------------- next part -------------- An HTML attachment was scrubbed... URL: From cbrookes at redhat.com Fri Jan 12 11:55:04 2018 From: cbrookes at redhat.com (Craig Brookes) Date: Fri, 12 Jan 2018 11:55:04 +0000 Subject: [feedhenry-dev] Proposal for addition of --mobile flag to oc cluster up In-Reply-To: References: Message-ID: +1 On Fri, Jan 12, 2018 at 11:46 AM, David Martin wrote: > I think there's great value in --mobile flag. > Its the same approach for metrics and logging (--metrics, --logging) > > It would do everything needed to enable the mobile extension and get the > cluster into the state we want. > Having to provide multiple flags would make it just that little more > complex that it raises the barrier. > > I do think there's upstream value in allowing configuring a default org > for the broker though, but I don't think it should be part of this proposal. > > On 12 January 2018 at 11:39, Phil Brookes wrote: > >> Hey Wojciech, >> >> Thanks a lot for the feedback. >> >> If I have understood you correctly, you are suggesting splitting this >> task in to two discrete pieces of work: >> >> - Add parameters to oc cluster up, to be able to configure the >> ansible-service-broker with custom docker credentials and docker org to >> pull in the ASBs from. >> - Add the ?mobile flag to enable the Mobile-Core UI extension. >> >> With the intention of making this an easier change to adopt. >> >> If that is correct then I am happy to proceed this way and I can update >> the proposal to reflect this as a route to implementation. >> >> Maybe it would be best to bring this discussion to the proposal so that >> the OpenShift team also have access to it? >> >> Thanks, >> Phil. >> ? >> >> On Fri, Jan 12, 2018 at 11:21 AM, Wojciech Trocki >> wrote: >> >>> Mobile flag as it doesn't provide ability to change values and imposes >>> some hard dependencies. >>> That may be hard accept and maintain on upstream. >>> Upstream works by generalization so if we want to contribute there it's >>> best to pass something that can be used by many people. >>> >>> How about `oc cluster up --service-broker=true >>> --service-broker-org=aerogearcatalog` and whatever else we need? >>> That's easier to accept and contribute upstream. >>> I have done changes for cluster up recently so if you need anything in >>> that let me know - we can work on this together. >>> >>> Another idea is to specify oc cluster up pre/post actions (hooks) that >>> will allow people to run ansible roles for things we need. >>> That will be solid proposal that upstream may consider. >>> >>> Developers can still have simple command by doing alias: >>> >>> >>> *alias oc-mobile-up=`oc cluster up --service-broker=true >>> --service-broker-org=aerogearcatalog` * >>> >>> >>> On Fri, Jan 12, 2018 at 10:51 AM, David Ffrench >>> wrote: >>> >>>> Fantastic Phil, This is 100% needed in my opinion. The mobile services >>>> need to be a first class citizen in OpenShift to ensure easy setup and >>>> adoption. >>>> >>>> DAVID FFRENCH >>>> >>>> senior software engineer, RED HAT MOBILE >>>> >>>> Red Hat Waterford >>>> >>>> Communications House, Cork Road >>>> >>>> Waterford, Ireland >>>> >>>> dffrench at redhat.com >>>> >>>> >>>> >>>> On Fri, Jan 12, 2018 at 10:36 AM, Matthias Wessendorf < >>>> mwessend at redhat.com> wrote: >>>> >>>>> +9001 >>>>> >>>>> On Fri, Jan 12, 2018 at 11:26 AM, Phil Brookes >>>>> wrote: >>>>> >>>>>> Hey Everyone, >>>>>> >>>>>> I have opened a proposal with the OpenShift team, hoping to start a >>>>>> discussion around the addition of a --mobile=true flag to the oc >>>>>> cluster up command. Running oc cluster up --mobile=true will start a >>>>>> local OpenShift cluster with all of the MCP features enabled. >>>>>> >>>>>> This would be a great way for us to gain some exposure for the Mobile >>>>>> Core and get it into the hands of developers more quickly and easily, so >>>>>> I?d love to see you share your thoughts on this idea. You can review / >>>>>> comment / support it here: >>>>>> https://github.com/openshift/origin/issues/18089 >>>>>> >>>>>> Thanks, >>>>>> Phil. >>>>>> ? >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Project lead AeroGear.org >>>>> >>>> >>>> >>>> _______________________________________________ >>>> feedhenry-dev mailing list >>>> feedhenry-dev at redhat.com >>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>> >>>> >>> >>> >>> -- >>> >>> WOJCIECH TROCKI >>> >>> Red Hat Mobile >>> >>> IM: wtrocki >>> >>> >> >> > > > -- > David Martin > Red Hat Mobile > Twitter: @irldavem > IRC: @irldavem (#aerogear) > -- Craig Brookes RHMAP @maleck13 Github -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbrookes at redhat.com Fri Jan 12 12:04:10 2018 From: pbrookes at redhat.com (Phil Brookes) Date: Fri, 12 Jan 2018 12:04:10 +0000 Subject: [feedhenry-dev] Proposal for addition of --mobile flag to oc cluster up In-Reply-To: References: Message-ID: I?ve discussed this privately with Wojciech as I had misunderstood his suggestion, so here?s my attempt to clarify the discussion: Rather than inserting our mobile oriented tasks into the upstream tool (oc), which doesn?t provide value to all users of that tool but rather only to the users who are interested in the mobile use-case; we should instead modify the tool so that it can accept addons, similar (ideally, identical) to minishift addons. The proposal here would be something like: oc cluster addons install mobilecore oc cluster addons enable mobilecore oc cluster up There a few benefits to this solution: - There is a clear value-add to the upstream tool - We only need to maintain one mobilecore plugin for both minishift and oc cluster up - The barrier to entry for mobile developers is low - The process for setting up a local cluster is the same with both tools - Future changes to the setup process of the Mobile-Core can be submitted to our own repo ?@Wojciech please correct me, if I?ve still misunderstood anything!? Regards, Phil. ? On Fri, Jan 12, 2018 at 11:55 AM, Craig Brookes wrote: > +1 > > On Fri, Jan 12, 2018 at 11:46 AM, David Martin > wrote: > >> I think there's great value in --mobile flag. >> Its the same approach for metrics and logging (--metrics, --logging) >> >> It would do everything needed to enable the mobile extension and get the >> cluster into the state we want. >> Having to provide multiple flags would make it just that little more >> complex that it raises the barrier. >> >> I do think there's upstream value in allowing configuring a default org >> for the broker though, but I don't think it should be part of this proposal. >> >> On 12 January 2018 at 11:39, Phil Brookes wrote: >> >>> Hey Wojciech, >>> >>> Thanks a lot for the feedback. >>> >>> If I have understood you correctly, you are suggesting splitting this >>> task in to two discrete pieces of work: >>> >>> - Add parameters to oc cluster up, to be able to configure the >>> ansible-service-broker with custom docker credentials and docker org to >>> pull in the ASBs from. >>> - Add the ?mobile flag to enable the Mobile-Core UI extension. >>> >>> With the intention of making this an easier change to adopt. >>> >>> If that is correct then I am happy to proceed this way and I can update >>> the proposal to reflect this as a route to implementation. >>> >>> Maybe it would be best to bring this discussion to the proposal so that >>> the OpenShift team also have access to it? >>> >>> Thanks, >>> Phil. >>> ? >>> >>> On Fri, Jan 12, 2018 at 11:21 AM, Wojciech Trocki >>> wrote: >>> >>>> Mobile flag as it doesn't provide ability to change values and imposes >>>> some hard dependencies. >>>> That may be hard accept and maintain on upstream. >>>> Upstream works by generalization so if we want to contribute there it's >>>> best to pass something that can be used by many people. >>>> >>>> How about `oc cluster up --service-broker=true >>>> --service-broker-org=aerogearcatalog` and whatever else we need? >>>> That's easier to accept and contribute upstream. >>>> I have done changes for cluster up recently so if you need anything in >>>> that let me know - we can work on this together. >>>> >>>> Another idea is to specify oc cluster up pre/post actions (hooks) that >>>> will allow people to run ansible roles for things we need. >>>> That will be solid proposal that upstream may consider. >>>> >>>> Developers can still have simple command by doing alias: >>>> >>>> >>>> *alias oc-mobile-up=`oc cluster up --service-broker=true >>>> --service-broker-org=aerogearcatalog` * >>>> >>>> >>>> On Fri, Jan 12, 2018 at 10:51 AM, David Ffrench >>>> wrote: >>>> >>>>> Fantastic Phil, This is 100% needed in my opinion. The mobile services >>>>> need to be a first class citizen in OpenShift to ensure easy setup and >>>>> adoption. >>>>> >>>>> DAVID FFRENCH >>>>> >>>>> senior software engineer, RED HAT MOBILE >>>>> >>>>> Red Hat Waterford >>>>> >>>>> Communications House, Cork Road >>>>> >>>>> Waterford, Ireland >>>>> >>>>> dffrench at redhat.com >>>>> >>>>> >>>>> >>>>> On Fri, Jan 12, 2018 at 10:36 AM, Matthias Wessendorf < >>>>> mwessend at redhat.com> wrote: >>>>> >>>>>> +9001 >>>>>> >>>>>> On Fri, Jan 12, 2018 at 11:26 AM, Phil Brookes >>>>>> wrote: >>>>>> >>>>>>> Hey Everyone, >>>>>>> >>>>>>> I have opened a proposal with the OpenShift team, hoping to start a >>>>>>> discussion around the addition of a --mobile=true flag to the oc >>>>>>> cluster up command. Running oc cluster up --mobile=true will start >>>>>>> a local OpenShift cluster with all of the MCP features enabled. >>>>>>> >>>>>>> This would be a great way for us to gain some exposure for the >>>>>>> Mobile Core and get it into the hands of developers more quickly and >>>>>>> easily, so I?d love to see you share your thoughts on this idea. You can >>>>>>> review / comment / support it here: >>>>>>> https://github.com/openshift/origin/issues/18089 >>>>>>> >>>>>>> Thanks, >>>>>>> Phil. >>>>>>> ? >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Project lead AeroGear.org >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> feedhenry-dev mailing list >>>>> feedhenry-dev at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> WOJCIECH TROCKI >>>> >>>> Red Hat Mobile >>>> >>>> IM: wtrocki >>>> >>>> >>> >>> >> >> >> -- >> David Martin >> Red Hat Mobile >> Twitter: @irldavem >> IRC: @irldavem (#aerogear) >> > > > > -- > Craig Brookes > RHMAP > @maleck13 Github > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Fri Jan 12 12:06:06 2018 From: mwessend at redhat.com (Matthias Wessendorf) Date: Fri, 12 Jan 2018 13:06:06 +0100 Subject: [feedhenry-dev] Proposal for addition of --mobile flag to oc cluster up In-Reply-To: References: Message-ID: On Fri, Jan 12, 2018 at 12:46 PM, David Martin wrote: > I think there's great value in --mobile flag. > Its the same approach for metrics and logging (--metrics, --logging) > > It would do everything needed to enable the mobile extension and get the > cluster into the state we want. > Having to provide multiple flags would make it just that little more > complex that it raises the barrier. > > I do think there's upstream value in allowing configuring a default org > for the broker though, but I don't think it should be part of this proposal. > +1 > > On 12 January 2018 at 11:39, Phil Brookes wrote: > >> Hey Wojciech, >> >> Thanks a lot for the feedback. >> >> If I have understood you correctly, you are suggesting splitting this >> task in to two discrete pieces of work: >> >> - Add parameters to oc cluster up, to be able to configure the >> ansible-service-broker with custom docker credentials and docker org to >> pull in the ASBs from. >> - Add the ?mobile flag to enable the Mobile-Core UI extension. >> >> With the intention of making this an easier change to adopt. >> >> If that is correct then I am happy to proceed this way and I can update >> the proposal to reflect this as a route to implementation. >> >> Maybe it would be best to bring this discussion to the proposal so that >> the OpenShift team also have access to it? >> >> Thanks, >> Phil. >> ? >> >> On Fri, Jan 12, 2018 at 11:21 AM, Wojciech Trocki >> wrote: >> >>> Mobile flag as it doesn't provide ability to change values and imposes >>> some hard dependencies. >>> That may be hard accept and maintain on upstream. >>> Upstream works by generalization so if we want to contribute there it's >>> best to pass something that can be used by many people. >>> >>> How about `oc cluster up --service-broker=true >>> --service-broker-org=aerogearcatalog` and whatever else we need? >>> That's easier to accept and contribute upstream. >>> I have done changes for cluster up recently so if you need anything in >>> that let me know - we can work on this together. >>> >>> Another idea is to specify oc cluster up pre/post actions (hooks) that >>> will allow people to run ansible roles for things we need. >>> That will be solid proposal that upstream may consider. >>> >>> Developers can still have simple command by doing alias: >>> >>> >>> *alias oc-mobile-up=`oc cluster up --service-broker=true >>> --service-broker-org=aerogearcatalog` * >>> >>> >>> On Fri, Jan 12, 2018 at 10:51 AM, David Ffrench >>> wrote: >>> >>>> Fantastic Phil, This is 100% needed in my opinion. The mobile services >>>> need to be a first class citizen in OpenShift to ensure easy setup and >>>> adoption. >>>> >>>> DAVID FFRENCH >>>> >>>> senior software engineer, RED HAT MOBILE >>>> >>>> Red Hat Waterford >>>> >>>> Communications House, Cork Road >>>> >>>> Waterford, Ireland >>>> >>>> dffrench at redhat.com >>>> >>>> >>>> >>>> On Fri, Jan 12, 2018 at 10:36 AM, Matthias Wessendorf < >>>> mwessend at redhat.com> wrote: >>>> >>>>> +9001 >>>>> >>>>> On Fri, Jan 12, 2018 at 11:26 AM, Phil Brookes >>>>> wrote: >>>>> >>>>>> Hey Everyone, >>>>>> >>>>>> I have opened a proposal with the OpenShift team, hoping to start a >>>>>> discussion around the addition of a --mobile=true flag to the oc >>>>>> cluster up command. Running oc cluster up --mobile=true will start a >>>>>> local OpenShift cluster with all of the MCP features enabled. >>>>>> >>>>>> This would be a great way for us to gain some exposure for the Mobile >>>>>> Core and get it into the hands of developers more quickly and easily, so >>>>>> I?d love to see you share your thoughts on this idea. You can review / >>>>>> comment / support it here: >>>>>> https://github.com/openshift/origin/issues/18089 >>>>>> >>>>>> Thanks, >>>>>> Phil. >>>>>> ? >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Project lead AeroGear.org >>>>> >>>> >>>> >>>> _______________________________________________ >>>> feedhenry-dev mailing list >>>> feedhenry-dev at redhat.com >>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>> >>>> >>> >>> >>> -- >>> >>> WOJCIECH TROCKI >>> >>> Red Hat Mobile >>> >>> IM: wtrocki >>> >>> >> >> > > > -- > David Martin > Red Hat Mobile > Twitter: @irldavem > IRC: @irldavem (#aerogear) > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Fri Jan 12 12:06:39 2018 From: mwessend at redhat.com (Matthias Wessendorf) Date: Fri, 12 Jan 2018 13:06:39 +0100 Subject: [feedhenry-dev] Proposal for addition of --mobile flag to oc cluster up In-Reply-To: References: Message-ID: I'd actually prefer more --mobile - which than does exactly what we need On Fri, Jan 12, 2018 at 1:04 PM, Phil Brookes wrote: > I?ve discussed this privately with Wojciech as I had misunderstood his > suggestion, so here?s my attempt to clarify the discussion: > > Rather than inserting our mobile oriented tasks into the upstream tool > (oc), which doesn?t provide value to all users of that tool but rather only > to the users who are interested in the mobile use-case; we should instead > modify the tool so that it can accept addons, similar (ideally, identical) > to minishift addons. > > The proposal here would be something like: > > oc cluster addons install mobilecore > oc cluster addons enable mobilecore > oc cluster up > > There a few benefits to this solution: > > - There is a clear value-add to the upstream tool > - We only need to maintain one mobilecore plugin for both minishift > and oc cluster up > - The barrier to entry for mobile developers is low > - The process for setting up a local cluster is the same with both > tools > - Future changes to the setup process of the Mobile-Core can be > submitted to our own repo > > ?@Wojciech please correct me, if I?ve still misunderstood anything!? > > Regards, > Phil. > ? > > On Fri, Jan 12, 2018 at 11:55 AM, Craig Brookes > wrote: > >> +1 >> >> On Fri, Jan 12, 2018 at 11:46 AM, David Martin >> wrote: >> >>> I think there's great value in --mobile flag. >>> Its the same approach for metrics and logging (--metrics, --logging) >>> >>> It would do everything needed to enable the mobile extension and get the >>> cluster into the state we want. >>> Having to provide multiple flags would make it just that little more >>> complex that it raises the barrier. >>> >>> I do think there's upstream value in allowing configuring a default org >>> for the broker though, but I don't think it should be part of this proposal. >>> >>> On 12 January 2018 at 11:39, Phil Brookes wrote: >>> >>>> Hey Wojciech, >>>> >>>> Thanks a lot for the feedback. >>>> >>>> If I have understood you correctly, you are suggesting splitting this >>>> task in to two discrete pieces of work: >>>> >>>> - Add parameters to oc cluster up, to be able to configure the >>>> ansible-service-broker with custom docker credentials and docker org to >>>> pull in the ASBs from. >>>> - Add the ?mobile flag to enable the Mobile-Core UI extension. >>>> >>>> With the intention of making this an easier change to adopt. >>>> >>>> If that is correct then I am happy to proceed this way and I can update >>>> the proposal to reflect this as a route to implementation. >>>> >>>> Maybe it would be best to bring this discussion to the proposal so that >>>> the OpenShift team also have access to it? >>>> >>>> Thanks, >>>> Phil. >>>> ? >>>> >>>> On Fri, Jan 12, 2018 at 11:21 AM, Wojciech Trocki >>>> wrote: >>>> >>>>> Mobile flag as it doesn't provide ability to change values and imposes >>>>> some hard dependencies. >>>>> That may be hard accept and maintain on upstream. >>>>> Upstream works by generalization so if we want to contribute there >>>>> it's best to pass something that can be used by many people. >>>>> >>>>> How about `oc cluster up --service-broker=true >>>>> --service-broker-org=aerogearcatalog` and whatever else we need? >>>>> That's easier to accept and contribute upstream. >>>>> I have done changes for cluster up recently so if you need anything in >>>>> that let me know - we can work on this together. >>>>> >>>>> Another idea is to specify oc cluster up pre/post actions (hooks) that >>>>> will allow people to run ansible roles for things we need. >>>>> That will be solid proposal that upstream may consider. >>>>> >>>>> Developers can still have simple command by doing alias: >>>>> >>>>> >>>>> *alias oc-mobile-up=`oc cluster up --service-broker=true >>>>> --service-broker-org=aerogearcatalog` * >>>>> >>>>> >>>>> On Fri, Jan 12, 2018 at 10:51 AM, David Ffrench >>>>> wrote: >>>>> >>>>>> Fantastic Phil, This is 100% needed in my opinion. The mobile >>>>>> services need to be a first class citizen in OpenShift to ensure easy setup >>>>>> and adoption. >>>>>> >>>>>> DAVID FFRENCH >>>>>> >>>>>> senior software engineer, RED HAT MOBILE >>>>>> >>>>>> Red Hat Waterford >>>>>> >>>>>> Communications House, Cork Road >>>>>> >>>>>> Waterford, Ireland >>>>>> >>>>>> dffrench at redhat.com >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Jan 12, 2018 at 10:36 AM, Matthias Wessendorf < >>>>>> mwessend at redhat.com> wrote: >>>>>> >>>>>>> +9001 >>>>>>> >>>>>>> On Fri, Jan 12, 2018 at 11:26 AM, Phil Brookes >>>>>>> wrote: >>>>>>> >>>>>>>> Hey Everyone, >>>>>>>> >>>>>>>> I have opened a proposal with the OpenShift team, hoping to start a >>>>>>>> discussion around the addition of a --mobile=true flag to the oc >>>>>>>> cluster up command. Running oc cluster up --mobile=true will start >>>>>>>> a local OpenShift cluster with all of the MCP features enabled. >>>>>>>> >>>>>>>> This would be a great way for us to gain some exposure for the >>>>>>>> Mobile Core and get it into the hands of developers more quickly and >>>>>>>> easily, so I?d love to see you share your thoughts on this idea. You can >>>>>>>> review / comment / support it here: >>>>>>>> https://github.com/openshift/origin/issues/18089 >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Phil. >>>>>>>> ? >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Project lead AeroGear.org >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> feedhenry-dev mailing list >>>>>> feedhenry-dev at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> WOJCIECH TROCKI >>>>> >>>>> Red Hat Mobile >>>>> >>>>> IM: wtrocki >>>>> >>>>> >>>> >>>> >>> >>> >>> -- >>> David Martin >>> Red Hat Mobile >>> Twitter: @irldavem >>> IRC: @irldavem (#aerogear) >>> >> >> >> >> -- >> Craig Brookes >> RHMAP >> @maleck13 Github >> > > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfrizell at redhat.com Fri Jan 12 12:14:28 2018 From: jfrizell at redhat.com (John Frizelle) Date: Fri, 12 Jan 2018 12:14:28 +0000 Subject: [feedhenry-dev] Proposal for addition of --mobile flag to oc cluster up In-Reply-To: References: Message-ID: I agree with Wojciech - we are more likely to get the addon proposal accepted than the mobile specific one. As a compromise, we could also propose adding support for a simple --addon=mobile as an alias to the addon install & enable commands, where the --foo flag is used to identify the name of the addon the install and enable e..g. oc cluster up --addon=mobile would run the following commands: oc cluster addons install mobile oc cluster addons enable mobile oc cluster up and oc cluster up --addon=foobar would run the following commands: oc cluster addons install foobar oc cluster addons enable foobar oc cluster up -- 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 January 2018 at 12:06, Matthias Wessendorf wrote: > I'd actually prefer more --mobile - which than does exactly what we need > > On Fri, Jan 12, 2018 at 1:04 PM, Phil Brookes wrote: > >> I?ve discussed this privately with Wojciech as I had misunderstood his >> suggestion, so here?s my attempt to clarify the discussion: >> >> Rather than inserting our mobile oriented tasks into the upstream tool >> (oc), which doesn?t provide value to all users of that tool but rather only >> to the users who are interested in the mobile use-case; we should instead >> modify the tool so that it can accept addons, similar (ideally, identical) >> to minishift addons. >> >> The proposal here would be something like: >> >> oc cluster addons install mobilecore >> oc cluster addons enable mobilecore >> oc cluster up >> >> There a few benefits to this solution: >> >> - There is a clear value-add to the upstream tool >> - We only need to maintain one mobilecore plugin for both minishift >> and oc cluster up >> - The barrier to entry for mobile developers is low >> - The process for setting up a local cluster is the same with both >> tools >> - Future changes to the setup process of the Mobile-Core can be >> submitted to our own repo >> >> ?@Wojciech please correct me, if I?ve still misunderstood anything!? >> >> Regards, >> Phil. >> ? >> >> On Fri, Jan 12, 2018 at 11:55 AM, Craig Brookes >> wrote: >> >>> +1 >>> >>> On Fri, Jan 12, 2018 at 11:46 AM, David Martin >>> wrote: >>> >>>> I think there's great value in --mobile flag. >>>> Its the same approach for metrics and logging (--metrics, --logging) >>>> >>>> It would do everything needed to enable the mobile extension and get >>>> the cluster into the state we want. >>>> Having to provide multiple flags would make it just that little more >>>> complex that it raises the barrier. >>>> >>>> I do think there's upstream value in allowing configuring a default org >>>> for the broker though, but I don't think it should be part of this proposal. >>>> >>>> On 12 January 2018 at 11:39, Phil Brookes wrote: >>>> >>>>> Hey Wojciech, >>>>> >>>>> Thanks a lot for the feedback. >>>>> >>>>> If I have understood you correctly, you are suggesting splitting this >>>>> task in to two discrete pieces of work: >>>>> >>>>> - Add parameters to oc cluster up, to be able to configure the >>>>> ansible-service-broker with custom docker credentials and docker org to >>>>> pull in the ASBs from. >>>>> - Add the ?mobile flag to enable the Mobile-Core UI extension. >>>>> >>>>> With the intention of making this an easier change to adopt. >>>>> >>>>> If that is correct then I am happy to proceed this way and I can >>>>> update the proposal to reflect this as a route to implementation. >>>>> >>>>> Maybe it would be best to bring this discussion to the proposal so >>>>> that the OpenShift team also have access to it? >>>>> >>>>> Thanks, >>>>> Phil. >>>>> ? >>>>> >>>>> On Fri, Jan 12, 2018 at 11:21 AM, Wojciech Trocki >>>>> wrote: >>>>> >>>>>> Mobile flag as it doesn't provide ability to change values and >>>>>> imposes some hard dependencies. >>>>>> That may be hard accept and maintain on upstream. >>>>>> Upstream works by generalization so if we want to contribute there >>>>>> it's best to pass something that can be used by many people. >>>>>> >>>>>> How about `oc cluster up --service-broker=true >>>>>> --service-broker-org=aerogearcatalog` and whatever else we need? >>>>>> That's easier to accept and contribute upstream. >>>>>> I have done changes for cluster up recently so if you need anything >>>>>> in that let me know - we can work on this together. >>>>>> >>>>>> Another idea is to specify oc cluster up pre/post actions (hooks) >>>>>> that will allow people to run ansible roles for things we need. >>>>>> That will be solid proposal that upstream may consider. >>>>>> >>>>>> Developers can still have simple command by doing alias: >>>>>> >>>>>> >>>>>> *alias oc-mobile-up=`oc cluster up --service-broker=true >>>>>> --service-broker-org=aerogearcatalog` * >>>>>> >>>>>> >>>>>> On Fri, Jan 12, 2018 at 10:51 AM, David Ffrench >>>>>> wrote: >>>>>> >>>>>>> Fantastic Phil, This is 100% needed in my opinion. The mobile >>>>>>> services need to be a first class citizen in OpenShift to ensure easy setup >>>>>>> and adoption. >>>>>>> >>>>>>> DAVID FFRENCH >>>>>>> >>>>>>> senior software engineer, RED HAT MOBILE >>>>>>> >>>>>>> Red Hat Waterford >>>>>>> >>>>>>> Communications House, Cork Road >>>>>>> >>>>>>> Waterford, Ireland >>>>>>> >>>>>>> dffrench at redhat.com >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Jan 12, 2018 at 10:36 AM, Matthias Wessendorf < >>>>>>> mwessend at redhat.com> wrote: >>>>>>> >>>>>>>> +9001 >>>>>>>> >>>>>>>> On Fri, Jan 12, 2018 at 11:26 AM, Phil Brookes >>>>>>> > wrote: >>>>>>>> >>>>>>>>> Hey Everyone, >>>>>>>>> >>>>>>>>> I have opened a proposal with the OpenShift team, hoping to start >>>>>>>>> a discussion around the addition of a --mobile=true flag to the oc >>>>>>>>> cluster up command. Running oc cluster up --mobile=true will >>>>>>>>> start a local OpenShift cluster with all of the MCP features enabled. >>>>>>>>> >>>>>>>>> This would be a great way for us to gain some exposure for the >>>>>>>>> Mobile Core and get it into the hands of developers more quickly and >>>>>>>>> easily, so I?d love to see you share your thoughts on this idea. You can >>>>>>>>> review / comment / support it here: >>>>>>>>> https://github.com/openshift/origin/issues/18089 >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Phil. >>>>>>>>> ? >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Project lead AeroGear.org >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> feedhenry-dev mailing list >>>>>>> feedhenry-dev at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> WOJCIECH TROCKI >>>>>> >>>>>> Red Hat Mobile >>>>>> >>>>>> IM: wtrocki >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> David Martin >>>> Red Hat Mobile >>>> Twitter: @irldavem >>>> IRC: @irldavem (#aerogear) >>>> >>> >>> >>> >>> -- >>> Craig Brookes >>> RHMAP >>> @maleck13 Github >>> >> >> > > > -- > 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: From cbrookes at redhat.com Fri Jan 12 12:15:12 2018 From: cbrookes at redhat.com (Craig Brookes) Date: Fri, 12 Jan 2018 12:15:12 +0000 Subject: [feedhenry-dev] Proposal for addition of --mobile flag to oc cluster up In-Reply-To: References: Message-ID: While that is an interesting proposal around the addons, I would suggest waiting for the OpenShift team to get back on your issue. Adding a plugin structure to oc is likely a much bigger piece of work and need a lot more engagement from the OpenShift team. That doesn't mean a different proposal for this approach could not be made however, but rather that our current proposal covers our immediate need and has clear prior art. On Fri, Jan 12, 2018 at 12:06 PM, Matthias Wessendorf wrote: > I'd actually prefer more --mobile - which than does exactly what we need > > On Fri, Jan 12, 2018 at 1:04 PM, Phil Brookes wrote: > >> I?ve discussed this privately with Wojciech as I had misunderstood his >> suggestion, so here?s my attempt to clarify the discussion: >> >> Rather than inserting our mobile oriented tasks into the upstream tool >> (oc), which doesn?t provide value to all users of that tool but rather only >> to the users who are interested in the mobile use-case; we should instead >> modify the tool so that it can accept addons, similar (ideally, identical) >> to minishift addons. >> >> The proposal here would be something like: >> >> oc cluster addons install mobilecore >> oc cluster addons enable mobilecore >> oc cluster up >> >> There a few benefits to this solution: >> >> - There is a clear value-add to the upstream tool >> - We only need to maintain one mobilecore plugin for both minishift >> and oc cluster up >> - The barrier to entry for mobile developers is low >> - The process for setting up a local cluster is the same with both >> tools >> - Future changes to the setup process of the Mobile-Core can be >> submitted to our own repo >> >> ?@Wojciech please correct me, if I?ve still misunderstood anything!? >> >> Regards, >> Phil. >> ? >> >> On Fri, Jan 12, 2018 at 11:55 AM, Craig Brookes >> wrote: >> >>> +1 >>> >>> On Fri, Jan 12, 2018 at 11:46 AM, David Martin >>> wrote: >>> >>>> I think there's great value in --mobile flag. >>>> Its the same approach for metrics and logging (--metrics, --logging) >>>> >>>> It would do everything needed to enable the mobile extension and get >>>> the cluster into the state we want. >>>> Having to provide multiple flags would make it just that little more >>>> complex that it raises the barrier. >>>> >>>> I do think there's upstream value in allowing configuring a default org >>>> for the broker though, but I don't think it should be part of this proposal. >>>> >>>> On 12 January 2018 at 11:39, Phil Brookes wrote: >>>> >>>>> Hey Wojciech, >>>>> >>>>> Thanks a lot for the feedback. >>>>> >>>>> If I have understood you correctly, you are suggesting splitting this >>>>> task in to two discrete pieces of work: >>>>> >>>>> - Add parameters to oc cluster up, to be able to configure the >>>>> ansible-service-broker with custom docker credentials and docker org to >>>>> pull in the ASBs from. >>>>> - Add the ?mobile flag to enable the Mobile-Core UI extension. >>>>> >>>>> With the intention of making this an easier change to adopt. >>>>> >>>>> If that is correct then I am happy to proceed this way and I can >>>>> update the proposal to reflect this as a route to implementation. >>>>> >>>>> Maybe it would be best to bring this discussion to the proposal so >>>>> that the OpenShift team also have access to it? >>>>> >>>>> Thanks, >>>>> Phil. >>>>> ? >>>>> >>>>> On Fri, Jan 12, 2018 at 11:21 AM, Wojciech Trocki >>>>> wrote: >>>>> >>>>>> Mobile flag as it doesn't provide ability to change values and >>>>>> imposes some hard dependencies. >>>>>> That may be hard accept and maintain on upstream. >>>>>> Upstream works by generalization so if we want to contribute there >>>>>> it's best to pass something that can be used by many people. >>>>>> >>>>>> How about `oc cluster up --service-broker=true >>>>>> --service-broker-org=aerogearcatalog` and whatever else we need? >>>>>> That's easier to accept and contribute upstream. >>>>>> I have done changes for cluster up recently so if you need anything >>>>>> in that let me know - we can work on this together. >>>>>> >>>>>> Another idea is to specify oc cluster up pre/post actions (hooks) >>>>>> that will allow people to run ansible roles for things we need. >>>>>> That will be solid proposal that upstream may consider. >>>>>> >>>>>> Developers can still have simple command by doing alias: >>>>>> >>>>>> >>>>>> *alias oc-mobile-up=`oc cluster up --service-broker=true >>>>>> --service-broker-org=aerogearcatalog` * >>>>>> >>>>>> >>>>>> On Fri, Jan 12, 2018 at 10:51 AM, David Ffrench >>>>>> wrote: >>>>>> >>>>>>> Fantastic Phil, This is 100% needed in my opinion. The mobile >>>>>>> services need to be a first class citizen in OpenShift to ensure easy setup >>>>>>> and adoption. >>>>>>> >>>>>>> DAVID FFRENCH >>>>>>> >>>>>>> senior software engineer, RED HAT MOBILE >>>>>>> >>>>>>> Red Hat Waterford >>>>>>> >>>>>>> Communications House, Cork Road >>>>>>> >>>>>>> Waterford, Ireland >>>>>>> >>>>>>> dffrench at redhat.com >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Jan 12, 2018 at 10:36 AM, Matthias Wessendorf < >>>>>>> mwessend at redhat.com> wrote: >>>>>>> >>>>>>>> +9001 >>>>>>>> >>>>>>>> On Fri, Jan 12, 2018 at 11:26 AM, Phil Brookes >>>>>>> > wrote: >>>>>>>> >>>>>>>>> Hey Everyone, >>>>>>>>> >>>>>>>>> I have opened a proposal with the OpenShift team, hoping to start >>>>>>>>> a discussion around the addition of a --mobile=true flag to the oc >>>>>>>>> cluster up command. Running oc cluster up --mobile=true will >>>>>>>>> start a local OpenShift cluster with all of the MCP features enabled. >>>>>>>>> >>>>>>>>> This would be a great way for us to gain some exposure for the >>>>>>>>> Mobile Core and get it into the hands of developers more quickly and >>>>>>>>> easily, so I?d love to see you share your thoughts on this idea. You can >>>>>>>>> review / comment / support it here: >>>>>>>>> https://github.com/openshift/origin/issues/18089 >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Phil. >>>>>>>>> ? >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Project lead AeroGear.org >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> feedhenry-dev mailing list >>>>>>> feedhenry-dev at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> WOJCIECH TROCKI >>>>>> >>>>>> Red Hat Mobile >>>>>> >>>>>> IM: wtrocki >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> David Martin >>>> Red Hat Mobile >>>> Twitter: @irldavem >>>> IRC: @irldavem (#aerogear) >>>> >>> >>> >>> >>> -- >>> Craig Brookes >>> RHMAP >>> @maleck13 Github >>> >> >> > > > -- > Project lead AeroGear.org > -- Craig Brookes RHMAP @maleck13 Github -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfrizell at redhat.com Fri Jan 12 12:20:21 2018 From: jfrizell at redhat.com (John Frizelle) Date: Fri, 12 Jan 2018 12:20:21 +0000 Subject: [feedhenry-dev] Proposal for addition of --mobile flag to oc cluster up In-Reply-To: References: Message-ID: Good point Criag - let's see what the response to this request is before we look at an entire plugin ecosystem... Question: does the minishift plugin offering lend itself in any way to being re-used or ported into the oc tool? -- 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 January 2018 at 12:15, Craig Brookes wrote: > While that is an interesting proposal around the addons, I would suggest > waiting for the OpenShift team to get back on your issue. Adding a plugin > structure to oc is likely a much bigger piece of work and need a lot more > engagement from the OpenShift team. > That doesn't mean a different proposal for this approach could not be made > however, but rather that our current proposal covers our immediate need and > has clear prior art. > > On Fri, Jan 12, 2018 at 12:06 PM, Matthias Wessendorf > wrote: > >> I'd actually prefer more --mobile - which than does exactly what we need >> >> On Fri, Jan 12, 2018 at 1:04 PM, Phil Brookes >> wrote: >> >>> I?ve discussed this privately with Wojciech as I had misunderstood his >>> suggestion, so here?s my attempt to clarify the discussion: >>> >>> Rather than inserting our mobile oriented tasks into the upstream tool >>> (oc), which doesn?t provide value to all users of that tool but rather only >>> to the users who are interested in the mobile use-case; we should instead >>> modify the tool so that it can accept addons, similar (ideally, identical) >>> to minishift addons. >>> >>> The proposal here would be something like: >>> >>> oc cluster addons install mobilecore >>> oc cluster addons enable mobilecore >>> oc cluster up >>> >>> There a few benefits to this solution: >>> >>> - There is a clear value-add to the upstream tool >>> - We only need to maintain one mobilecore plugin for both minishift >>> and oc cluster up >>> - The barrier to entry for mobile developers is low >>> - The process for setting up a local cluster is the same with both >>> tools >>> - Future changes to the setup process of the Mobile-Core can be >>> submitted to our own repo >>> >>> ?@Wojciech please correct me, if I?ve still misunderstood anything!? >>> >>> Regards, >>> Phil. >>> ? >>> >>> On Fri, Jan 12, 2018 at 11:55 AM, Craig Brookes >>> wrote: >>> >>>> +1 >>>> >>>> On Fri, Jan 12, 2018 at 11:46 AM, David Martin >>>> wrote: >>>> >>>>> I think there's great value in --mobile flag. >>>>> Its the same approach for metrics and logging (--metrics, --logging) >>>>> >>>>> It would do everything needed to enable the mobile extension and get >>>>> the cluster into the state we want. >>>>> Having to provide multiple flags would make it just that little more >>>>> complex that it raises the barrier. >>>>> >>>>> I do think there's upstream value in allowing configuring a default >>>>> org for the broker though, but I don't think it should be part of this >>>>> proposal. >>>>> >>>>> On 12 January 2018 at 11:39, Phil Brookes wrote: >>>>> >>>>>> Hey Wojciech, >>>>>> >>>>>> Thanks a lot for the feedback. >>>>>> >>>>>> If I have understood you correctly, you are suggesting splitting this >>>>>> task in to two discrete pieces of work: >>>>>> >>>>>> - Add parameters to oc cluster up, to be able to configure the >>>>>> ansible-service-broker with custom docker credentials and docker org to >>>>>> pull in the ASBs from. >>>>>> - Add the ?mobile flag to enable the Mobile-Core UI extension. >>>>>> >>>>>> With the intention of making this an easier change to adopt. >>>>>> >>>>>> If that is correct then I am happy to proceed this way and I can >>>>>> update the proposal to reflect this as a route to implementation. >>>>>> >>>>>> Maybe it would be best to bring this discussion to the proposal so >>>>>> that the OpenShift team also have access to it? >>>>>> >>>>>> Thanks, >>>>>> Phil. >>>>>> ? >>>>>> >>>>>> On Fri, Jan 12, 2018 at 11:21 AM, Wojciech Trocki >>>>> > wrote: >>>>>> >>>>>>> Mobile flag as it doesn't provide ability to change values and >>>>>>> imposes some hard dependencies. >>>>>>> That may be hard accept and maintain on upstream. >>>>>>> Upstream works by generalization so if we want to contribute there >>>>>>> it's best to pass something that can be used by many people. >>>>>>> >>>>>>> How about `oc cluster up --service-broker=true >>>>>>> --service-broker-org=aerogearcatalog` and whatever else we need? >>>>>>> That's easier to accept and contribute upstream. >>>>>>> I have done changes for cluster up recently so if you need anything >>>>>>> in that let me know - we can work on this together. >>>>>>> >>>>>>> Another idea is to specify oc cluster up pre/post actions (hooks) >>>>>>> that will allow people to run ansible roles for things we need. >>>>>>> That will be solid proposal that upstream may consider. >>>>>>> >>>>>>> Developers can still have simple command by doing alias: >>>>>>> >>>>>>> >>>>>>> *alias oc-mobile-up=`oc cluster up --service-broker=true >>>>>>> --service-broker-org=aerogearcatalog` * >>>>>>> >>>>>>> >>>>>>> On Fri, Jan 12, 2018 at 10:51 AM, David Ffrench >>>>>> > wrote: >>>>>>> >>>>>>>> Fantastic Phil, This is 100% needed in my opinion. The mobile >>>>>>>> services need to be a first class citizen in OpenShift to ensure easy setup >>>>>>>> and adoption. >>>>>>>> >>>>>>>> DAVID FFRENCH >>>>>>>> >>>>>>>> senior software engineer, RED HAT MOBILE >>>>>>>> >>>>>>>> Red Hat Waterford >>>>>>>> >>>>>>>> Communications House, Cork Road >>>>>>>> >>>>>>>> Waterford, Ireland >>>>>>>> >>>>>>>> dffrench at redhat.com >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Jan 12, 2018 at 10:36 AM, Matthias Wessendorf < >>>>>>>> mwessend at redhat.com> wrote: >>>>>>>> >>>>>>>>> +9001 >>>>>>>>> >>>>>>>>> On Fri, Jan 12, 2018 at 11:26 AM, Phil Brookes < >>>>>>>>> pbrookes at redhat.com> wrote: >>>>>>>>> >>>>>>>>>> Hey Everyone, >>>>>>>>>> >>>>>>>>>> I have opened a proposal with the OpenShift team, hoping to start >>>>>>>>>> a discussion around the addition of a --mobile=true flag to the oc >>>>>>>>>> cluster up command. Running oc cluster up --mobile=true will >>>>>>>>>> start a local OpenShift cluster with all of the MCP features enabled. >>>>>>>>>> >>>>>>>>>> This would be a great way for us to gain some exposure for the >>>>>>>>>> Mobile Core and get it into the hands of developers more quickly and >>>>>>>>>> easily, so I?d love to see you share your thoughts on this idea. You can >>>>>>>>>> review / comment / support it here: >>>>>>>>>> https://github.com/openshift/origin/issues/18089 >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Phil. >>>>>>>>>> ? >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Project lead AeroGear.org >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> feedhenry-dev mailing list >>>>>>>> feedhenry-dev at redhat.com >>>>>>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> WOJCIECH TROCKI >>>>>>> >>>>>>> Red Hat Mobile >>>>>>> >>>>>>> IM: wtrocki >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> David Martin >>>>> Red Hat Mobile >>>>> Twitter: @irldavem >>>>> IRC: @irldavem (#aerogear) >>>>> >>>> >>>> >>>> >>>> -- >>>> Craig Brookes >>>> RHMAP >>>> @maleck13 Github >>>> >>> >>> >> >> >> -- >> Project lead AeroGear.org >> > > > > -- > Craig Brookes > RHMAP > @maleck13 Github > -------------- 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 Fri Jan 12 12:21:07 2018 From: mwessend at redhat.com (Matthias Wessendorf) Date: Fri, 12 Jan 2018 13:21:07 +0100 Subject: [feedhenry-dev] Proposal for addition of --mobile flag to oc cluster up In-Reply-To: References: Message-ID: I was about to say, that I'd be not surprised if there is not that much interest in brining this in... Currently they have "oc cluster ACTION [options]", and for the "up" action, they list a bunch of options, including installing (experimental) bits, like: Cassandra/Hawkular), via the --metrics option On Fri, Jan 12, 2018 at 1:15 PM, Craig Brookes wrote: > While that is an interesting proposal around the addons, I would suggest > waiting for the OpenShift team to get back on your issue. Adding a plugin > structure to oc is likely a much bigger piece of work and need a lot more > engagement from the OpenShift team. > That doesn't mean a different proposal for this approach could not be made > however, but rather that our current proposal covers our immediate need and > has clear prior art. > > On Fri, Jan 12, 2018 at 12:06 PM, Matthias Wessendorf > wrote: > >> I'd actually prefer more --mobile - which than does exactly what we need >> >> On Fri, Jan 12, 2018 at 1:04 PM, Phil Brookes >> wrote: >> >>> I?ve discussed this privately with Wojciech as I had misunderstood his >>> suggestion, so here?s my attempt to clarify the discussion: >>> >>> Rather than inserting our mobile oriented tasks into the upstream tool >>> (oc), which doesn?t provide value to all users of that tool but rather only >>> to the users who are interested in the mobile use-case; we should instead >>> modify the tool so that it can accept addons, similar (ideally, identical) >>> to minishift addons. >>> >>> The proposal here would be something like: >>> >>> oc cluster addons install mobilecore >>> oc cluster addons enable mobilecore >>> oc cluster up >>> >>> There a few benefits to this solution: >>> >>> - There is a clear value-add to the upstream tool >>> - We only need to maintain one mobilecore plugin for both minishift >>> and oc cluster up >>> - The barrier to entry for mobile developers is low >>> - The process for setting up a local cluster is the same with both >>> tools >>> - Future changes to the setup process of the Mobile-Core can be >>> submitted to our own repo >>> >>> ?@Wojciech please correct me, if I?ve still misunderstood anything!? >>> >>> Regards, >>> Phil. >>> ? >>> >>> On Fri, Jan 12, 2018 at 11:55 AM, Craig Brookes >>> wrote: >>> >>>> +1 >>>> >>>> On Fri, Jan 12, 2018 at 11:46 AM, David Martin >>>> wrote: >>>> >>>>> I think there's great value in --mobile flag. >>>>> Its the same approach for metrics and logging (--metrics, --logging) >>>>> >>>>> It would do everything needed to enable the mobile extension and get >>>>> the cluster into the state we want. >>>>> Having to provide multiple flags would make it just that little more >>>>> complex that it raises the barrier. >>>>> >>>>> I do think there's upstream value in allowing configuring a default >>>>> org for the broker though, but I don't think it should be part of this >>>>> proposal. >>>>> >>>>> On 12 January 2018 at 11:39, Phil Brookes wrote: >>>>> >>>>>> Hey Wojciech, >>>>>> >>>>>> Thanks a lot for the feedback. >>>>>> >>>>>> If I have understood you correctly, you are suggesting splitting this >>>>>> task in to two discrete pieces of work: >>>>>> >>>>>> - Add parameters to oc cluster up, to be able to configure the >>>>>> ansible-service-broker with custom docker credentials and docker org to >>>>>> pull in the ASBs from. >>>>>> - Add the ?mobile flag to enable the Mobile-Core UI extension. >>>>>> >>>>>> With the intention of making this an easier change to adopt. >>>>>> >>>>>> If that is correct then I am happy to proceed this way and I can >>>>>> update the proposal to reflect this as a route to implementation. >>>>>> >>>>>> Maybe it would be best to bring this discussion to the proposal so >>>>>> that the OpenShift team also have access to it? >>>>>> >>>>>> Thanks, >>>>>> Phil. >>>>>> ? >>>>>> >>>>>> On Fri, Jan 12, 2018 at 11:21 AM, Wojciech Trocki >>>>> > wrote: >>>>>> >>>>>>> Mobile flag as it doesn't provide ability to change values and >>>>>>> imposes some hard dependencies. >>>>>>> That may be hard accept and maintain on upstream. >>>>>>> Upstream works by generalization so if we want to contribute there >>>>>>> it's best to pass something that can be used by many people. >>>>>>> >>>>>>> How about `oc cluster up --service-broker=true >>>>>>> --service-broker-org=aerogearcatalog` and whatever else we need? >>>>>>> That's easier to accept and contribute upstream. >>>>>>> I have done changes for cluster up recently so if you need anything >>>>>>> in that let me know - we can work on this together. >>>>>>> >>>>>>> Another idea is to specify oc cluster up pre/post actions (hooks) >>>>>>> that will allow people to run ansible roles for things we need. >>>>>>> That will be solid proposal that upstream may consider. >>>>>>> >>>>>>> Developers can still have simple command by doing alias: >>>>>>> >>>>>>> >>>>>>> *alias oc-mobile-up=`oc cluster up --service-broker=true >>>>>>> --service-broker-org=aerogearcatalog` * >>>>>>> >>>>>>> >>>>>>> On Fri, Jan 12, 2018 at 10:51 AM, David Ffrench >>>>>> > wrote: >>>>>>> >>>>>>>> Fantastic Phil, This is 100% needed in my opinion. The mobile >>>>>>>> services need to be a first class citizen in OpenShift to ensure easy setup >>>>>>>> and adoption. >>>>>>>> >>>>>>>> DAVID FFRENCH >>>>>>>> >>>>>>>> senior software engineer, RED HAT MOBILE >>>>>>>> >>>>>>>> Red Hat Waterford >>>>>>>> >>>>>>>> Communications House, Cork Road >>>>>>>> >>>>>>>> Waterford, Ireland >>>>>>>> >>>>>>>> dffrench at redhat.com >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Jan 12, 2018 at 10:36 AM, Matthias Wessendorf < >>>>>>>> mwessend at redhat.com> wrote: >>>>>>>> >>>>>>>>> +9001 >>>>>>>>> >>>>>>>>> On Fri, Jan 12, 2018 at 11:26 AM, Phil Brookes < >>>>>>>>> pbrookes at redhat.com> wrote: >>>>>>>>> >>>>>>>>>> Hey Everyone, >>>>>>>>>> >>>>>>>>>> I have opened a proposal with the OpenShift team, hoping to start >>>>>>>>>> a discussion around the addition of a --mobile=true flag to the oc >>>>>>>>>> cluster up command. Running oc cluster up --mobile=true will >>>>>>>>>> start a local OpenShift cluster with all of the MCP features enabled. >>>>>>>>>> >>>>>>>>>> This would be a great way for us to gain some exposure for the >>>>>>>>>> Mobile Core and get it into the hands of developers more quickly and >>>>>>>>>> easily, so I?d love to see you share your thoughts on this idea. You can >>>>>>>>>> review / comment / support it here: >>>>>>>>>> https://github.com/openshift/origin/issues/18089 >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Phil. >>>>>>>>>> ? >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Project lead AeroGear.org >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> feedhenry-dev mailing list >>>>>>>> feedhenry-dev at redhat.com >>>>>>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> WOJCIECH TROCKI >>>>>>> >>>>>>> Red Hat Mobile >>>>>>> >>>>>>> IM: wtrocki >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> David Martin >>>>> Red Hat Mobile >>>>> Twitter: @irldavem >>>>> IRC: @irldavem (#aerogear) >>>>> >>>> >>>> >>>> >>>> -- >>>> Craig Brookes >>>> RHMAP >>>> @maleck13 Github >>>> >>> >>> >> >> >> -- >> Project lead AeroGear.org >> > > > > -- > Craig Brookes > RHMAP > @maleck13 Github > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbraun at redhat.com Fri Jan 12 13:35:18 2018 From: pbraun at redhat.com (Peter Braun) Date: Fri, 12 Jan 2018 14:35:18 +0100 Subject: [feedhenry-dev] Proposal for addition of --mobile flag to oc cluster up In-Reply-To: References: Message-ID: If we stick with the ?mobile flag proposal setting up the service broker and default org is not enough. Don?t we need to install our custom resource definitions too? > Am 12.01.2018 um 13:21 schrieb Matthias Wessendorf : > > I was about to say, that I'd be not surprised if there is not that much interest in brining this in... > > Currently they have "oc cluster ACTION [options]", > > and for the "up" action, they list a bunch of options, including installing (experimental) bits, like: Cassandra/Hawkular), via the --metrics option > > On Fri, Jan 12, 2018 at 1:15 PM, Craig Brookes > wrote: > While that is an interesting proposal around the addons, I would suggest waiting for the OpenShift team to get back on your issue. Adding a plugin structure to oc is likely a much bigger piece of work and need a lot more engagement from the OpenShift team. > That doesn't mean a different proposal for this approach could not be made however, but rather that our current proposal covers our immediate need and has clear prior art. > > On Fri, Jan 12, 2018 at 12:06 PM, Matthias Wessendorf > wrote: > I'd actually prefer more --mobile - which than does exactly what we need > > On Fri, Jan 12, 2018 at 1:04 PM, Phil Brookes > wrote: > I?ve discussed this privately with Wojciech as I had misunderstood his suggestion, so here?s my attempt to clarify the discussion: > > Rather than inserting our mobile oriented tasks into the upstream tool (oc), which doesn?t provide value to all users of that tool but rather only to the users who are interested in the mobile use-case; we should instead modify the tool so that it can accept addons, similar (ideally, identical) to minishift addons. > > The proposal here would be something like: > > oc cluster addons install mobilecore > oc cluster addons enable mobilecore > oc cluster up > There a few benefits to this solution: > > There is a clear value-add to the upstream tool > We only need to maintain one mobilecore plugin for both minishift and oc cluster up > The barrier to entry for mobile developers is low > The process for setting up a local cluster is the same with both tools > Future changes to the setup process of the Mobile-Core can be submitted to our own repo > ?@Wojciech please correct me, if I?ve still misunderstood anything!? > > Regards, > Phil. > > > On Fri, Jan 12, 2018 at 11:55 AM, Craig Brookes > wrote: > +1 > > On Fri, Jan 12, 2018 at 11:46 AM, David Martin > wrote: > I think there's great value in --mobile flag. > Its the same approach for metrics and logging (--metrics, --logging) > > It would do everything needed to enable the mobile extension and get the cluster into the state we want. > Having to provide multiple flags would make it just that little more complex that it raises the barrier. > > I do think there's upstream value in allowing configuring a default org for the broker though, but I don't think it should be part of this proposal. > > On 12 January 2018 at 11:39, Phil Brookes > wrote: > Hey Wojciech, > > Thanks a lot for the feedback. > > If I have understood you correctly, you are suggesting splitting this task in to two discrete pieces of work: > > Add parameters to oc cluster up, to be able to configure the ansible-service-broker with custom docker credentials and docker org to pull in the ASBs from. > Add the ?mobile flag to enable the Mobile-Core UI extension. > With the intention of making this an easier change to adopt. > > If that is correct then I am happy to proceed this way and I can update the proposal to reflect this as a route to implementation. > > Maybe it would be best to bring this discussion to the proposal so that the OpenShift team also have access to it? > > Thanks, > Phil. > > > On Fri, Jan 12, 2018 at 11:21 AM, Wojciech Trocki > wrote: > Mobile flag as it doesn't provide ability to change values and imposes some hard dependencies. > That may be hard accept and maintain on upstream. > Upstream works by generalization so if we want to contribute there it's best to pass something that can be used by many people. > > How about `oc cluster up --service-broker=true --service-broker-org=aerogearcatalog` and whatever else we need? > That's easier to accept and contribute upstream. > I have done changes for cluster up recently so if you need anything in that let me know - we can work on this together. > > Another idea is to specify oc cluster up pre/post actions (hooks) that will allow people to run ansible roles for things we need. > That will be solid proposal that upstream may consider. > > Developers can still have simple command by doing alias: > > alias oc-mobile-up=`oc cluster up --service-broker=true --service-broker-org=aerogearcatalog` > > > > On Fri, Jan 12, 2018 at 10:51 AM, David Ffrench > wrote: > Fantastic Phil, This is 100% needed in my opinion. The mobile services need to be a first class citizen in OpenShift to ensure easy setup and adoption. > > DAVID FFRENCH > SENIOR SOFTWARE ENGINEER, RED HAT MOBILE > Red Hat?Waterford > Communications House, Cork Road > Waterford, Ireland > dffrench at redhat.com > > > > > On Fri, Jan 12, 2018 at 10:36 AM, Matthias Wessendorf > wrote: > +9001 > > On Fri, Jan 12, 2018 at 11:26 AM, Phil Brookes > wrote: > Hey Everyone, > > I have opened a proposal with the OpenShift team, hoping to start a discussion around the addition of a --mobile=true flag to the oc cluster up command. Running oc cluster up --mobile=true will start a local OpenShift cluster with all of the MCP features enabled. > > This would be a great way for us to gain some exposure for the Mobile Core and get it into the hands of developers more quickly and easily, so I?d love to see you share your thoughts on this idea. You can review / comment / support it here: > https://github.com/openshift/origin/issues/18089 > Thanks, > Phil. > > > > > -- > Project lead AeroGear.org > > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > > > > -- > WOJCIECH TROCKI > Red Hat?Mobile > IM: wtrocki > > > > > > -- > David Martin > Red Hat Mobile > Twitter: @irldavem > IRC: @irldavem (#aerogear) > > > > -- > Craig Brookes > RHMAP > @maleck13 Github > > > > > -- > Project lead AeroGear.org > > > > -- > Craig Brookes > RHMAP > @maleck13 Github > > > > -- > Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Fri Jan 12 14:22:11 2018 From: mwessend at redhat.com (Matthias Wessendorf) Date: Fri, 12 Jan 2018 15:22:11 +0100 Subject: [feedhenry-dev] Demo: Prometheus auto discovery In-Reply-To: References: <567403EF-DADB-4234-8618-F41DAD1B3FB1@redhat.com> Message-ID: for ups we have started to collect some simple metrics, and exposed via the annotation (in the apb) On Fri, Jan 12, 2018 at 12:40 PM, David Martin wrote: > Nice Video Ali! > It really shows how easy it can be to start capturing metrics from your > app. > That's 1 of the main goals of the Metrics Service > > (The other main goal being the capture of metrics for mobile services like > sync, push, keyclaok etc...) > > On 12 January 2018 at 11:30, Peter Braun wrote: > >> great Demo! >> >> Am 12.01.2018 um 11:51 schrieb Ali Ok : >> >> Hi, >> >> I created a video, demonstrating Prometheus auto discovery that is >> configured in metrics-apb[1]: https://www.youtube.com/watch?v=AC_Xet-B1fY >> >> This video is an educational video that doesn't use FH-Sync or any other >> FH-service as the metrics target. Instead, I wrote a very simple >> lightweight node application [2] that serves the purpose of experimenting >> with Prometheus on OpenShift better. >> >> This video is something I prepared very quickly in addition to the video >> that will be made soon featuring the metrics solution [3]. >> >> [1]: https://github.com/aerogearcatalog/metrics-apb >> [2]: https://github.com/aliok/node-app-with-prometheus-metrics >> [3]: https://issues.jboss.org/browse/AEROGEAR-1797 >> >> Cheers, >> Ali >> _______________________________________________ >> 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 (#aerogear) > > _______________________________________________ > 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 wtrocki at redhat.com Fri Jan 12 14:27:09 2018 From: wtrocki at redhat.com (Wojciech Trocki) Date: Fri, 12 Jan 2018 14:27:09 +0000 Subject: [feedhenry-dev] Proposal for addition of --mobile flag to oc cluster up In-Reply-To: References: Message-ID: Reason why I proposed that is having mobile flag is harder to accept and it will impose limitations from the beginning on our system as some details will be hardcoded into openshift client. I also see problems with maintaining this flag, handling multiple versions of clients etc. Mobile flag has also a lots of functionalities behind so it will take a while to explain and understand all requirements/impacts. While entire idea is brilliant I wanted to propose additional aproach (without rejecting original idea or proposal which is fine to have). IMHO Starting by small steps will help us with acceptance - not all changes will be accepted, but some of them will be. Having more than 4-5 contributors will help us a lot. We can establish community working group and propose things we care about. Have some part in openshift ecosystem. To do that we will be able to get more contributors and eventually it may lead us to something like mobile flag. This is what RedHat does a lot - see node.js, docker, kubernetes example. IMHO Best for changes to be done in some small steps and by different people to get more contributors and recognition in community. We already have strong presence in ASB thanks to Craig. This why in my own opinion* oc cluster up --metrics* is not the same as *oc cluster up --mobile* Metrics team is backed and supported by working group. It's also part of their documentation. > ?@Wojciech please correct me, if I?ve still misunderstood anything!? That sounds great! Plus change mentioned before > Add parameters to oc cluster up, to be able to configure the ansible-service-broker with custom docker credentials and docker org to pull in the ASBs from. There also many initiatives around `oc cluster up` based on ideas that were not be acceptable upstream. Good example: https://github.com/openshift-evangelists/oc-cluster-wrapper See oc-cluster-wrapper plugins: https://github.com/openshift-evangelists/oc-cluster-wrapper/tree/master/plugins.d On Fri, Jan 12, 2018 at 1:35 PM, Peter Braun wrote: > If we stick with the ?mobile flag proposal setting up the service broker > and default org is not enough. Don?t we need to install our custom resource > definitions too? > > > Am 12.01.2018 um 13:21 schrieb Matthias Wessendorf : > > I was about to say, that I'd be not surprised if there is not that much > interest in brining this in... > > Currently they have "oc cluster ACTION [options]", > > and for the "up" action, they list a bunch of options, including > installing (experimental) bits, like: Cassandra/Hawkular), via the > --metrics option > > On Fri, Jan 12, 2018 at 1:15 PM, Craig Brookes > wrote: > >> While that is an interesting proposal around the addons, I would suggest >> waiting for the OpenShift team to get back on your issue. Adding a plugin >> structure to oc is likely a much bigger piece of work and need a lot more >> engagement from the OpenShift team. >> That doesn't mean a different proposal for this approach could not be >> made however, but rather that our current proposal covers our immediate >> need and has clear prior art. >> >> On Fri, Jan 12, 2018 at 12:06 PM, Matthias Wessendorf < >> mwessend at redhat.com> wrote: >> >>> I'd actually prefer more --mobile - which than does exactly what we need >>> >>> On Fri, Jan 12, 2018 at 1:04 PM, Phil Brookes >>> wrote: >>> >>>> I?ve discussed this privately with Wojciech as I had misunderstood his >>>> suggestion, so here?s my attempt to clarify the discussion: >>>> >>>> Rather than inserting our mobile oriented tasks into the upstream tool >>>> (oc), which doesn?t provide value to all users of that tool but rather only >>>> to the users who are interested in the mobile use-case; we should instead >>>> modify the tool so that it can accept addons, similar (ideally, identical) >>>> to minishift addons. >>>> >>>> The proposal here would be something like: >>>> >>>> oc cluster addons install mobilecore >>>> oc cluster addons enable mobilecore >>>> oc cluster up >>>> >>>> There a few benefits to this solution: >>>> >>>> - There is a clear value-add to the upstream tool >>>> - We only need to maintain one mobilecore plugin for both minishift >>>> and oc cluster up >>>> - The barrier to entry for mobile developers is low >>>> - The process for setting up a local cluster is the same with both >>>> tools >>>> - Future changes to the setup process of the Mobile-Core can be >>>> submitted to our own repo >>>> >>>> ?@Wojciech please correct me, if I?ve still misunderstood anything!? >>>> >>>> Regards, >>>> Phil. >>>> ? >>>> >>>> On Fri, Jan 12, 2018 at 11:55 AM, Craig Brookes >>>> wrote: >>>> >>>>> +1 >>>>> >>>>> On Fri, Jan 12, 2018 at 11:46 AM, David Martin >>>>> wrote: >>>>> >>>>>> I think there's great value in --mobile flag. >>>>>> Its the same approach for metrics and logging (--metrics, --logging) >>>>>> >>>>>> It would do everything needed to enable the mobile extension and get >>>>>> the cluster into the state we want. >>>>>> Having to provide multiple flags would make it just that little more >>>>>> complex that it raises the barrier. >>>>>> >>>>>> I do think there's upstream value in allowing configuring a default >>>>>> org for the broker though, but I don't think it should be part of this >>>>>> proposal. >>>>>> >>>>>> On 12 January 2018 at 11:39, Phil Brookes >>>>>> wrote: >>>>>> >>>>>>> Hey Wojciech, >>>>>>> >>>>>>> Thanks a lot for the feedback. >>>>>>> >>>>>>> If I have understood you correctly, you are suggesting splitting >>>>>>> this task in to two discrete pieces of work: >>>>>>> >>>>>>> - Add parameters to oc cluster up, to be able to configure the >>>>>>> ansible-service-broker with custom docker credentials and docker org to >>>>>>> pull in the ASBs from. >>>>>>> - Add the ?mobile flag to enable the Mobile-Core UI extension. >>>>>>> >>>>>>> With the intention of making this an easier change to adopt. >>>>>>> >>>>>>> If that is correct then I am happy to proceed this way and I can >>>>>>> update the proposal to reflect this as a route to implementation. >>>>>>> >>>>>>> Maybe it would be best to bring this discussion to the proposal so >>>>>>> that the OpenShift team also have access to it? >>>>>>> >>>>>>> Thanks, >>>>>>> Phil. >>>>>>> ? >>>>>>> >>>>>>> On Fri, Jan 12, 2018 at 11:21 AM, Wojciech Trocki < >>>>>>> wtrocki at redhat.com> wrote: >>>>>>> >>>>>>>> Mobile flag as it doesn't provide ability to change values and >>>>>>>> imposes some hard dependencies. >>>>>>>> That may be hard accept and maintain on upstream. >>>>>>>> Upstream works by generalization so if we want to contribute there >>>>>>>> it's best to pass something that can be used by many people. >>>>>>>> >>>>>>>> How about `oc cluster up --service-broker=true >>>>>>>> --service-broker-org=aerogearcatalog` and whatever else we need? >>>>>>>> That's easier to accept and contribute upstream. >>>>>>>> I have done changes for cluster up recently so if you need anything >>>>>>>> in that let me know - we can work on this together. >>>>>>>> >>>>>>>> Another idea is to specify oc cluster up pre/post actions (hooks) >>>>>>>> that will allow people to run ansible roles for things we need. >>>>>>>> That will be solid proposal that upstream may consider. >>>>>>>> >>>>>>>> Developers can still have simple command by doing alias: >>>>>>>> >>>>>>>> >>>>>>>> *alias oc-mobile-up=`oc cluster up --service-broker=true >>>>>>>> --service-broker-org=aerogearcatalog` * >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Jan 12, 2018 at 10:51 AM, David Ffrench < >>>>>>>> dffrench at redhat.com> wrote: >>>>>>>> >>>>>>>>> Fantastic Phil, This is 100% needed in my opinion. The mobile >>>>>>>>> services need to be a first class citizen in OpenShift to ensure easy setup >>>>>>>>> and adoption. >>>>>>>>> >>>>>>>>> DAVID FFRENCH >>>>>>>>> >>>>>>>>> senior software engineer, RED HAT MOBILE >>>>>>>>> Red Hat Waterford >>>>>>>>> Communications House, Cork Road >>>>>>>>> Waterford, Ireland >>>>>>>>> >>>>>>>>> dffrench at redhat.com >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, Jan 12, 2018 at 10:36 AM, Matthias Wessendorf < >>>>>>>>> mwessend at redhat.com> wrote: >>>>>>>>> >>>>>>>>>> +9001 >>>>>>>>>> >>>>>>>>>> On Fri, Jan 12, 2018 at 11:26 AM, Phil Brookes < >>>>>>>>>> pbrookes at redhat.com> wrote: >>>>>>>>>> >>>>>>>>>>> Hey Everyone, >>>>>>>>>>> >>>>>>>>>>> I have opened a proposal with the OpenShift team, hoping to >>>>>>>>>>> start a discussion around the addition of a --mobile=true flag >>>>>>>>>>> to the oc cluster up command. Running oc cluster up >>>>>>>>>>> --mobile=true will start a local OpenShift cluster with all of >>>>>>>>>>> the MCP features enabled. >>>>>>>>>>> >>>>>>>>>>> This would be a great way for us to gain some exposure for the >>>>>>>>>>> Mobile Core and get it into the hands of developers more quickly and >>>>>>>>>>> easily, so I?d love to see you share your thoughts on this idea. You can >>>>>>>>>>> review / comment / support it here: >>>>>>>>>>> https://github.com/openshift/origin/issues/18089 >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Phil. >>>>>>>>>>> ? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Project lead AeroGear.org >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> feedhenry-dev mailing list >>>>>>>>> feedhenry-dev at redhat.com >>>>>>>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> WOJCIECH TROCKI >>>>>>>> Red Hat Mobile >>>>>>>> >>>>>>>> IM: wtrocki >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> David Martin >>>>>> Red Hat Mobile >>>>>> Twitter: @irldavem >>>>>> IRC: @irldavem (#aerogear) >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Craig Brookes >>>>> RHMAP >>>>> @maleck13 Github >>>>> >>>> >>>> >>> >>> >>> -- >>> Project lead AeroGear.org >>> >> >> >> >> -- >> Craig Brookes >> RHMAP >> @maleck13 Github >> > > > > -- > Project lead AeroGear.org > > > > _______________________________________________ > 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 phajidec at redhat.com Fri Jan 12 14:31:30 2018 From: phajidec at redhat.com (Paolo Haji) Date: Fri, 12 Jan 2018 12:31:30 -0200 Subject: [feedhenry-dev] Demo: Prometheus auto discovery In-Reply-To: References: Message-ID: Awesome video! Do you think it would be outside of the scope of the original example app to include the sample random metrics gauge and perhaps other metrics gathering? I believe this could be a nice contribution to it. On Fri, Jan 12, 2018 at 8:51 AM, Ali Ok wrote: > Hi, > > I created a video, demonstrating Prometheus auto discovery that is > configured in metrics-apb[1]: https://www.youtube.com/watch?v=AC_Xet-B1fY > > This video is an educational video that doesn't use FH-Sync or any other > FH-service as the metrics target. Instead, I wrote a very simple > lightweight node application [2] that serves the purpose of experimenting > with Prometheus on OpenShift better. > > This video is something I prepared very quickly in addition to the video > that will be made soon featuring the metrics solution [3]. > > [1]: https://github.com/aerogearcatalog/metrics-apb > [2]: https://github.com/aliok/node-app-with-prometheus-metrics > [3]: https://issues.jboss.org/browse/AEROGEAR-1797 > > Cheers, > Ali > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- PAOLO HAJI SOFTWARE ENGINEER, RED HAT MOBILE APPLICATION PLATFORM Red Hat Brasil phaji at redhat.com TRIED. TESTED. TRUSTED. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aliok at redhat.com Mon Jan 15 07:48:05 2018 From: aliok at redhat.com (Ali Ok) Date: Mon, 15 Jan 2018 10:48:05 +0300 Subject: [feedhenry-dev] Demo: Prometheus auto discovery In-Reply-To: References: Message-ID: Hi Paolo, Good idea. I created an issue for that app: https://github.com/openshift/nodejs-ex/issues/161 Let's see what they think. Cheers On Fri, Jan 12, 2018 at 5:31 PM, Paolo Haji wrote: > Awesome video! > > Do you think it would be outside of the scope of the original example app > to include the sample random metrics gauge and perhaps other metrics > gathering? > I believe this could be a nice contribution to it. > > On Fri, Jan 12, 2018 at 8:51 AM, Ali Ok wrote: > >> Hi, >> >> I created a video, demonstrating Prometheus auto discovery that is >> configured in metrics-apb[1]: https://www.youtube.com/watch?v=AC_Xet-B1fY >> >> This video is an educational video that doesn't use FH-Sync or any other >> FH-service as the metrics target. Instead, I wrote a very simple >> lightweight node application [2] that serves the purpose of experimenting >> with Prometheus on OpenShift better. >> >> This video is something I prepared very quickly in addition to the video >> that will be made soon featuring the metrics solution [3]. >> >> [1]: https://github.com/aerogearcatalog/metrics-apb >> [2]: https://github.com/aliok/node-app-with-prometheus-metrics >> [3]: https://issues.jboss.org/browse/AEROGEAR-1797 >> >> Cheers, >> Ali >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > > -- > > PAOLO HAJI > > SOFTWARE ENGINEER, RED HAT MOBILE APPLICATION PLATFORM > > Red Hat Brasil > > phaji at redhat.com > > TRIED. TESTED. TRUSTED. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From supittma at redhat.com Mon Jan 15 14:15:09 2018 From: supittma at redhat.com (Summers Pittman) Date: Mon, 15 Jan 2018 09:15:09 -0500 Subject: [feedhenry-dev] Android Pair Programming session Message-ID: Hey guys, Wojciech and I are going to PP through some questions he has on the proposal (https://github.com/aerogear/proposals/pull/9)at the top of the hour. (10 AM Eastern). Everyone is welcome to join in my bluejeans, if you need the link ask me in IRC. Summers -------------- next part -------------- An HTML attachment was scrubbed... URL: From wtrocki at redhat.com Mon Jan 15 11:17:09 2018 From: wtrocki at redhat.com (Wojciech Trocki) Date: Mon, 15 Jan 2018 11:17:09 +0000 Subject: [feedhenry-dev] [aerogear-dev] Mitigating ML problems In-Reply-To: References: Message-ID: Leaving small update here. New group was created by Matthias today. Email: *aerogear at googlegroups.com * Group web panel: *https://groups.google.com/forum/#!forum/aerogear * We can include it now when creating new topics for aerogear and decide to move at some point if we find it better/ more stable. Regards On Fri, Jan 12, 2018 at 6:51 AM, Matthias Wessendorf wrote: > I am perfectly fine w/ moving toward google groups > > On Wed, Jan 10, 2018 at 5:35 PM, John Frizelle > wrote: > >> Hi All, >> >> Until such time as we get confirmation that the problems with delivery to >> the arergrear-dev ML have been fixed (or we migrate from mailman to a >> public google group for the ML), can I ask that ALL mail sent to the >> aerogear-dev ML is also sent to the other 2 MLs on this thread - >> feedhenry-dev and mobile-dev. >> >> I know this is a bit of a pain, but it's even more painful to not have >> mails delivered in a timely fashion. >> >> I know there has been suggestions made to move from mailman to Google >> Groups already, but not sure where these discussions are at... Is there >> anything preventing us making this jump - the mailman ML problem has been >> ongoing for quite some time now with no resolution in sight that I am aware >> of, so perhaps it's time to look at moving to Google Groups? >> >> 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 * >> >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > github: https://github.com/matzew > 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 davmarti at redhat.com Tue Jan 16 09:34:03 2018 From: davmarti at redhat.com (David Martin) Date: Tue, 16 Jan 2018 09:34:03 +0000 Subject: [feedhenry-dev] Priority & Ordering of some stories for upcoming sprint Message-ID: Hi all, Sharing some thoughts on priority and ordering to help with the focus of the upcoming sprint. Before we can do this: As a DevOps Engineer I want to be able to visualise data provided by the other services on an overview / dashboard screen [met] https://trello.com/c/SQsfFS34/4-as-a-devops-engineer-i-want-to-be-able-to-visualise-data-provided-by-the-other-services-on-an-overview-dashboard-screen-met I think we need to do this: As a developer I want to be able to expose metrics data about Identity Management in prometheus format from an endpoint of the service [idm] https://trello.com/c/NgXh76Oi/6-as-a-developer-i-want-to-be-able-to-expose-metrics-data-about-identity-management-in-prometheus-format-from-an-endpoint-of-the-s It would help a lot to have an example to focus on and build out first, which would also give us a great reference for future visualization integrations. There is a working example already with keycloak and grafana, but they were for the proof of concept. Doing these stories should be focusing on something more complete, documented, well tested and maintainable. Thoughts anyone? -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (#aerogear) -------------- next part -------------- An HTML attachment was scrubbed... URL: From akeating at redhat.com Tue Jan 16 10:10:38 2018 From: akeating at redhat.com (Aiden Keating) Date: Tue, 16 Jan 2018 10:10:38 +0000 Subject: [feedhenry-dev] Priority & Ordering of some stories for upcoming sprint In-Reply-To: References: Message-ID: To give some context on what has already been done. This spike contains a bunch of information about the work already done on the Keycloak metrics story. https://issues.jboss.org/browse/AEROGEAR-1776 Thanks, Aiden On Tue, Jan 16, 2018 at 9:34 AM, David Martin wrote: > Hi all, > > Sharing some thoughts on priority and ordering to help with the focus of > the upcoming sprint. > > Before we can do this: > As a DevOps Engineer I want to be able to visualise data provided by the > other services on an overview / dashboard screen [met] > https://trello.com/c/SQsfFS34/4-as-a-devops-engineer-i-want- > to-be-able-to-visualise-data-provided-by-the-other- > services-on-an-overview-dashboard-screen-met > > I think we need to do this: > As a developer I want to be able to expose metrics data about Identity > Management in prometheus format from an endpoint of the service [idm] > https://trello.com/c/NgXh76Oi/6-as-a-developer-i-want-to-be- > able-to-expose-metrics-data-about-identity-management-in- > prometheus-format-from-an-endpoint-of-the-s > > > It would help a lot to have an example to focus on and build out first, > which would also give us a great reference for future visualization > integrations. > > There is a working example already with keycloak and grafana, but they > were for the proof of concept. Doing these stories should be focusing on > something more complete, documented, well tested and maintainable. > > Thoughts anyone? > > > > -- > David Martin > Red Hat Mobile > Twitter: @irldavem > IRC: @irldavem (#aerogear) > > _______________________________________________ > 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 davmarti at redhat.com Tue Jan 16 11:53:28 2018 From: davmarti at redhat.com (David Martin) Date: Tue, 16 Jan 2018 11:53:28 +0000 Subject: [feedhenry-dev] Priority & Ordering of some stories for upcoming sprint In-Reply-To: References: Message-ID: I've added an event to the shared calendar for tomorrow (12:30 UTC). I've included some names on it, but anyone is welcome to join. Keycloak Metrics & Grafana Knowledge Sharing & Discussion Aiden will share what was done for keycloak metrics for the poc, and his thoughts on where it could be taken. After that, we can discuss what we should do to deliver the 2 trello stories Related mail thread: * http://lists.jboss.org/pipermail/aerogear-dev/2018-January/013275.html Trello stories that will drive the discussion: * As a DevOps Engineer I want to be able to visualise data provided by the other services on an overview / dashboard screen [met] https://trello.com/c/SQsfFS34/4-as-a-devops-engineer-i-want-to-be-able-to-visualise-data-provided-by-the-other-services-on-an-overview-dashboard-screen-met * As a developer I want to be able to expose metrics data about Identity Management in prometheus format from an endpoint of the service [idm] https://trello.com/c/NgXh76Oi/6-as-a-developer-i-want-to-be-able-to-expose-metrics-data-about-identity-management-in-prometheus-format-from-an-endpoint-of-the-s Jira with previous work: https://issues.jboss.org/browse/AEROGEAR-1776 On 16 January 2018 at 10:10, Aiden Keating wrote: > To give some context on what has already been done. This spike contains a > bunch of information about the work already done on the Keycloak metrics > story. > > https://issues.jboss.org/browse/AEROGEAR-1776 > > Thanks, > Aiden > > On Tue, Jan 16, 2018 at 9:34 AM, David Martin wrote: > >> Hi all, >> >> Sharing some thoughts on priority and ordering to help with the focus of >> the upcoming sprint. >> >> Before we can do this: >> As a DevOps Engineer I want to be able to visualise data provided by the >> other services on an overview / dashboard screen [met] >> https://trello.com/c/SQsfFS34/4-as-a-devops-engineer-i-want- >> to-be-able-to-visualise-data-provided-by-the-other-services- >> on-an-overview-dashboard-screen-met >> >> I think we need to do this: >> As a developer I want to be able to expose metrics data about Identity >> Management in prometheus format from an endpoint of the service [idm] >> https://trello.com/c/NgXh76Oi/6-as-a-developer-i-want-to-be- >> able-to-expose-metrics-data-about-identity-management-in-pro >> metheus-format-from-an-endpoint-of-the-s >> >> >> It would help a lot to have an example to focus on and build out first, >> which would also give us a great reference for future visualization >> integrations. >> >> There is a working example already with keycloak and grafana, but they >> were for the proof of concept. Doing these stories should be focusing on >> something more complete, documented, well tested and maintainable. >> >> Thoughts anyone? >> >> >> >> -- >> David Martin >> Red Hat Mobile >> Twitter: @irldavem >> IRC: @irldavem (#aerogear) >> >> _______________________________________________ >> 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 (#aerogear) -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwright at redhat.com Tue Jan 16 14:32:05 2018 From: pwright at redhat.com (Paul Wright) Date: Tue, 16 Jan 2018 14:32:05 +0000 Subject: [feedhenry-dev] Mitigating ML problems In-Reply-To: References: Message-ID: Hi, I'm posting now to the google group . Should I be cc'ing feedhenry-dev and mobile-dev still? Paul On 01/10/2018 04:35 PM, John Frizelle wrote: > Hi All, > > Until such time as we get confirmation that the problems with delivery > to the arergrear-dev ML have been fixed (or we migrate from mailman to > a public google group for the ML), can I ask that ALL mail sent to the > aerogear-dev ML is also sent to the other 2 MLs on this thread - > feedhenry-dev and mobile-dev. > > I know this is a bit of a pain, but it's even more painful to not have > mails delivered in a timely fashion. > > I know there has been suggestions made to move from mailman to Google > Groups already, but not sure where these discussions are at... Is > there anything preventing us making this jump - the mailman ML problem > has been ongoing for quite some time now with no resolution in sight > that I am aware of, so perhaps it's time to look at moving to Google > Groups? > > 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 * > > > > > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev -- Paul Wright Mobile Docs (github: finp) -------------- 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 Tue Jan 16 14:41:47 2018 From: mwessend at redhat.com (Matthias Wessendorf) Date: Tue, 16 Jan 2018 15:41:47 +0100 Subject: [feedhenry-dev] Mitigating ML problems In-Reply-To: References: Message-ID: mobile-dev is an internal one, while feedhenry-dev is a public list - I'd not mix internal and external lists, since the internal ones are not visible for community users On Tue, Jan 16, 2018 at 3:32 PM, Paul Wright wrote: > Hi, > > I'm posting now to the google group > . > > Should I be cc'ing feedhenry-dev and mobile-dev still? > > Paul > On 01/10/2018 04:35 PM, John Frizelle wrote: > > Hi All, > > Until such time as we get confirmation that the problems with delivery to > the arergrear-dev ML have been fixed (or we migrate from mailman to a > public google group for the ML), can I ask that ALL mail sent to the > aerogear-dev ML is also sent to the other 2 MLs on this thread - > feedhenry-dev and mobile-dev. > > I know this is a bit of a pain, but it's even more painful to not have > mails delivered in a timely fashion. > > I know there has been suggestions made to move from mailman to Google > Groups already, but not sure where these discussions are at... Is there > anything preventing us making this jump - the mailman ML problem has been > ongoing for quite some time now with no resolution in sight that I am aware > of, so perhaps it's time to look at moving to Google Groups? > > 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 * > > > > > > _______________________________________________ > feedhenry-dev mailing listfeedhenry-dev at redhat.comhttps://www.redhat.com/mailman/listinfo/feedhenry-dev > > > -- > Paul Wright > Mobile Docs (github: finp) > > > _______________________________________________ > 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: From jgallaso at redhat.com Wed Jan 17 15:06:58 2018 From: jgallaso at redhat.com (Jose Miguel Gallas Olmedo) Date: Wed, 17 Jan 2018 16:06:58 +0100 Subject: [feedhenry-dev] Exception occurred! 'namespace' Message-ID: Hi, I am getting an error when trying to push an APB to my local Openshift. Here's the output: *$ apb_canary push* *--broker https://asb-1338-ansible-service broker.192.168.37.1.xip.io/ * version: 1.0 name: my-test-apb description: This is a sample application generated by apb init bindable: False async: optional metadata: displayName: my-test plans: - name: default description: This default plan deploys my-test-apb free: True metadata: {} parameters: [] Found registry IP at: 172.30.1.1:5000 Exception occurred! 'namespace' ?The apb_canary alias is defined as: ?alias apb_canary='docker run --rm --privileged -v $PWD:/mnt -v $HOME/.kube:/.kube -v /var/run/docker.sock:/var/run/docker.sock -u $UID docker.io/ansibleplaybookbundle/apb-tools:canary' ?I have tried so far: - make clean - running the installer again with xip.io and nip.io - setting the permissions to user "developer?" - using user "admin" - restarting Docker - deleting all Docker images ?The APB is the one created using "apb init" as described in the guide: https://github.com/ansibleplaybookbundle/ansible-playbook-bundle/blob/master/docs/getting_started.md docker: Version 17.09.0-ce-mac33 ansible: ansible 2.4.0.0 There is no information in the Ansible Service Broker pods' log Any idea how to workaround this OR where could I find more info? Thanks,? JOSE MIGUEL GALLAS OLMEDO ASSOCIATE QE, mobile Red Hat M: +34618488633 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Wed Jan 17 15:30:54 2018 From: mwessend at redhat.com (Matthias Wessendorf) Date: Wed, 17 Jan 2018 16:30:54 +0100 Subject: [feedhenry-dev] Exception occurred! 'namespace' In-Reply-To: References: Message-ID: I think I've seen this before - not 100% sure. why not asking on the #asbroker channel in freenode ? On Wed, Jan 17, 2018 at 4:06 PM, Jose Miguel Gallas Olmedo < jgallaso at redhat.com> wrote: > Hi, > > I am getting an error when trying to push an APB to my local Openshift. > Here's the output: > > *$ apb_canary push* *--broker https://asb-1338-ansible-service > broker.192.168.37.1.xip.io/ > * > version: 1.0 > name: my-test-apb > description: This is a sample application generated by apb init > bindable: False > async: optional > metadata: > displayName: my-test > plans: > - name: default > description: This default plan deploys my-test-apb > free: True > metadata: {} > parameters: [] > Found registry IP at: 172.30.1.1:5000 > Exception occurred! 'namespace' > > ?The apb_canary alias is defined as: > > ?alias apb_canary='docker run --rm --privileged -v $PWD:/mnt -v > $HOME/.kube:/.kube -v /var/run/docker.sock:/var/run/docker.sock -u $UID > docker.io/ansibleplaybookbundle/apb-tools:canary' > > ?I have tried so far: > > - make clean > - running the installer again with xip.io and nip.io > - setting the permissions to user "developer?" > - using user "admin" > - restarting Docker > - deleting all Docker images > > ?The APB is the one created using "apb init" as described in the guide: > https://github.com/ansibleplaybookbundle/ansible- > playbook-bundle/blob/master/docs/getting_started.md > > docker: Version 17.09.0-ce-mac33 > ansible: ansible 2.4.0.0 > > There is no information in the Ansible Service Broker pods' log > > Any idea how to workaround this OR where could I find more info? > > Thanks,? > > > JOSE MIGUEL GALLAS OLMEDO > > ASSOCIATE QE, mobile > > Red Hat > > > > M: +34618488633 > > > > _______________________________________________ > 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 jgallaso at redhat.com Wed Jan 17 15:59:44 2018 From: jgallaso at redhat.com (Jose Miguel Gallas Olmedo) Date: Wed, 17 Jan 2018 16:59:44 +0100 Subject: [feedhenry-dev] Exception occurred! 'namespace' In-Reply-To: References: Message-ID: @matthias I have asked a couple of times already Anyway, it turned out using *apb-tools:sprint142* workarounded the issue! JOSE MIGUEL GALLAS OLMEDO ASSOCIATE QE, mobile Red Hat M: +34618488633 On 17 January 2018 at 16:30, Matthias Wessendorf wrote: > I think I've seen this before - not 100% sure. > > why not asking on the #asbroker channel in freenode ? > > On Wed, Jan 17, 2018 at 4:06 PM, Jose Miguel Gallas Olmedo < > jgallaso at redhat.com> wrote: > >> Hi, >> >> I am getting an error when trying to push an APB to my local Openshift. >> Here's the output: >> >> *$ apb_canary push* *--broker https://asb-1338-ansible-service >> broker.192.168.37.1.xip.io/ >> * >> version: 1.0 >> name: my-test-apb >> description: This is a sample application generated by apb init >> bindable: False >> async: optional >> metadata: >> displayName: my-test >> plans: >> - name: default >> description: This default plan deploys my-test-apb >> free: True >> metadata: {} >> parameters: [] >> Found registry IP at: 172.30.1.1:5000 >> Exception occurred! 'namespace' >> >> ?The apb_canary alias is defined as: >> >> ?alias apb_canary='docker run --rm --privileged -v $PWD:/mnt -v >> $HOME/.kube:/.kube -v /var/run/docker.sock:/var/run/docker.sock -u $UID >> docker.io/ansibleplaybookbundle/apb-tools:canary' >> >> ?I have tried so far: >> >> - make clean >> - running the installer again with xip.io and nip.io >> - setting the permissions to user "developer?" >> - using user "admin" >> - restarting Docker >> - deleting all Docker images >> >> ?The APB is the one created using "apb init" as described in the guide: >> https://github.com/ansibleplaybookbundle/ansible-playbook- >> bundle/blob/master/docs/getting_started.md >> >> docker: Version 17.09.0-ce-mac33 >> ansible: ansible 2.4.0.0 >> >> There is no information in the Ansible Service Broker pods' log >> >> Any idea how to workaround this OR where could I find more info? >> >> Thanks,? >> >> >> JOSE MIGUEL GALLAS OLMEDO >> >> ASSOCIATE QE, mobile >> >> Red Hat >> >> >> >> M: +34618488633 >> >> >> >> _______________________________________________ >> 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 Wed Jan 17 16:08:04 2018 From: mwessend at redhat.com (Matthias Wessendorf) Date: Wed, 17 Jan 2018 17:08:04 +0100 Subject: [feedhenry-dev] Exception occurred! 'namespace' In-Reply-To: References: Message-ID: that would make sense, since that's our used backend :-) I hate the labeling / tagging - and sprints, is IMO closer to real release tags, unlike latest, canary etc On Wed, Jan 17, 2018 at 4:59 PM, Jose Miguel Gallas Olmedo < jgallaso at redhat.com> wrote: > @matthias I have asked a couple of times already > > Anyway, it turned out using *apb-tools:sprint142* workarounded the issue! > > JOSE MIGUEL GALLAS OLMEDO > > ASSOCIATE QE, mobile > > Red Hat > > > > M: +34618488633 > > > > On 17 January 2018 at 16:30, Matthias Wessendorf > wrote: > >> I think I've seen this before - not 100% sure. >> >> why not asking on the #asbroker channel in freenode ? >> >> On Wed, Jan 17, 2018 at 4:06 PM, Jose Miguel Gallas Olmedo < >> jgallaso at redhat.com> wrote: >> >>> Hi, >>> >>> I am getting an error when trying to push an APB to my local Openshift. >>> Here's the output: >>> >>> *$ apb_canary push* *--broker https://asb-1338-ansible-service >>> broker.192.168.37.1.xip.io/ >>> * >>> version: 1.0 >>> name: my-test-apb >>> description: This is a sample application generated by apb init >>> bindable: False >>> async: optional >>> metadata: >>> displayName: my-test >>> plans: >>> - name: default >>> description: This default plan deploys my-test-apb >>> free: True >>> metadata: {} >>> parameters: [] >>> Found registry IP at: 172.30.1.1:5000 >>> Exception occurred! 'namespace' >>> >>> ?The apb_canary alias is defined as: >>> >>> ?alias apb_canary='docker run --rm --privileged -v $PWD:/mnt -v >>> $HOME/.kube:/.kube -v /var/run/docker.sock:/var/run/docker.sock -u $UID >>> docker.io/ansibleplaybookbundle/apb-tools:canary' >>> >>> ?I have tried so far: >>> >>> - make clean >>> - running the installer again with xip.io and nip.io >>> - setting the permissions to user "developer?" >>> - using user "admin" >>> - restarting Docker >>> - deleting all Docker images >>> >>> ?The APB is the one created using "apb init" as described in the guide: >>> https://github.com/ansibleplaybookbundle/ansible-playbook-bu >>> ndle/blob/master/docs/getting_started.md >>> >>> docker: Version 17.09.0-ce-mac33 >>> ansible: ansible 2.4.0.0 >>> >>> There is no information in the Ansible Service Broker pods' log >>> >>> Any idea how to workaround this OR where could I find more info? >>> >>> Thanks,? >>> >>> >>> JOSE MIGUEL GALLAS OLMEDO >>> >>> ASSOCIATE QE, mobile >>> >>> Red Hat >>> >>> >>> >>> M: +34618488633 >>> >>> >>> >>> _______________________________________________ >>> 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 aliok at redhat.com Thu Jan 18 13:15:45 2018 From: aliok at redhat.com (Ali Ok) Date: Thu, 18 Jan 2018 16:15:45 +0300 Subject: [feedhenry-dev] [DEMO] AeroGear metrics with Prometheus and Grafana Message-ID: Hello, We published a new video on AeroGear Youtube channel demoing metrics for AeroGear services with Prometheus and Grafana. Video: https://youtu.be/is2moCykMSI Relevant links: - https://github.com/aerogearcatalog/metrics-apb - https://github.com/aerogear/service-docs - https://github.com/aerogearcatalog/fh-sync-server-apb - https://github.com/aerogear/mobile-core Cheers, Ali -------------- next part -------------- An HTML attachment was scrubbed... URL: From psturc at redhat.com Fri Jan 19 09:30:56 2018 From: psturc at redhat.com (Pavel Sturc) Date: Fri, 19 Jan 2018 10:30:56 +0100 Subject: [feedhenry-dev] [aerogear-dev] Demo: Prometheus auto discovery In-Reply-To: References: Message-ID: Hey Ali, I haven't noticed any of your videos until now, because my clever Gmail filter was still throwing out all "aerogear-dev" emails to spam folder! Nice and helpful videos! :) On Mon, Jan 15, 2018 at 8:48 AM, Ali Ok wrote: > Hi Paolo, > > Good idea. I created an issue for that app: https://github.com/ > openshift/nodejs-ex/issues/161 > > Let's see what they think. > > Cheers > > On Fri, Jan 12, 2018 at 5:31 PM, Paolo Haji wrote: > >> Awesome video! >> >> Do you think it would be outside of the scope of the original example app >> to include the sample random metrics gauge and perhaps other metrics >> gathering? >> I believe this could be a nice contribution to it. >> >> On Fri, Jan 12, 2018 at 8:51 AM, Ali Ok wrote: >> >>> Hi, >>> >>> I created a video, demonstrating Prometheus auto discovery that is >>> configured in metrics-apb[1]: https://www.youtube.com/watch? >>> v=AC_Xet-B1fY >>> >>> This video is an educational video that doesn't use FH-Sync or any other >>> FH-service as the metrics target. Instead, I wrote a very simple >>> lightweight node application [2] that serves the purpose of experimenting >>> with Prometheus on OpenShift better. >>> >>> This video is something I prepared very quickly in addition to the video >>> that will be made soon featuring the metrics solution [3]. >>> >>> [1]: https://github.com/aerogearcatalog/metrics-apb >>> [2]: https://github.com/aliok/node-app-with-prometheus-metrics >>> [3]: https://issues.jboss.org/browse/AEROGEAR-1797 >>> >>> Cheers, >>> Ali >>> >>> _______________________________________________ >>> feedhenry-dev mailing list >>> feedhenry-dev at redhat.com >>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>> >>> >> >> >> -- >> >> PAOLO HAJI >> >> SOFTWARE ENGINEER, RED HAT MOBILE APPLICATION PLATFORM >> >> Red Hat Brasil >> >> phaji at redhat.com >> >> TRIED. TESTED. TRUSTED. >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Regards, PAVEL STURC QUALITY ENGINEER Red Hat Mobile Application Platform psturc at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From psturc at redhat.com Fri Jan 19 12:59:29 2018 From: psturc at redhat.com (Pavel Sturc) Date: Fri, 19 Jan 2018 13:59:29 +0100 Subject: [feedhenry-dev] [DEMO] APB PR-based testing on Jenkins Message-ID: Hello guys, we were working on the implementation of APB PR-based testing and we also recorded a quick demo about it. https://youtu.be/ByDW8a9bhaw Relevant links are in the description of the video. -- Regards, PAVEL STURC QUALITY ENGINEER Red Hat Mobile Application Platform psturc at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwright at redhat.com Fri Jan 19 15:09:15 2018 From: pwright at redhat.com (Paul Wright) Date: Fri, 19 Jan 2018 15:09:15 +0000 Subject: [feedhenry-dev] mobile-docs repo Message-ID: <41b99834-1d59-e4bf-4047-3857f6cef6ea@redhat.com> Hi, FYI - if you wrote any content in the https://github.com/aerogear/service-docs repo Dave Martin had set up a service-docs repo for generic doc relating to mobile.next, and Craig set up mobile-docs for me with the same intent... So, today, we renamed service-docs to mobile-docs to retain the history of the work that was already done, Paul -- Paul Wright Mobile Docs (github: finp) From mwessend at redhat.com Fri Jan 19 15:48:05 2018 From: mwessend at redhat.com (Matthias Wessendorf) Date: Fri, 19 Jan 2018 15:48:05 +0000 Subject: [feedhenry-dev] mobile-docs repo In-Reply-To: <41b99834-1d59-e4bf-4047-3857f6cef6ea@redhat.com> References: <41b99834-1d59-e4bf-4047-3857f6cef6ea@redhat.com> Message-ID: +1 On Fri 19. Jan 2018 at 16:09, Paul Wright wrote: > Hi, > > FYI - if you wrote any content in the > https://github.com/aerogear/service-docs repo > > Dave Martin had set up a service-docs repo for generic doc relating to > mobile.next, and Craig set up mobile-docs for me with the same intent... > > So, today, we renamed service-docs to mobile-docs to retain the history > of the work that was already done, > > Paul > > -- > Paul Wright > Mobile Docs (github: finp) > > _______________________________________________ > 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 Mon Jan 22 10:43:48 2018 From: davmarti at redhat.com (David Martin) Date: Mon, 22 Jan 2018 10:43:48 +0000 Subject: [feedhenry-dev] Push Server Metrics to capture Message-ID: There are 2 metrics already captured in the push server metrics endpoint. More info here https://github.com/aerogear/aerogear-unifiedpush-server/pull/949 Related trello with more info on the story [1] I'm interested in any suggestions on what else could/should be included in the metrics endpoint. CPU/RAM will already be captured by heapster in openshift Any thoughts on using the same approach as keycloak & including default exports https://github.com/prometheus/client_java#included-collectors https://github.com/aerogear/keycloak-metrics-spi/blob/master/src/main/java/org/jboss/aerogear/keycloak/metrics/PrometheusExporter.java#L55 ? Is there anything else specific to administering a push server that would be useful? [1] https://trello.com/c/tPin7vee/22-as-a-developer-i-want-to-be-able-to-expose-metrics-data-about-push-in-prometheus-format-from-an-endpoint-of-this-service -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (#aerogear) -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbraun at redhat.com Mon Jan 22 11:23:36 2018 From: pbraun at redhat.com (Peter Braun) Date: Mon, 22 Jan 2018 12:23:36 +0100 Subject: [feedhenry-dev] Push Server Metrics to capture In-Reply-To: References: Message-ID: <9C4BA5F4-895F-4950-A6CB-76D52D09A718@redhat.com> One of the captured metrics is ?push_requests_total?. It would be nice to add a label here to group by platform, e.g. ?push_requests_total{platform=?android?} = 5.0? About the default metrics. They are free and i think we should include them just to have the same behavior in our metrics endpoints as much as possible. > Am 22.01.2018 um 11:43 schrieb David Martin : > > There are 2 metrics already captured in the push server metrics endpoint. > More info here > https://github.com/aerogear/aerogear-unifiedpush-server/pull/949 > Related trello with more info on the story [1] > > > I'm interested in any suggestions on what else could/should be included in the metrics endpoint. > > CPU/RAM will already be captured by heapster in openshift > > Any thoughts on using the same approach as keycloak & including default exports > https://github.com/prometheus/client_java#included-collectors > https://github.com/aerogear/keycloak-metrics-spi/blob/master/src/main/java/org/jboss/aerogear/keycloak/metrics/PrometheusExporter.java#L55 > ? > > Is there anything else specific to administering a push server that would be useful? > > [1] https://trello.com/c/tPin7vee/22-as-a-developer-i-want-to-be-able-to-expose-metrics-data-about-push-in-prometheus-format-from-an-endpoint-of-this-service -- > David Martin > Red Hat Mobile > Twitter: @irldavem > IRC: @irldavem (#aerogear) > _______________________________________________ > 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 matzew at apache.org Mon Jan 22 11:23:34 2018 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 22 Jan 2018 12:23:34 +0100 Subject: [feedhenry-dev] [aerogear-dev] Push Server Metrics to capture In-Reply-To: References: Message-ID: +1 on DefaultExports usage On Mon, Jan 22, 2018 at 11:43 AM, David Martin wrote: > There are 2 metrics already captured in the push server metrics endpoint. > More info here > https://github.com/aerogear/aerogear-unifiedpush-server/pull/949 > Related trello with more info on the story [1] > > > I'm interested in any suggestions on what else could/should be included in > the metrics endpoint. > > CPU/RAM will already be captured by heapster in openshift > > Any thoughts on using the same approach as keycloak & including default > exports > https://github.com/prometheus/client_java#included-collectors > https://github.com/aerogear/keycloak-metrics-spi/blob/ > master/src/main/java/org/jboss/aerogear/keycloak/ > metrics/PrometheusExporter.java#L55 > ? > > Is there anything else specific to administering a push server that would > be useful? > > [1] https://trello.com/c/tPin7vee/22-as-a-developer-i- > want-to-be-able-to-expose-metrics-data-about-push-in- > prometheus-format-from-an-endpoint-of-this-service > -- > David Martin > Red Hat Mobile > Twitter: @irldavem > IRC: @irldavem (#aerogear) > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf github: https://github.com/matzew twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Mon Jan 22 11:25:03 2018 From: mwessend at redhat.com (Matthias Wessendorf) Date: Mon, 22 Jan 2018 12:25:03 +0100 Subject: [feedhenry-dev] Push Server Metrics to capture In-Reply-To: <9C4BA5F4-895F-4950-A6CB-76D52D09A718@redhat.com> References: <9C4BA5F4-895F-4950-A6CB-76D52D09A718@redhat.com> Message-ID: On Mon, Jan 22, 2018 at 12:23 PM, Peter Braun wrote: > One of the captured metrics is ?push_requests_total?. It would be nice to > add a label here to group by platform, e.g. ?push_requests_total{platform=?android?} > = 5.0? > +1 we could do that, instead (or in addition) > > About the default metrics. They are free and i think we should include > them just to have the same behavior in our metrics endpoints as much as > possible. > +1 > > > Am 22.01.2018 um 11:43 schrieb David Martin : > > There are 2 metrics already captured in the push server metrics endpoint. > More info here > https://github.com/aerogear/aerogear-unifiedpush-server/pull/949 > Related trello with more info on the story [1] > > > I'm interested in any suggestions on what else could/should be included in > the metrics endpoint. > > CPU/RAM will already be captured by heapster in openshift > > Any thoughts on using the same approach as keycloak & including default > exports > https://github.com/prometheus/client_java#included-collectors > https://github.com/aerogear/keycloak-metrics-spi/blob/ > master/src/main/java/org/jboss/aerogear/keycloak/ > metrics/PrometheusExporter.java#L55 > ? > > Is there anything else specific to administering a push server that would > be useful? > > [1] https://trello.com/c/tPin7vee/22-as-a-developer-i- > want-to-be-able-to-expose-metrics-data-about-push-in- > prometheus-format-from-an-endpoint-of-this-service > -- > David Martin > Red Hat Mobile > Twitter: @irldavem > IRC: @irldavem (#aerogear) > _______________________________________________ > 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 > > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From mziccard at redhat.com Mon Jan 22 18:57:27 2018 From: mziccard at redhat.com (Massimiliano Ziccardi) Date: Mon, 22 Jan 2018 19:57:27 +0100 Subject: [feedhenry-dev] [aerogear-dev] Push Server Metrics to capture In-Reply-To: References: Message-ID: I think it would be a good idea to have pinpoint as well. Il 22 Gen 2018 12:29 PM, "Matthias Wessendorf" ha scritto: > +1 on DefaultExports usage > > On Mon, Jan 22, 2018 at 11:43 AM, David Martin > wrote: > >> There are 2 metrics already captured in the push server metrics endpoint. >> More info here >> https://github.com/aerogear/aerogear-unifiedpush-server/pull/949 >> Related trello with more info on the story [1] >> >> >> I'm interested in any suggestions on what else could/should be included >> in the metrics endpoint. >> >> CPU/RAM will already be captured by heapster in openshift >> >> Any thoughts on using the same approach as keycloak & including default >> exports >> https://github.com/prometheus/client_java#included-collectors >> https://github.com/aerogear/keycloak-metrics-spi/blob/master >> /src/main/java/org/jboss/aerogear/keycloak/metrics/ >> PrometheusExporter.java#L55 >> ? >> >> Is there anything else specific to administering a push server that would >> be useful? >> >> [1] https://trello.com/c/tPin7vee/22-as-a-developer-i-want- >> to-be-able-to-expose-metrics-data-about-push-in-prometheus- >> format-from-an-endpoint-of-this-service >> -- >> David Martin >> Red Hat Mobile >> Twitter: @irldavem >> IRC: @irldavem (#aerogear) >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > github: https://github.com/matzew > 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 mwessend at redhat.com Mon Jan 22 19:52:49 2018 From: mwessend at redhat.com (Matthias Wessendorf) Date: Mon, 22 Jan 2018 20:52:49 +0100 Subject: [feedhenry-dev] [aerogear-dev] Push Server Metrics to capture In-Reply-To: References: Message-ID: I think that's a completely different beast, since more for profiling - while still useful, to bring in to learn more check the cards in the trello there is one that might fit for pinpoint On Mon, Jan 22, 2018 at 7:57 PM, Massimiliano Ziccardi wrote: > I think it would be a good idea to have pinpoint as well. > > Il 22 Gen 2018 12:29 PM, "Matthias Wessendorf" ha > scritto: > >> +1 on DefaultExports usage >> >> On Mon, Jan 22, 2018 at 11:43 AM, David Martin >> wrote: >> >>> There are 2 metrics already captured in the push server metrics endpoint. >>> More info here >>> https://github.com/aerogear/aerogear-unifiedpush-server/pull/949 >>> Related trello with more info on the story [1] >>> >>> >>> I'm interested in any suggestions on what else could/should be included >>> in the metrics endpoint. >>> >>> CPU/RAM will already be captured by heapster in openshift >>> >>> Any thoughts on using the same approach as keycloak & including default >>> exports >>> https://github.com/prometheus/client_java#included-collectors >>> https://github.com/aerogear/keycloak-metrics-spi/blob/master >>> /src/main/java/org/jboss/aerogear/keycloak/metrics/Prometheu >>> sExporter.java#L55 >>> ? >>> >>> Is there anything else specific to administering a push server that >>> would be useful? >>> >>> [1] https://trello.com/c/tPin7vee/22-as-a-developer-i-want-t >>> o-be-able-to-expose-metrics-data-about-push-in-prometheus-fo >>> rmat-from-an-endpoint-of-this-service >>> -- >>> David Martin >>> Red Hat Mobile >>> Twitter: @irldavem >>> IRC: @irldavem (#aerogear) >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> >> -- >> Matthias Wessendorf >> >> github: https://github.com/matzew >> 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 > > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From matzew at apache.org Tue Jan 23 10:01:04 2018 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 23 Jan 2018 11:01:04 +0100 Subject: [feedhenry-dev] Java 9 updates Message-ID: Hi, I am trying to get a POM/BOM that supports out java projects w/ JDK9 support. For that I've created a new branch: https://github.com/aerogear/aerogear-parent/tree/java_9_prepwork This branch uses a jboss-parent that bumps the versions to those maven plugins that already did include java9 support (e.g. maven-compiler-plugin:3.7.0). Since this is a major change, I've updated the version of the parent, on that branch, to 2.0.0 For now, the master continues to support 'legacy' JDKs, such as Java8 - once the branch is stable and we should merge the changes to master. Projects that will require java8 support, like the Android (via the Android bom), will continue using the 1.1.x stream of the parent and its BOMs, for maintaince, there will be - at that time - a 1.1.x branch, for JDK8, stuff, while the latest development (e.g. JDK9,10,11) will live on MASTER, once they are stable enough ... any thoughts ? -Mattias -- Matthias Wessendorf github: https://github.com/matzew twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Wed Jan 24 10:35:38 2018 From: mwessend at redhat.com (Matthias Wessendorf) Date: Wed, 24 Jan 2018 11:35:38 +0100 Subject: [feedhenry-dev] Good video series on (Ansible) Service Broker(s) on Openshift Message-ID: Hi, all I found two videos that are nice and quick resources for some nice overview info on Ansible Service Broker on Openshift . Part 1: https://www.youtube.com/watch?v=iBVFq0X4ELw and Part 2: https://www.youtube.com/watch?v=jFtPGhhEQoU Good info for starters - perhaps we can add it to our info doc? If others like it, I can send a PR for that Cheers, Matthias -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbrookes at redhat.com Wed Jan 24 10:54:14 2018 From: pbrookes at redhat.com (Phil Brookes) Date: Wed, 24 Jan 2018 10:54:14 +0000 Subject: [feedhenry-dev] Demo videos via blue jeans for scrum of scrums meeting Message-ID: Hey Everyone, If, like me, you already have recorded a demo video that you want to use in the scrum of scrums meeting then I have found a way to do this and have it display in good quality, with audio enabled. First, you will need to upload your video to bluejeans, you can do this via the web-client, if you login to your red hat account at: https://redhat.bluejeans.com/ Then click on videos at the top of the screen and upload your video. This can take quite a while, so it?s wise to do this as soon as possible. To check that you will be able to show the video during the scrum of scrums meeting (some people tested with did not have the option). You will first need to be in the desktop app, accessing bluejeans via the browser does not have the option. Once in the desktop app and connected to a meeting, click ?Share Screen? and at the top you should have a ?videos? option (if you do not, you will not be able to share your video), and under this option your uploaded video should be present as an option. Any questions or comments, let me know! Thanks, Phil. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbraun at redhat.com Wed Jan 24 12:58:12 2018 From: pbraun at redhat.com (Peter Braun) Date: Wed, 24 Jan 2018 13:58:12 +0100 Subject: [feedhenry-dev] Demo videos via blue jeans for scrum of scrums meeting In-Reply-To: References: Message-ID: <443F48D7-14F4-4C7C-908D-60AF09ED4ABB@redhat.com> Thanks Phil, that works perfectly! One thing to note is that you need to be signed in to your BlueJeans account. Using Guest mode with the App will not work. > Am 24.01.2018 um 11:54 schrieb Phil Brookes : > > Hey Everyone, > > If, like me, you already have recorded a demo video that you want to use in the scrum of scrums meeting then I have found a way to do this and have it display in good quality, with audio enabled. > > First, you will need to upload your video to bluejeans, you can do this via the web-client, if you login to your red hat account at: > https://redhat.bluejeans.com/ > Then click on videos at the top of the screen and upload your video. This can take quite a while, so it?s wise to do this as soon as possible. > > To check that you will be able to show the video during the scrum of scrums meeting (some people tested with did not have the option). You will first need to be in the desktop app, accessing bluejeans via the browser does not have the option. > > Once in the desktop app and connected to a meeting, click ?Share Screen? and at the top you should have a ?videos? option (if you do not, you will not be able to share your video), and under this option your uploaded video should be present as an option. > > Any questions or comments, let me know! > > Thanks, > Phil. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfrizell at redhat.com Wed Jan 24 13:00:50 2018 From: jfrizell at redhat.com (John Frizelle) Date: Wed, 24 Jan 2018 14:00:50 +0100 Subject: [feedhenry-dev] Demo videos via blue jeans for scrum of scrums meeting In-Reply-To: References: Message-ID: Hi Phil, How poor is the quality when playing a youtube video through BlueJeans - or is it the lack of audio that is the main challenge? Thinking about community and being more open as we move forward, we will probably want to consider something other than BlueJeans for these meetings. I know AeroGear used to do public google hangouts - I'm guessing it would have better support for sharing/streaming videos from YouTube... 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 24 January 2018 at 11:54, Phil Brookes wrote: > Hey Everyone, > > If, like me, you already have recorded a demo video that you want to use > in the scrum of scrums meeting then I have found a way to do this and have > it display in good quality, with audio enabled. > > First, you will need to upload your video to bluejeans, you can do this > via the web-client, if you login to your red hat account at: > https://redhat.bluejeans.com/ > > Then click on videos at the top of the screen and upload your video. This > can take quite a while, so it?s wise to do this as soon as possible. > > To check that you will be able to show the video during the scrum of > scrums meeting (some people tested with did not have the option). You will > first need to be in the desktop app, accessing bluejeans via the browser > does not have the option. > > Once in the desktop app and connected to a meeting, click ?Share Screen? > and at the top you should have a ?videos? option (if you do not, you will > not be able to share your video), and under this option your uploaded video > should be present as an option. > > Any questions or comments, let me know! > > Thanks, > Phil. > ? > -------------- 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 supittma at redhat.com Wed Jan 24 13:06:28 2018 From: supittma at redhat.com (Summers Pittman) Date: Wed, 24 Jan 2018 08:06:28 -0500 Subject: [feedhenry-dev] Demo videos via blue jeans for scrum of scrums meeting In-Reply-To: References: Message-ID: On Wed, Jan 24, 2018 at 5:54 AM, Phil Brookes wrote: > Hey Everyone, > > If, like me, you already have recorded a demo video that you want to use > in the scrum of scrums meeting then I have found a way to do this and have > it display in good quality, with audio enabled. > > First, you will need to upload your video to bluejeans, you can do this > via the web-client, if you login to your red hat account at: > https://redhat.bluejeans.com/ > > Then click on videos at the top of the screen and upload your video. This > can take quite a while, so it?s wise to do this as soon as possible. > > To check that you will be able to show the video during the scrum of > scrums meeting (some people tested with did not have the option). You will > first need to be in the desktop app, accessing bluejeans via the browser > does not have the option. > > Once in the desktop app and connected to a meeting, click ?Share Screen? > and at the top you should have a ?videos? option (if you do not, you will > not be able to share your video), and under this option your uploaded video > should be present as an option. > > Any questions or comments, let me know! > > Does this work with the linux app? I just tried and the videos option didn't appear. > Thanks, > Phil. > ? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbraun at redhat.com Wed Jan 24 13:12:34 2018 From: pbraun at redhat.com (Peter Braun) Date: Wed, 24 Jan 2018 14:12:34 +0100 Subject: [feedhenry-dev] Demo videos via blue jeans for scrum of scrums meeting In-Reply-To: References: Message-ID: <5ABCD7B1-DC8B-4434-86F6-DB53AD87EBB4@redhat.com> @Summers: it?s an Electron App, so i?d assume it?s identical on all platforms. When you click on ?Share Screen? there are two tabs, one of then is ?Videos?. And you need to be logged in with the App for it to work. @John: i uploaded the Video to Youtube and BlueJeans. Bluejeans only for the presentation today because that also works with sound. > Am 24.01.2018 um 14:06 schrieb Summers Pittman : > > > > On Wed, Jan 24, 2018 at 5:54 AM, Phil Brookes > wrote: > Hey Everyone, > > If, like me, you already have recorded a demo video that you want to use in the scrum of scrums meeting then I have found a way to do this and have it display in good quality, with audio enabled. > > First, you will need to upload your video to bluejeans, you can do this via the web-client, if you login to your red hat account at: > https://redhat.bluejeans.com/ > Then click on videos at the top of the screen and upload your video. This can take quite a while, so it?s wise to do this as soon as possible. > > To check that you will be able to show the video during the scrum of scrums meeting (some people tested with did not have the option). You will first need to be in the desktop app, accessing bluejeans via the browser does not have the option. > > Once in the desktop app and connected to a meeting, click ?Share Screen? and at the top you should have a ?videos? option (if you do not, you will not be able to share your video), and under this option your uploaded video should be present as an option. > > Any questions or comments, let me know! > > > Does this work with the linux app? I just tried and the videos option didn't appear. > > > Thanks, > Phil. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From supittma at redhat.com Wed Jan 24 13:13:51 2018 From: supittma at redhat.com (Summers Pittman) Date: Wed, 24 Jan 2018 08:13:51 -0500 Subject: [feedhenry-dev] Demo videos via blue jeans for scrum of scrums meeting In-Reply-To: References: Message-ID: On Wed, Jan 24, 2018 at 8:00 AM, John Frizelle wrote: > Hi Phil, > > How poor is the quality when playing a youtube video through BlueJeans - > or is it the lack of audio that is the main challenge? > > Thinking about community and being more open as we move forward, we will > probably want to consider something other than BlueJeans for these > meetings. I know AeroGear used to do public google hangouts - I'm guessing > it would have better support for sharing/streaming videos from YouTube... > So I think Hangouts on Air has been deprecated in favor of YouTube live which is more single person twitch style streaming instead of group meetings. On AG we had the problem that we had more people than Hangouts would allow and we eventually moved to IRC meetings using meetbot, but we were experimenting with creating a webRTC client. I *think* we can make our bluejeans videos and meetings public as well. > > 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 24 January 2018 at 11:54, Phil Brookes wrote: > >> Hey Everyone, >> >> If, like me, you already have recorded a demo video that you want to use >> in the scrum of scrums meeting then I have found a way to do this and have >> it display in good quality, with audio enabled. >> >> First, you will need to upload your video to bluejeans, you can do this >> via the web-client, if you login to your red hat account at: >> https://redhat.bluejeans.com/ >> >> Then click on videos at the top of the screen and upload your video. This >> can take quite a while, so it?s wise to do this as soon as possible. >> >> To check that you will be able to show the video during the scrum of >> scrums meeting (some people tested with did not have the option). You will >> first need to be in the desktop app, accessing bluejeans via the browser >> does not have the option. >> >> Once in the desktop app and connected to a meeting, click ?Share Screen? >> and at the top you should have a ?videos? option (if you do not, you will >> not be able to share your video), and under this option your uploaded video >> should be present as an option. >> >> Any questions or comments, let me know! >> >> Thanks, >> Phil. >> ? >> > > > _______________________________________________ > 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 supittma at redhat.com Wed Jan 24 13:16:05 2018 From: supittma at redhat.com (Summers Pittman) Date: Wed, 24 Jan 2018 08:16:05 -0500 Subject: [feedhenry-dev] Demo videos via blue jeans for scrum of scrums meeting In-Reply-To: <5ABCD7B1-DC8B-4434-86F6-DB53AD87EBB4@redhat.com> References: <5ABCD7B1-DC8B-4434-86F6-DB53AD87EBB4@redhat.com> Message-ID: On Wed, Jan 24, 2018 at 8:12 AM, Peter Braun wrote: > @Summers: it?s an Electron App, so i?d assume it?s identical on all > platforms. When you click on ?Share Screen? there are two tabs, one of then > is ?Videos?. And you need to be logged in with the App for it to work. > > It works after manually updating the app. > @John: i uploaded the Video to Youtube and BlueJeans. Bluejeans only for > the presentation today because that also works with sound. > > > Am 24.01.2018 um 14:06 schrieb Summers Pittman : > > > > On Wed, Jan 24, 2018 at 5:54 AM, Phil Brookes wrote: > >> Hey Everyone, >> >> If, like me, you already have recorded a demo video that you want to use >> in the scrum of scrums meeting then I have found a way to do this and have >> it display in good quality, with audio enabled. >> >> First, you will need to upload your video to bluejeans, you can do this >> via the web-client, if you login to your red hat account at: >> https://redhat.bluejeans.com/ >> >> Then click on videos at the top of the screen and upload your video. This >> can take quite a while, so it?s wise to do this as soon as possible. >> >> To check that you will be able to show the video during the scrum of >> scrums meeting (some people tested with did not have the option). You will >> first need to be in the desktop app, accessing bluejeans via the browser >> does not have the option. >> >> Once in the desktop app and connected to a meeting, click ?Share Screen? >> and at the top you should have a ?videos? option (if you do not, you will >> not be able to share your video), and under this option your uploaded video >> should be present as an option. >> >> Any questions or comments, let me know! >> >> Does this work with the linux app? I just tried and the videos option > didn't appear. > > > >> Thanks, >> Phil. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbrookes at redhat.com Wed Jan 24 13:56:58 2018 From: pbrookes at redhat.com (Phil Brookes) Date: Wed, 24 Jan 2018 13:56:58 +0000 Subject: [feedhenry-dev] Demo videos via blue jeans for scrum of scrums meeting In-Reply-To: References: Message-ID: Hey John, My main concern with playing the video on YouTube through bluejeans is that the audio is not transmitted. Like Peter, I uploaded my video to YouTube when I mailed the demo around earlier, and have duplicated it into bluejeans for the purpose of this demonstration. Regards, Phil. ? On Wed, Jan 24, 2018 at 1:00 PM, John Frizelle wrote: > Hi Phil, > > How poor is the quality when playing a youtube video through BlueJeans - > or is it the lack of audio that is the main challenge? > > Thinking about community and being more open as we move forward, we will > probably want to consider something other than BlueJeans for these > meetings. I know AeroGear used to do public google hangouts - I'm guessing > it would have better support for sharing/streaming videos from YouTube... > > 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 24 January 2018 at 11:54, Phil Brookes wrote: > >> Hey Everyone, >> >> If, like me, you already have recorded a demo video that you want to use >> in the scrum of scrums meeting then I have found a way to do this and have >> it display in good quality, with audio enabled. >> >> First, you will need to upload your video to bluejeans, you can do this >> via the web-client, if you login to your red hat account at: >> https://redhat.bluejeans.com/ >> >> Then click on videos at the top of the screen and upload your video. This >> can take quite a while, so it?s wise to do this as soon as possible. >> >> To check that you will be able to show the video during the scrum of >> scrums meeting (some people tested with did not have the option). You will >> first need to be in the desktop app, accessing bluejeans via the browser >> does not have the option. >> >> Once in the desktop app and connected to a meeting, click ?Share Screen? >> and at the top you should have a ?videos? option (if you do not, you will >> not be able to share your video), and under this option your uploaded video >> should be present as an option. >> >> Any questions or comments, let me know! >> >> Thanks, >> Phil. >> ? >> > > -------------- 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 Wed Jan 24 14:43:17 2018 From: wtrocki at redhat.com (Wojciech Trocki) Date: Wed, 24 Jan 2018 14:43:17 +0000 Subject: [feedhenry-dev] Demo videos via blue jeans for scrum of scrums meeting In-Reply-To: References: Message-ID: How about we will just collect videos URL's and share them before? It will be strange to be on the meeting to actually watch videos :) It's strange for myself to have this conversation in the public list. When we share links to demos on the list and mention new milestone it will work for both community and internal purposes without mentioning meetings that community have no access to. I think that feedhenry-dev should no longer be used (at least this is what I got from internal messages) For aerogear emails we moved to google groups. On Wed, Jan 24, 2018 at 1:56 PM, Phil Brookes wrote: > Hey John, > > My main concern with playing the video on YouTube through bluejeans is > that the audio is not transmitted. > > Like Peter, I uploaded my video to YouTube when I mailed the demo around > earlier, and have duplicated it into bluejeans for the purpose of this > demonstration. > > Regards, > Phil. > ? > > On Wed, Jan 24, 2018 at 1:00 PM, John Frizelle > wrote: > >> Hi Phil, >> >> How poor is the quality when playing a youtube video through BlueJeans - >> or is it the lack of audio that is the main challenge? >> >> Thinking about community and being more open as we move forward, we will >> probably want to consider something other than BlueJeans for these >> meetings. I know AeroGear used to do public google hangouts - I'm guessing >> it would have better support for sharing/streaming videos from YouTube... >> >> 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 24 January 2018 at 11:54, Phil Brookes wrote: >> >>> Hey Everyone, >>> >>> If, like me, you already have recorded a demo video that you want to use >>> in the scrum of scrums meeting then I have found a way to do this and have >>> it display in good quality, with audio enabled. >>> >>> First, you will need to upload your video to bluejeans, you can do this >>> via the web-client, if you login to your red hat account at: >>> https://redhat.bluejeans.com/ >>> >>> Then click on videos at the top of the screen and upload your video. >>> This can take quite a while, so it?s wise to do this as soon as possible. >>> >>> To check that you will be able to show the video during the scrum of >>> scrums meeting (some people tested with did not have the option). You will >>> first need to be in the desktop app, accessing bluejeans via the browser >>> does not have the option. >>> >>> Once in the desktop app and connected to a meeting, click ?Share Screen? >>> and at the top you should have a ?videos? option (if you do not, you will >>> not be able to share your video), and under this option your uploaded video >>> should be present as an option. >>> >>> Any questions or comments, let me know! >>> >>> Thanks, >>> Phil. >>> ? >>> >> >> > > _______________________________________________ > 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 jfrizell at redhat.com Thu Jan 25 12:57:37 2018 From: jfrizell at redhat.com (John Frizelle) Date: Thu, 25 Jan 2018 13:57:37 +0100 Subject: [feedhenry-dev] Good video series on (Ansible) Service Broker(s) on Openshift In-Reply-To: References: Message-ID: Hey Matthias, Those videos are really good - very nice overview and practical demos in 2 x 6 min videos. +1 for adding to our docs - and would suggest that most people take the 12 mins required to have a look at these videos. 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 24 January 2018 at 11:35, Matthias Wessendorf wrote: > Hi, all > > I found two videos that are nice and quick resources for some nice > overview info on Ansible Service Broker on Openshift . > > Part 1: > https://www.youtube.com/watch?v=iBVFq0X4ELw > > and Part 2: > https://www.youtube.com/watch?v=jFtPGhhEQoU > > Good info for starters - perhaps we can add it to our info doc? If others > like it, I can send a PR for that > > Cheers, > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 11472 bytes Desc: not available URL: From vsazel at redhat.com Mon Jan 29 08:41:47 2018 From: vsazel at redhat.com (Vojtech Sazel) Date: Mon, 29 Jan 2018 09:41:47 +0100 Subject: [feedhenry-dev] Demo videos via blue jeans for scrum of scrums meeting In-Reply-To: References: Message-ID: Maybe there is one more thing. Can we make one page (on github or somewhere) where all links on the videos are? I got a little bit disconnected because of DevConf. Now I watched video from Pavel's about APB PR building and I'm in trouble of finding more. Vojtech On Wed, Jan 24, 2018 at 3:43 PM, Wojciech Trocki wrote: > How about we will just collect videos URL's and share them before? > It will be strange to be on the meeting to actually watch videos :) > It's strange for myself to have this conversation in the public list. > > When we share links to demos on the list and mention new milestone it will > work for both community and internal purposes > without mentioning meetings that community have no access to. > > I think that feedhenry-dev should no longer be used (at least this is what > I got from internal messages) > For aerogear emails we moved to google groups. > > On Wed, Jan 24, 2018 at 1:56 PM, Phil Brookes wrote: > >> Hey John, >> >> My main concern with playing the video on YouTube through bluejeans is >> that the audio is not transmitted. >> >> Like Peter, I uploaded my video to YouTube when I mailed the demo around >> earlier, and have duplicated it into bluejeans for the purpose of this >> demonstration. >> >> Regards, >> Phil. >> ? >> >> On Wed, Jan 24, 2018 at 1:00 PM, John Frizelle >> wrote: >> >>> Hi Phil, >>> >>> How poor is the quality when playing a youtube video through BlueJeans - >>> or is it the lack of audio that is the main challenge? >>> >>> Thinking about community and being more open as we move forward, we will >>> probably want to consider something other than BlueJeans for these >>> meetings. I know AeroGear used to do public google hangouts - I'm guessing >>> it would have better support for sharing/streaming videos from YouTube... >>> >>> 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 24 January 2018 at 11:54, Phil Brookes wrote: >>> >>>> Hey Everyone, >>>> >>>> If, like me, you already have recorded a demo video that you want to >>>> use in the scrum of scrums meeting then I have found a way to do this and >>>> have it display in good quality, with audio enabled. >>>> >>>> First, you will need to upload your video to bluejeans, you can do this >>>> via the web-client, if you login to your red hat account at: >>>> https://redhat.bluejeans.com/ >>>> >>>> Then click on videos at the top of the screen and upload your video. >>>> This can take quite a while, so it?s wise to do this as soon as possible. >>>> >>>> To check that you will be able to show the video during the scrum of >>>> scrums meeting (some people tested with did not have the option). You will >>>> first need to be in the desktop app, accessing bluejeans via the browser >>>> does not have the option. >>>> >>>> Once in the desktop app and connected to a meeting, click ?Share >>>> Screen? and at the top you should have a ?videos? option (if you do not, >>>> you will not be able to share your video), and under this option your >>>> uploaded video should be present as an option. >>>> >>>> Any questions or comments, let me know! >>>> >>>> Thanks, >>>> Phil. >>>> ? >>>> >>> >>> >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > > -- > > WOJCIECH TROCKI > > Red Hat Mobile > > IM: wtrocki > > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- VOJT?CH S?ZEL SENIOR QUALITY ENGINEER, MOBILE QE Red Hat Remote Czech Republic vsazel at redhat.com IM: vsazel -------------- 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 Mon Jan 29 09:19:59 2018 From: pwright at redhat.com (Paul Wright) Date: Mon, 29 Jan 2018 09:19:59 +0000 Subject: [feedhenry-dev] Demo videos via blue jeans for scrum of scrums meeting In-Reply-To: References: Message-ID: <6491dcd2-9c79-5f0c-0247-c61595d32d9f@redhat.com> Great idea Vojtech, I'm wondering about a simple table of media, perhaps in the mobile-docs wiki, eg: https://github.com/aerogear/mobile-docs/wiki/Video Of course, I'd depend on? the AeroGear community to remove items if/when they become out of date, thanks, Paul On 01/29/2018 08:41 AM, Vojtech Sazel wrote: > Maybe there is one more thing. Can we make one page (on github or > somewhere) where all links on the videos are? > I got a little bit disconnected because of DevConf. Now I watched > video from Pavel's about APB PR building and I'm in trouble of finding > more. > > Vojtech > > On Wed, Jan 24, 2018 at 3:43 PM, Wojciech Trocki > wrote: > > How about we will just collect videos URL's and share them before? > It will be strange to be on the meeting to actually watch videos :) > It's strange for myself to have this conversation in the public list. > > When we share links to demos on the list and mention new milestone > it will work for both community and internal purposes > without mentioning meetings that community have no access to. > > I think that feedhenry-dev should no longer be used (at least this > is what I got from internal messages) > For aerogear emails we moved to google groups. > > On Wed, Jan 24, 2018 at 1:56 PM, Phil Brookes > wrote: > > Hey John, > > My main concern with playing the video on YouTube through > bluejeans is that the audio is not transmitted. > > Like Peter, I uploaded my video to YouTube when I mailed the > demo around earlier, and have duplicated it into bluejeans for > the purpose of this demonstration. > > Regards, > Phil. > > ? > > On Wed, Jan 24, 2018 at 1:00 PM, John Frizelle > > wrote: > > Hi Phil, > > How poor is the quality when playing a youtube video > through BlueJeans - or is it the lack of audio that is the > main challenge? > > Thinking about community and being more open as we move > forward, we will probably want to consider something other > than BlueJeans for these meetings. I know AeroGear used to > do public google hangouts - I'm guessing it would have > better support for sharing/streaming videos from YouTube... > > 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 24 January 2018 at 11:54, Phil Brookes > > wrote: > > Hey Everyone, > > If, like me, you already have recorded a demo video > that you want to use in the scrum of scrums meeting > then I have found a way to do this and have it display > in good quality, with audio enabled. > > First, you will need to upload your video to > bluejeans, you can do this via the web-client, if you > login to your red hat account at: > https://redhat.bluejeans.com/ > > Then click on videos at the top of the screen and > upload your video. This can take quite a while, so > it?s wise to do this as soon as possible. > > To check that you will be able to show the video > during the scrum of scrums meeting (some people tested > with did not have the option). You will first need to > be in the desktop app, accessing bluejeans via the > browser does not have the option. > > Once in the desktop app and connected to a meeting, > click ?Share Screen? and at the top you should have a > ?videos? option (if you do not, you will not be able > to share your video), and under this option your > uploaded video should be present as an option. > > Any questions or comments, let me know! > > Thanks, > Phil. > > ? > > > > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > > > > > -- > > WOJCIECH TROCKI > > Red Hat Mobile > > IM: wtrocki > > > > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > > > > > -- > > VOJT?CH S?ZEL > > SENIOR QUALITY ENGINEER, MOBILE QE > > Red Hat > > > > Remote Czech Republic > > vsazel at redhat.com IM: vsazel > > > > > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev -- Paul Wright Mobile Docs (github: finp) -------------- 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 Mon Jan 29 16:51:02 2018 From: davmarti at redhat.com (David Martin) Date: Mon, 29 Jan 2018 16:51:02 +0000 Subject: [feedhenry-dev] Android Core Proposal Merged (and some follow up goals) Message-ID: Hi all, After a massive 100+ comments, I've decided to merge the Android Core SDK Proposal https://github.com/aerogear/proposals/pull/9 * Android Core SDK is available from Maven: * Repo: https://github.com/aerogear/aerogear-android-sdk * Example Android App that uses the core SDK: https://github.com/secondsun/WipDemo/blob/master/app/src/main/java/org/feedhenry/mcp/prdemo/CoreActivity.java * What you need to add to your gradle file: https://github.com/secondsun/WipDemo/blob/master/app/build.gradle#L29 The amount of comments, calls and back&forth on irc has reached a reasonable level of agreement, with some remaining points of contention. The contention is mainly around the level of complexity that a developer has to undertake to use the SDK. After listening to the 3 main voices on this (Summers, Wojciech, Passos), I can see both points of view. (WARNING: A lot of paraphrasing below :) ) >From Passos & Wojciech's point of view, ease of use of the SDK is what's most important. There should be practically no setup/init required other than having a mobile-config.json file in the right place, and call a static method to get an instance of a service (similar to Firebase). >From Summers point of view, ease of use is also important, but something we can improve on iteratively. For example, the default use of a Service will be fine & possible to automate the setup for for 95% of cases. However, the other 5% is what we need to take into account from the beginning. So, based on this, I would like if the following 2 things were follow up goals for the Core SDK. I believe these changes will take whats currently there (and working), and move it towards something that is easier to use for developers. Goal 1: https://issues.jboss.org/browse/AGDROID-712 Remove the need for static block initialisation/registration of service classes & their dependencies. i.e. this: static { ServiceModuleRegistry.registerServiceModule("keycloak", KeyCloakService.class, "http"); } >From chatting with Summers, this should be possible now that this PR is merged https://github.com/aerogear/proposals/pull/16 and the config file format is nailed down. Goal 2: https://issues.jboss.org/browse/AGDROID-713 Allow a simpler way of getting an instance of a Service class other than below. keycloakService = core.getService("keycloak", KeyCloakService.class); If there are multiple instances registered for a particular Class, it may still be necessary to use the above to get a 'named' instance (much like in dependency injection libs like spring that use annotations). However, in most cases, the below should be possible: keycloakService = core.getService(KeyCloakService.class); Thanks -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (#aerogear) -------------- next part -------------- An HTML attachment was scrubbed... URL: From wtrocki at redhat.com Mon Jan 29 17:55:38 2018 From: wtrocki at redhat.com (Wojciech Trocki) Date: Mon, 29 Jan 2018 17:55:38 +0000 Subject: [feedhenry-dev] Android Core Proposal Merged (and some follow up goals) In-Reply-To: References: Message-ID: Added small comments on tickets. From my point of view everything looks great. >From my point of view Goal 2 may be actually not needed depending on how Goal 1 will be resolved. I we think about it that is just one single ticket that is required to improve overall user experience and API. > keycloakService = core.getService(KeyCloakService.class); I remember that service team required to pass additional parameters and going this way will impose some limitations. What we looking for is probably something like this: Auth keycloak = AeroGearAuth.create(options) On Mon, Jan 29, 2018 at 4:51 PM, David Martin wrote: > Hi all, > > After a massive 100+ comments, I've decided to merge the Android Core SDK > Proposal > https://github.com/aerogear/proposals/pull/9 > > * Android Core SDK is available from Maven: > * Repo: https://github.com/aerogear/aerogear-android-sdk > * Example Android App that uses the core SDK: > https://github.com/secondsun/WipDemo/blob/master/app/src/ > main/java/org/feedhenry/mcp/prdemo/CoreActivity.java > * What you need to add to your gradle file: https://github.com/ > secondsun/WipDemo/blob/master/app/build.gradle#L29 > > > The amount of comments, calls and back&forth on irc has reached a > reasonable level of agreement, with some remaining points of contention. > The contention is mainly around the level of complexity that a developer > has to undertake to use the SDK. > After listening to the 3 main voices on this (Summers, Wojciech, Passos), > I can see both points of view. > > (WARNING: A lot of paraphrasing below :) ) > > From Passos & Wojciech's point of view, ease of use of the SDK is what's > most important. There should be practically no setup/init required other > than having a mobile-config.json file in the right place, and call a static > method to get an instance of a service (similar to Firebase). > > From Summers point of view, ease of use is also important, but something > we can improve on iteratively. For example, the default use of a Service > will be fine & possible to automate the setup for for 95% of cases. > However, the other 5% is what we need to take into account from the > beginning. > > > So, based on this, I would like if the following 2 things were follow up > goals for the Core SDK. > I believe these changes will take whats currently there (and working), and > move it towards something that is easier to use for developers. > > > Goal 1: > https://issues.jboss.org/browse/AGDROID-712 > Remove the need for static block initialisation/registration of service > classes & their dependencies. i.e. this: > > static { > ServiceModuleRegistry.registerServiceModule("keycloak", > KeyCloakService.class, "http"); > } > > From chatting with Summers, this should be possible now that this PR is > merged https://github.com/aerogear/proposals/pull/16 and the config file > format is nailed down. > > > Goal 2: > https://issues.jboss.org/browse/AGDROID-713 > Allow a simpler way of getting an instance of a Service class other than > below. > > keycloakService = core.getService("keycloak", KeyCloakService.class); > > If there are multiple instances registered for a particular Class, it may > still be necessary to use the above to get a 'named' instance (much like in > dependency injection libs like spring that use annotations). > However, in most cases, the below should be possible: > > keycloakService = core.getService(KeyCloakService.class); > > > > > Thanks > > -- > David Martin > Red Hat Mobile > Twitter: @irldavem > IRC: @irldavem (#aerogear) > > -- > You received this message because you are subscribed to the Google Groups > "Aerogear" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to aerogear+unsubscribe at googlegroups.com. > To post to this group, send email to aerogear at googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/aerogear/CADvBQ454ouqqV8Qr7nHssEYxV932Z-JcBqA36VW6-w_Puoe-ng%40mail. > gmail.com > > . > For more options, visit https://groups.google.com/d/optout. > -- WOJCIECH TROCKI Red Hat Mobile IM: wtrocki -------------- next part -------------- An HTML attachment was scrubbed... URL: From davmarti at redhat.com Mon Jan 29 19:44:29 2018 From: davmarti at redhat.com (David Martin) Date: Mon, 29 Jan 2018 19:44:29 +0000 Subject: [feedhenry-dev] Android Core Proposal Merged (and some follow up goals) In-Reply-To: References: Message-ID: Sounds good to me. If it works out that 2 is covered by 1, great. @Passos @Summers anything you want to add? Would be great to get feedback from anyone using the sdk already too. On Mon, 29 Jan 2018 17:56 Wojciech Trocki, wrote: > Added small comments on tickets. From my point of view everything looks > great. > From my point of view Goal 2 may be actually not needed depending on how > Goal 1 will be resolved. > I we think about it that is just one single ticket that is required to > improve overall user experience and API. > > > keycloakService = core.getService(KeyCloakService.class); > > I remember that service team required to pass additional parameters and > going this way will impose some limitations. > What we looking for is probably something like this: > > Auth keycloak = AeroGearAuth.create(options) > > > On Mon, Jan 29, 2018 at 4:51 PM, David Martin wrote: > >> Hi all, >> >> After a massive 100+ comments, I've decided to merge the Android Core SDK >> Proposal >> https://github.com/aerogear/proposals/pull/9 >> >> * Android Core SDK is available from Maven: >> * Repo: https://github.com/aerogear/aerogear-android-sdk >> * Example Android App that uses the core SDK: >> >> https://github.com/secondsun/WipDemo/blob/master/app/src/main/java/org/feedhenry/mcp/prdemo/CoreActivity.java >> * What you need to add to your gradle file: >> https://github.com/secondsun/WipDemo/blob/master/app/build.gradle#L29 >> >> >> The amount of comments, calls and back&forth on irc has reached a >> reasonable level of agreement, with some remaining points of contention. >> The contention is mainly around the level of complexity that a developer >> has to undertake to use the SDK. >> After listening to the 3 main voices on this (Summers, Wojciech, Passos), >> I can see both points of view. >> >> (WARNING: A lot of paraphrasing below :) ) >> >> From Passos & Wojciech's point of view, ease of use of the SDK is what's >> most important. There should be practically no setup/init required other >> than having a mobile-config.json file in the right place, and call a static >> method to get an instance of a service (similar to Firebase). >> >> From Summers point of view, ease of use is also important, but something >> we can improve on iteratively. For example, the default use of a Service >> will be fine & possible to automate the setup for for 95% of cases. >> However, the other 5% is what we need to take into account from the >> beginning. >> >> >> So, based on this, I would like if the following 2 things were follow up >> goals for the Core SDK. >> I believe these changes will take whats currently there (and working), >> and move it towards something that is easier to use for developers. >> >> >> Goal 1: >> https://issues.jboss.org/browse/AGDROID-712 >> Remove the need for static block initialisation/registration of service >> classes & their dependencies. i.e. this: >> >> static { >> ServiceModuleRegistry.registerServiceModule("keycloak", >> KeyCloakService.class, "http"); >> } >> >> From chatting with Summers, this should be possible now that this PR is >> merged https://github.com/aerogear/proposals/pull/16 and the config file >> format is nailed down. >> >> >> Goal 2: >> https://issues.jboss.org/browse/AGDROID-713 >> Allow a simpler way of getting an instance of a Service class other than >> below. >> >> keycloakService = core.getService("keycloak", KeyCloakService.class); >> >> If there are multiple instances registered for a particular Class, it may >> still be necessary to use the above to get a 'named' instance (much like in >> dependency injection libs like spring that use annotations). >> However, in most cases, the below should be possible: >> >> keycloakService = core.getService(KeyCloakService.class); >> >> >> >> >> Thanks >> >> -- >> David Martin >> Red Hat Mobile >> Twitter: @irldavem >> IRC: @irldavem (#aerogear) >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Aerogear" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to aerogear+unsubscribe at googlegroups.com. >> To post to this group, send email to aerogear at googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/aerogear/CADvBQ454ouqqV8Qr7nHssEYxV932Z-JcBqA36VW6-w_Puoe-ng%40mail.gmail.com >> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > > WOJCIECH TROCKI > > Red Hat Mobile > > IM: wtrocki > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davmarti at redhat.com Wed Jan 31 14:11:49 2018 From: davmarti at redhat.com (David Martin) Date: Wed, 31 Jan 2018 14:11:49 +0000 Subject: [feedhenry-dev] Docs process In-Reply-To: <63e12771-3df1-efae-786a-ff86933f78d6@redhat.com> References: <63e12771-3df1-efae-786a-ff86933f78d6@redhat.com> Message-ID: Sending on list @Paul, how about this approach when creating docs tasks in Epics. * Identify the 'action' that is the focus of the docs task, and include that in the jira title/description. So taking this task as an example, "Document how the Single Auth Provider works and is configured" https://issues.jboss.org/browse/AEROGEAR-1917 this could be rephrased to something like: "Document how an OpenShift user can be given access to a Mobile Service". This would contain a lot of similar content to what Steven has already written (as it explains how the openshift roles for that namespace give/restrict access to a service via the oauth proxy). But it also hints at there being a goal for that doc. Having this info in the task when it is started could help influence and shape how the doc is written so it is closer to what you want at PR time On 31 January 2018 at 12:09, Paul Wright wrote: > Hi David, > > Preamble: this is still a bit nebulous, but might become a proposal for a > docs process: > > I've got a few examples of mobile.next docs items, and here's the issue > > 1. Eng want to write specific pieces required by an epic > > 2. Docs want to publish end-user docs with context, fitting into an > overall flow/user story/structure > > An example is https://github.com/aerogear/mobile-docs/pull/7/files > > I'm struggling to find context for this piece, but at the same time the > guys want to close out the epic. > > Another example is the readme at https://github.com/aerogear/mi > nishift-mobilecore-addon > > (which will land in mobile-docs as https://github.com/finp/mobile > -docs/blob/AEROGEAR-1982/getting-started/minishift_install.adoc) > > Given this: > > * I don't want to block eng > > * I don't want to 'light' review material > > * some docs have a life outside of mobile-docs repo > > I'm thinking of the following procedure: > > 1. Write your docs in the repo of choice (and merge, eg finishing epic) > > 2. I'll create a placeholder in mobile-docs for that doc , eg > > mobile-docs/services/metrics-single-auth-provider.adoc > > with a reference to the source material (in code repo) > > 3. Create a follow up task to 'create upstream doc and reconcile with code > repo' > > The idea being that eventually, the doc in the code repo is equivalent to > mobile-docs repo, but that becomes async, not depending on me to sort > everything out to satisfy some epic closure pressure. > > Obviously, this is not ideal, because developer has moved on by the time > I'm reviewing doc, but not everything will require as much context filling > as https://github.com/aerogear/mobile-docs/pull/7/files > > > WDYT? > > Paul > > > > > -- > Paul Wright > Mobile Docs (github: finp) > > -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (#aerogear) -------------- next part -------------- An HTML attachment was scrubbed... URL: From davmarti at redhat.com Wed Jan 31 14:17:35 2018 From: davmarti at redhat.com (David Martin) Date: Wed, 31 Jan 2018 14:17:35 +0000 Subject: [feedhenry-dev] Docs process In-Reply-To: References: <63e12771-3df1-efae-786a-ff86933f78d6@redhat.com> Message-ID: Lets try that again... @Paul, how about this approach when creating docs tasks in Epics. * Identify the 'action' that is the focus of the docs task, and include that in the jira title/description. So taking this task as an example, "Document how the Single Auth Provider works and is configured" https://issues.jboss.org/browse/AEROGEAR-1917 this could be rephrased to something like: "Document how an OpenShift user can be given access to a Mobile Service". This would contain a lot of similar content to what Steven has already written (as it explains how the openshift roles for that namespace give/restrict access to a service via the oauth proxy). But it also hints at there being a goal for that doc. Having this info in the task when it is started could help influence and shape how the doc is written so it is closer to what you want at PR time Better? On 31 January 2018 at 14:11, David Martin wrote: > Sending on list > > @Paul, how about this approach when creating docs tasks in Epics. > > * Identify the 'action' that is the focus of the docs task, and include > that in the jira title/description. > > So taking this task as an example, > "Document how the Single Auth Provider works and is configured" > https://issues.jboss.org/browse/AEROGEAR-1917 > > this could be rephrased to something like: > "Document how an OpenShift user can be given access to a Mobile Service". > This would contain a lot of similar content to what Steven has already > written (as it explains how the openshift roles for that namespace > give/restrict access to a service via the oauth proxy). > But it also hints at there being a goal for that doc. > Having this info in the task when it is started could help influence and > shape how the doc is written so it is closer to what you want at PR time > > On 31 January 2018 at 12:09, Paul Wright wrote: > >> Hi David, >> >> Preamble: this is still a bit nebulous, but might become a proposal for a >> docs process: >> >> I've got a few examples of mobile.next docs items, and here's the issue >> >> 1. Eng want to write specific pieces required by an epic >> >> 2. Docs want to publish end-user docs with context, fitting into an >> overall flow/user story/structure >> >> An example is https://github.com/aerogear/mobile-docs/pull/7/files >> >> I'm struggling to find context for this piece, but at the same time the >> guys want to close out the epic. >> >> Another example is the readme at https://github.com/aerogear/mi >> nishift-mobilecore-addon >> >> (which will land in mobile-docs as https://github.com/finp/mobile >> -docs/blob/AEROGEAR-1982/getting-started/minishift_install.adoc) >> >> Given this: >> >> * I don't want to block eng >> >> * I don't want to 'light' review material >> >> * some docs have a life outside of mobile-docs repo >> >> I'm thinking of the following procedure: >> >> 1. Write your docs in the repo of choice (and merge, eg finishing epic) >> >> 2. I'll create a placeholder in mobile-docs for that doc , eg >> >> mobile-docs/services/metrics-single-auth-provider.adoc >> >> with a reference to the source material (in code repo) >> >> 3. Create a follow up task to 'create upstream doc and reconcile with >> code repo' >> >> The idea being that eventually, the doc in the code repo is equivalent to >> mobile-docs repo, but that becomes async, not depending on me to sort >> everything out to satisfy some epic closure pressure. >> >> Obviously, this is not ideal, because developer has moved on by the time >> I'm reviewing doc, but not everything will require as much context filling >> as https://github.com/aerogear/mobile-docs/pull/7/files >> >> >> WDYT? >> >> Paul >> >> >> >> >> -- >> Paul Wright >> Mobile Docs (github: finp) >> >> > > > -- > David Martin > Red Hat Mobile > Twitter: @irldavem > IRC: @irldavem (#aerogear) > -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (#aerogear) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmadigan at redhat.com Wed Jan 31 14:29:59 2018 From: jmadigan at redhat.com (Jason Madigan) Date: Wed, 31 Jan 2018 14:29:59 +0000 Subject: [feedhenry-dev] Docs process In-Reply-To: References: <63e12771-3df1-efae-786a-ff86933f78d6@redhat.com> Message-ID: @David - keen to see what your redacted reply was ;) [image: Inline image 1] On Wed, Jan 31, 2018 at 2:17 PM, David Martin wrote: > Lets try that again... > > > > @Paul, how about this approach when creating docs tasks in Epics. > > * Identify the 'action' that is the focus of the docs task, and include > that in the jira title/description. > > So taking this task as an example, > "Document how the Single Auth Provider works and is configured" > https://issues.jboss.org/browse/AEROGEAR-1917 > > this could be rephrased to something like: > "Document how an OpenShift user can be given access to a Mobile Service". > This would contain a lot of similar content to what Steven has already > written (as it explains how the openshift roles for that namespace > give/restrict access to a service via the oauth proxy). > But it also hints at there being a goal for that doc. > Having this info in the task when it is started could help influence and > shape how the doc is written so it is closer to what you want at PR time > > > Better? > > On 31 January 2018 at 14:11, David Martin wrote: > >> Sending on list >> >> @Paul, how about this approach when creating docs tasks in Epics. >> >> * Identify the 'action' that is the focus of the docs task, and include >> that in the jira title/description. >> >> So taking this task as an example, >> "Document how the Single Auth Provider works and is configured" >> https://issues.jboss.org/browse/AEROGEAR-1917 >> >> this could be rephrased to something like: >> "Document how an OpenShift user can be given access to a Mobile Service". >> This would contain a lot of similar content to what Steven has already >> written (as it explains how the openshift roles for that namespace >> give/restrict access to a service via the oauth proxy). >> But it also hints at there being a goal for that doc. >> Having this info in the task when it is started could help influence and >> shape how the doc is written so it is closer to what you want at PR time >> >> On 31 January 2018 at 12:09, Paul Wright wrote: >> >>> Hi David, >>> >>> Preamble: this is still a bit nebulous, but might become a proposal for >>> a docs process: >>> >>> I've got a few examples of mobile.next docs items, and here's the issue >>> >>> 1. Eng want to write specific pieces required by an epic >>> >>> 2. Docs want to publish end-user docs with context, fitting into an >>> overall flow/user story/structure >>> >>> An example is https://github.com/aerogear/mobile-docs/pull/7/files >>> >>> I'm struggling to find context for this piece, but at the same time the >>> guys want to close out the epic. >>> >>> Another example is the readme at https://github.com/aerogear/mi >>> nishift-mobilecore-addon >>> >>> (which will land in mobile-docs as https://github.com/finp/mobile >>> -docs/blob/AEROGEAR-1982/getting-started/minishift_install.adoc) >>> >>> Given this: >>> >>> * I don't want to block eng >>> >>> * I don't want to 'light' review material >>> >>> * some docs have a life outside of mobile-docs repo >>> >>> I'm thinking of the following procedure: >>> >>> 1. Write your docs in the repo of choice (and merge, eg finishing epic) >>> >>> 2. I'll create a placeholder in mobile-docs for that doc , eg >>> >>> mobile-docs/services/metrics-single-auth-provider.adoc >>> >>> with a reference to the source material (in code repo) >>> >>> 3. Create a follow up task to 'create upstream doc and reconcile with >>> code repo' >>> >>> The idea being that eventually, the doc in the code repo is equivalent >>> to mobile-docs repo, but that becomes async, not depending on me to sort >>> everything out to satisfy some epic closure pressure. >>> >>> Obviously, this is not ideal, because developer has moved on by the time >>> I'm reviewing doc, but not everything will require as much context filling >>> as https://github.com/aerogear/mobile-docs/pull/7/files >>> >>> >>> WDYT? >>> >>> Paul >>> >>> >>> >>> >>> -- >>> Paul Wright >>> Mobile Docs (github: finp) >>> >>> >> >> >> -- >> David Martin >> Red Hat Mobile >> Twitter: @irldavem >> IRC: @irldavem (#aerogear) >> > > > > -- > David Martin > Red Hat Mobile > Twitter: @irldavem > IRC: @irldavem (#aerogear) > > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2018-01-31 at 14.29.19.png Type: image/png Size: 75657 bytes Desc: not available URL: