From supittma at redhat.com Tue Oct 3 13:20:04 2017 From: supittma at redhat.com (Summers Pittman) Date: Tue, 3 Oct 2017 09:20:04 -0400 Subject: [feedhenry-dev] MCP Android Plugin Demo Message-ID: TL;DR; here's the link : https://www.youtube.com/watch?v=8_yGFnYtIoQ So the next two sprints the Client SDK team is working on MCP integration for Android in an attempt to replicate Aiden's demo from last week. Right now we have build an Android app that parses a local mcp-config file and loads the configuration from the mcp server. This configuration will be used to configure the sync and keycloak SDKs on the client. One of the features we've put into our PoC is a Android build plugin that handles the parsing of the mcp-config file at build time instead of at run time. This means that if the file is not present, is misconfigured, etc this error will be caught much sooner than if you have to load it onto an Android device. Additionally it let's us have tighter integration with the Android build ecosystem as shown in the demo. Summers -------------- next part -------------- An HTML attachment was scrubbed... URL: From davmarti at redhat.com Tue Oct 3 17:00:36 2017 From: davmarti at redhat.com (David Martin) Date: Tue, 3 Oct 2017 18:00:36 +0100 Subject: [feedhenry-dev] MCP Android Plugin Demo In-Reply-To: References: Message-ID: Hey Summers, Nice video. I like the idea of doing the config validation at build time. I think its important that an App can launch to some usable state, even if offline (for the first or subsequent launches). I'd like to know your thoughts on if there's value in having the config endpoint in the mcp server? Why even bother with calling the endpoint if you could just take the config from that response and use that in your App? (e.g. show the full config for all services in the MCP UI) On 3 October 2017 at 14:20, Summers Pittman wrote: > TL;DR; here's the link : https://www.youtube.com/watch?v=8_yGFnYtIoQ > > So the next two sprints the Client SDK team is working on MCP integration > for Android in an attempt to replicate Aiden's demo from last week. Right > now we have build an Android app that parses a local mcp-config file and > loads the configuration from the mcp server. This configuration will be > used to configure the sync and keycloak SDKs on the client. > > One of the features we've put into our PoC is a Android build plugin that > handles the parsing of the mcp-config file at build time instead of at run > time. This means that if the file is not present, is misconfigured, etc > this error will be caught much sooner than if you have to load it onto an > Android device. Additionally it let's us have tighter integration with the > Android build ecosystem as shown in the demo. > > Summers > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From supittma at redhat.com Tue Oct 3 18:53:18 2017 From: supittma at redhat.com (Summers Pittman) Date: Tue, 3 Oct 2017 14:53:18 -0400 Subject: [feedhenry-dev] MCP Android Plugin Demo In-Reply-To: References: Message-ID: On Tue, Oct 3, 2017 at 1:00 PM, David Martin wrote: > Hey Summers, > > Nice video. > I like the idea of doing the config validation at build time. > I think its important that an App can launch to some usable state, even if > offline (for the first or subsequent launches). > > I'd like to know your thoughts on if there's value in having the config > endpoint in the mcp server? > Why even bother with calling the endpoint if you could just take the config > from that response and use that in your App? > (e.g. show the full config for all services in the MCP UI) > Well there is value and I think we need A/B or Blue/Green style features to be competitive with other options, and having the download config pattern is one way to implement it. We also have to support many options on many platforms and it is a least common denominator implementation even if there are technical limitations we get to overcome. (Firebase sells a similar service called remote config). For some use cases this could be a core feature; configuration dashboard apps come to mind. From a support POV there are also options for enabling things like remote debugging, logging, etc. In development situations this will let us cut down on the turnaround time for testing service integrations which is beneficial during a app's early days. Eventually the dev scenario will need an easy way to "switch" to a static configuration for most apps. If we have as a use case changing the server configuration at runtime then we need to think out the feature as a whole once we get past the MVP. > > On 3 October 2017 at 14:20, Summers Pittman wrote: > >> TL;DR; here's the link : https://www.youtube.com/watch?v=8_yGFnYtIoQ >> >> So the next two sprints the Client SDK team is working on MCP integration >> for Android in an attempt to replicate Aiden's demo from last week. Right >> now we have build an Android app that parses a local mcp-config file and >> loads the configuration from the mcp server. This configuration will be >> used to configure the sync and keycloak SDKs on the client. >> >> One of the features we've put into our PoC is a Android build plugin that >> handles the parsing of the mcp-config file at build time instead of at run >> time. This means that if the file is not present, is misconfigured, etc >> this error will be caught much sooner than if you have to load it onto an >> Android device. Additionally it let's us have tighter integration with the >> Android build ecosystem as shown in the demo. >> >> Summers >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > > -- > David Martin > Red Hat Mobile > Twitter: @irldavem > IRC: @irldavem (feedhenry, mobile-internal) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From supittma at redhat.com Fri Oct 6 13:17:54 2017 From: supittma at redhat.com (Summers Pittman) Date: Fri, 6 Oct 2017 09:17:54 -0400 Subject: [feedhenry-dev] Self Signed Certs in Android Message-ID: While I'm testing out MCP and some of the client sdk sync refactoring I regularly get hit with Android not liking self signed certificates.* There are several work around for development such as * setting up and maintaining a CA infrastructure and signing everything in correct fashion * setting up DNS for developer to host their own domains and distribute well signed keys** * injecting a SSL Handler that just doesn't check anything These are impractical, tedious and/or dangerous. I will leave it as an exercise to the reader to decide which is which. However, for development scenarios we have the option of certificate pinning. This is a fancy word for "If you see the certificate at this URL you are golden, ignore the haters".*** There are two general ways to pin, but they each have drawbacks. First, Android N has support for defining pins in your AndroidManifest. Android handles all of the dirty work for you, but this is only in Android N and above. There do seem to be some attempts at back porting, but I haven't researched them too far, The second choice is for us to design our API layers such that pins can be injected and used by our underlying HTTP mechanisms. Many frameworks already support pinning so it shouldn't be too hard to expose, but it will require more coordination and thought. So wdyt? For the next couple of sprints we should be fine just using Android N's pinning, and eventually it will be the default solution. Also, I don't know how self-signed certificates run on cordova, windows, iOS, etc. I wouldn't mind if those platforms' experts chime in. Summers * Java and thus Android won't by default make a connection if the certificate can't be authenticated both by a chain of trust and matching the domain the certificate claims to be for. ** This is kind of what fhcap does. It works great fro Android development in an emulator but isn't practical for testing on devices as the DNS magic has to be set up on the device which fhcap can't control. *** I may have not used the correct technical jargon here. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jusanche at redhat.com Fri Oct 6 14:14:31 2017 From: jusanche at redhat.com (Julio Cesar Sanchez Hernandez) Date: Fri, 6 Oct 2017 16:14:31 +0200 Subject: [feedhenry-dev] Self Signed Certs in Android In-Reply-To: References: Message-ID: On Cordova Android apps, self signed certificates work in debug but fail to connect in release. On Cordova iOS and iOS native, self signed certificates don't work, even configuring ATS to allow everything, self signed don't fall into the "everything". There is some code you can add to allow connection despite the self signed certificate, but it's not a good option. Apple might reject the app if you forget to remove it before releasing the app. On Fri, Oct 6, 2017 at 3:17 PM, Summers Pittman wrote: > While I'm testing out MCP and some of the client sdk sync refactoring I > regularly get hit with Android not liking self signed certificates.* > > There are several work around for development such as > * setting up and maintaining a CA infrastructure and signing everything > in correct fashion > * setting up DNS for developer to host their own domains and distribute > well signed keys** > * injecting a SSL Handler that just doesn't check anything > > These are impractical, tedious and/or dangerous. I will leave it as an > exercise to the reader to decide which is which. > > However, for development scenarios we have the option of certificate > pinning. This is a fancy word for "If you see the certificate at this URL > you are golden, ignore the haters".*** There are two general ways to pin, > but they each have drawbacks. > > First, Android N has support for defining pins in your AndroidManifest. > Android handles all of the dirty work for you, but this is only in Android > N and above. There do seem to be some attempts at back porting, but I > haven't researched them too far, > > The second choice is for us to design our API layers such that pins can be > injected and used by our underlying HTTP mechanisms. Many frameworks > already support pinning so it shouldn't be too hard to expose, but it will > require more coordination and thought. > > So wdyt? For the next couple of sprints we should be fine just using > Android N's pinning, and eventually it will be the default solution. > > Also, I don't know how self-signed certificates run on cordova, windows, > iOS, etc. I wouldn't mind if those platforms' experts chime in. > > Summers > > * Java and thus Android won't by default make a connection if the > certificate can't be authenticated both by a chain of trust and matching > the domain the certificate claims to be for. > > ** This is kind of what fhcap does. It works great fro Android > development in an emulator but isn't practical for testing on devices as > the DNS magic has to be set up on the device which fhcap can't control. > > *** I may have not used the correct technical jargon here. > > > > _______________________________________________ > 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 vsazel at redhat.com Fri Oct 6 16:15:35 2017 From: vsazel at redhat.com (Vojtech Sazel) Date: Fri, 6 Oct 2017 18:15:35 +0200 Subject: [feedhenry-dev] Self Signed Certs in Android In-Reply-To: References: Message-ID: Hi, I think that MCP will be hosted on site like* openshift.io *. Doesn't they have simple some container that does set up Letsencrypt for the subdomain? However it's necessary to have access to public internet for Letsencrypt. I think that it would be ok to disable SSL certificate checks for debug mode apps. Vojtech On Fri, Oct 6, 2017 at 4:14 PM, Julio Cesar Sanchez Hernandez < jusanche at redhat.com> wrote: > On Cordova Android apps, self signed certificates work in debug but fail > to connect in release. > On Cordova iOS and iOS native, self signed certificates don't work, even > configuring ATS to allow everything, self signed don't fall into the > "everything". There is some code you can add to allow connection despite > the self signed certificate, but it's not a good option. Apple might reject > the app if you forget to remove it before releasing the app. > > On Fri, Oct 6, 2017 at 3:17 PM, Summers Pittman > wrote: > >> While I'm testing out MCP and some of the client sdk sync refactoring I >> regularly get hit with Android not liking self signed certificates.* >> >> There are several work around for development such as >> * setting up and maintaining a CA infrastructure and signing everything >> in correct fashion >> * setting up DNS for developer to host their own domains and distribute >> well signed keys** >> * injecting a SSL Handler that just doesn't check anything >> >> These are impractical, tedious and/or dangerous. I will leave it as an >> exercise to the reader to decide which is which. >> >> However, for development scenarios we have the option of certificate >> pinning. This is a fancy word for "If you see the certificate at this URL >> you are golden, ignore the haters".*** There are two general ways to pin, >> but they each have drawbacks. >> >> First, Android N has support for defining pins in your AndroidManifest. >> Android handles all of the dirty work for you, but this is only in Android >> N and above. There do seem to be some attempts at back porting, but I >> haven't researched them too far, >> >> The second choice is for us to design our API layers such that pins can >> be injected and used by our underlying HTTP mechanisms. Many frameworks >> already support pinning so it shouldn't be too hard to expose, but it will >> require more coordination and thought. >> >> So wdyt? For the next couple of sprints we should be fine just using >> Android N's pinning, and eventually it will be the default solution. >> >> Also, I don't know how self-signed certificates run on cordova, windows, >> iOS, etc. I wouldn't mind if those platforms' experts chime in. >> >> Summers >> >> * Java and thus Android won't by default make a connection if the >> certificate can't be authenticated both by a chain of trust and matching >> the domain the certificate claims to be for. >> >> ** This is kind of what fhcap does. It works great fro Android >> development in an emulator but isn't practical for testing on devices as >> the DNS magic has to be set up on the device which fhcap can't control. >> >> *** I may have not used the correct technical jargon here. >> >> >> >> _______________________________________________ >> 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 > > -- 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: From mwessend at redhat.com Mon Oct 9 07:06:34 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Mon, 9 Oct 2017 09:06:34 +0200 Subject: [feedhenry-dev] keycloak-apb -> automated build on docker-hub ? Message-ID: Hi, last week I've converted the "buildfarm-apb" repo ([1]), to an automatic build: Everytime a PR is merged (to master), a new image is build - instead of us doing manually (and inconsistent) uploads of our local builds. For other 'apb's, like the keycloak-apb, I'd like to do the same; Any concerns? Greetings, Matthias [1] https://hub.docker.com/r/feedhenry/buildfarm-apb/ -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From davmarti at redhat.com Mon Oct 9 08:23:01 2017 From: davmarti at redhat.com (David Martin) Date: Mon, 9 Oct 2017 09:23:01 +0100 Subject: [feedhenry-dev] keycloak-apb -> automated build on docker-hub ? In-Reply-To: References: Message-ID: +1 on automation for keeping the images up to date with master On 9 October 2017 at 08:06, Matthias Wessendorf wrote: > Hi, > > last week I've converted the "buildfarm-apb" repo ([1]), to an automatic > build: > Everytime a PR is merged (to master), a new image is build - instead of us > doing manually (and inconsistent) uploads of our local builds. > > For other 'apb's, like the keycloak-apb, I'd like to do the same; > > Any concerns? > > Greetings, > Matthias > > > [1] https://hub.docker.com/r/feedhenry/buildfarm-apb/ > > -- > Project lead AeroGear.org > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From lgriffin at redhat.com Mon Oct 9 08:30:36 2017 From: lgriffin at redhat.com (Leigh Griffin) Date: Mon, 9 Oct 2017 09:30:36 +0100 Subject: [feedhenry-dev] Congratulating Summers on 5 great years at Red Hat Message-ID: Hi everyone, Yesterday Summers marked his 5th anniversary in Red Hat. Summers has led the charge on our Open Source efforts for such a long time now that people default to him for advice and guidance on all things Open Source. He has helped transition the entire Mobile team towards a more Open mentality and his work in the SDK team, where he serves as an Android expert, and recently in the Mobile.next work is helping to bring our next generation offering to fruition. Summers, congratulations on this immense milestone and wishing you the best for the next 5 years. If you could join me in congratulating Summers on this great achievement, ideally off list. Thanks, Leigh -- LEIGH GRIFFIN ENGINEERING MANAGER, MOBILE Red Hat Ireland Communications House, Cork Road Waterford City, Ireland X91NY33 lgriffin at redhat.com M: +353877545162 IM: lgriffin TRIED. TESTED. TRUSTED. @redhatway @redhatinc @redhatsnaps -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkirwan at redhat.com Mon Oct 9 08:37:00 2017 From: dkirwan at redhat.com (David Kirwan) Date: Mon, 9 Oct 2017 09:37:00 +0100 Subject: [feedhenry-dev] Congratulating Summers on 5 great years at Red Hat In-Reply-To: References: Message-ID: Congrats Summers On 9 October 2017 at 09:30, Leigh Griffin wrote: > Hi everyone, > > Yesterday Summers marked his 5th anniversary in Red Hat. Summers has led > the charge on our Open Source efforts for such a long time now that people > default to him for advice and guidance on all things Open Source. He has > helped transition the entire Mobile team towards a more Open mentality and > his work in the SDK team, where he serves as an Android expert, and > recently in the Mobile.next work is helping to bring our next generation > offering to fruition. > > Summers, congratulations on this immense milestone and wishing you the > best for the next 5 years. If you could join me in congratulating Summers > on this great achievement, ideally off list. > > Thanks, > Leigh > > -- > > LEIGH GRIFFIN > > ENGINEERING MANAGER, MOBILE > > Red Hat Ireland > > Communications House, Cork Road > > Waterford City, Ireland X91NY33 > > lgriffin at redhat.com M: +353877545162 IM: lgriffin > > TRIED. TESTED. TRUSTED. > > @redhatway @redhatinc > @redhatsnaps > > -- David Kirwan *Cloud Operations Engineer* Red Hat Mobile, Waterford, Ireland. phone: +353 51 810167 Email: dkirwan at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbraun at redhat.com Mon Oct 9 08:43:20 2017 From: pbraun at redhat.com (Peter Braun) Date: Mon, 9 Oct 2017 10:43:20 +0200 Subject: [feedhenry-dev] Congratulating Summers on 5 great years at Red Hat In-Reply-To: References: Message-ID: Congratulations Summers! > Am 09.10.2017 um 10:30 schrieb Leigh Griffin : > > Hi everyone, > > Yesterday Summers marked his 5th anniversary in Red Hat. Summers has led the charge on our Open Source efforts for such a long time now that people default to him for advice and guidance on all things Open Source. He has helped transition the entire Mobile team towards a more Open mentality and his work in the SDK team, where he serves as an Android expert, and recently in the Mobile.next work is helping to bring our next generation offering to fruition. > > Summers, congratulations on this immense milestone and wishing you the best for the next 5 years. If you could join me in congratulating Summers on this great achievement, ideally off list. > > Thanks, > Leigh > > -- > LEIGH GRIFFIN > ENGINEERING MANAGER, MOBILE > Red Hat?Ireland > Communications House, Cork Road > Waterford City, Ireland X91NY33 > lgriffin at redhat.com M: +353877545162 IM: lgriffin > > > TRIED. TESTED. TRUSTED. > @redhatway @redhatinc @redhatsnaps -------------- next part -------------- An HTML attachment was scrubbed... URL: From roregan at redhat.com Mon Oct 9 08:43:35 2017 From: roregan at redhat.com (Rachael O'Regan) Date: Mon, 9 Oct 2017 09:43:35 +0100 Subject: [feedhenry-dev] Congratulating Summers on 5 great years at Red Hat In-Reply-To: References: Message-ID: <41BE054A-0FEB-4727-A5CF-18493A84BF36@redhat.com> Congrats Summers! RACHAEL O'REGAN Red Hat Mobile Communications House, Cork Road Waterford City, Ireland X91NY33 roregan at redhat.com IM: roregan > On 9 Oct 2017, at 09:37, David Kirwan wrote: > > Congrats Summers > > On 9 October 2017 at 09:30, Leigh Griffin > wrote: > Hi everyone, > > Yesterday Summers marked his 5th anniversary in Red Hat. Summers has led the charge on our Open Source efforts for such a long time now that people default to him for advice and guidance on all things Open Source. He has helped transition the entire Mobile team towards a more Open mentality and his work in the SDK team, where he serves as an Android expert, and recently in the Mobile.next work is helping to bring our next generation offering to fruition. > > Summers, congratulations on this immense milestone and wishing you the best for the next 5 years. If you could join me in congratulating Summers on this great achievement, ideally off list. > > Thanks, > Leigh > > -- > LEIGH GRIFFIN > ENGINEERING MANAGER, MOBILE > Red Hat?Ireland > Communications House, Cork Road > Waterford City, Ireland X91NY33 > lgriffin at redhat.com M: +353877545162 IM: lgriffin > > > TRIED. TESTED. TRUSTED. > @redhatway @redhatinc @redhatsnaps > > > -- > David Kirwan > Cloud Operations Engineer > Red Hat Mobile, > Waterford, Ireland. > phone: +353 51 810167 > Email: dkirwan at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Message signed with OpenPGP URL: From lrossett at redhat.com Mon Oct 9 08:44:05 2017 From: lrossett at redhat.com (Leonardo Rossetti) Date: Mon, 9 Oct 2017 05:44:05 -0300 Subject: [feedhenry-dev] Congratulating Summers on 5 great years at Red Hat In-Reply-To: References: Message-ID: Congrats :) On Mon, Oct 9, 2017 at 5:30 AM, Leigh Griffin wrote: > Hi everyone, > > Yesterday Summers marked his 5th anniversary in Red Hat. Summers has led > the charge on our Open Source efforts for such a long time now that people > default to him for advice and guidance on all things Open Source. He has > helped transition the entire Mobile team towards a more Open mentality and > his work in the SDK team, where he serves as an Android expert, and > recently in the Mobile.next work is helping to bring our next generation > offering to fruition. > > Summers, congratulations on this immense milestone and wishing you the > best for the next 5 years. If you could join me in congratulating Summers > on this great achievement, ideally off list. > > Thanks, > Leigh > > -- > > LEIGH GRIFFIN > > ENGINEERING MANAGER, MOBILE > > Red Hat Ireland > > Communications House, Cork Road > > Waterford City, Ireland X91NY33 > > lgriffin at redhat.com M: +353877545162 IM: lgriffin > > TRIED. TESTED. TRUSTED. > > @redhatway @redhatinc > @redhatsnaps > > -- LEONARDO ROSSETTI SOFTWARE ENGINEER Red Hat SP lrossett at redhat.com M: 11997030621 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jstaffor at redhat.com Mon Oct 9 08:43:52 2017 From: jstaffor at redhat.com (John Stafford) Date: Mon, 9 Oct 2017 09:43:52 +0100 Subject: [feedhenry-dev] Congratulating Summers on 5 great years at Red Hat In-Reply-To: References: Message-ID: Congrats Summers. On Mon, Oct 9, 2017 at 9:37 AM, David Kirwan wrote: > Congrats Summers > > On 9 October 2017 at 09:30, Leigh Griffin wrote: > >> Hi everyone, >> >> Yesterday Summers marked his 5th anniversary in Red Hat. Summers has led >> the charge on our Open Source efforts for such a long time now that people >> default to him for advice and guidance on all things Open Source. He has >> helped transition the entire Mobile team towards a more Open mentality and >> his work in the SDK team, where he serves as an Android expert, and >> recently in the Mobile.next work is helping to bring our next generation >> offering to fruition. >> >> Summers, congratulations on this immense milestone and wishing you the >> best for the next 5 years. If you could join me in congratulating Summers >> on this great achievement, ideally off list. >> >> Thanks, >> Leigh >> >> -- >> >> LEIGH GRIFFIN >> >> ENGINEERING MANAGER, MOBILE >> >> Red Hat Ireland >> >> Communications House, Cork Road >> >> Waterford City, Ireland X91NY33 >> >> lgriffin at redhat.com M: +353877545162 IM: lgriffin >> >> TRIED. TESTED. TRUSTED. >> >> @redhatway @redhatinc >> @redhatsnaps >> >> > > > > -- > David Kirwan > *Cloud Operations Engineer* > Red Hat Mobile, > Waterford, Ireland. > phone: +353 51 810167 <+353%2051%20810%20167> > Email: dkirwan at redhat.com > -- JOHN STAFFORD TECHNICAL WRITER, CCS Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: From lzuccare at redhat.com Mon Oct 9 09:02:42 2017 From: lzuccare at redhat.com (Luigi Zuccarelli) Date: Mon, 9 Oct 2017 10:02:42 +0100 Subject: [feedhenry-dev] Congratulating Summers on 5 great years at Red Hat In-Reply-To: References: Message-ID: Congrats Summers On Mon, Oct 9, 2017 at 9:43 AM, Peter Braun wrote: > Congratulations Summers! > > Am 09.10.2017 um 10:30 schrieb Leigh Griffin : > > Hi everyone, > > Yesterday Summers marked his 5th anniversary in Red Hat. Summers has led > the charge on our Open Source efforts for such a long time now that people > default to him for advice and guidance on all things Open Source. He has > helped transition the entire Mobile team towards a more Open mentality and > his work in the SDK team, where he serves as an Android expert, and > recently in the Mobile.next work is helping to bring our next generation > offering to fruition. > > Summers, congratulations on this immense milestone and wishing you the > best for the next 5 years. If you could join me in congratulating Summers > on this great achievement, ideally off list. > > Thanks, > Leigh > > -- > LEIGH GRIFFIN > > ENGINEERING MANAGER, MOBILE > Red Hat Ireland > Communications House, Cork Road > Waterford City, Ireland X91NY33 > > lgriffin at redhat.com M: +353877545162 IM: lgriffin > > TRIED. TESTED. TRUSTED. > > @redhatway @redhatinc > @redhatsnaps > > > > -- LUIGI ZUCCARELLI Associate MANAGER , REDHAT MOBILE Red Hat 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 jfrizell at redhat.com Mon Oct 9 09:11:07 2017 From: jfrizell at redhat.com (John Frizelle) Date: Mon, 9 Oct 2017 10:11:07 +0100 Subject: [feedhenry-dev] keycloak-apb -> automated build on docker-hub ? In-Reply-To: References: Message-ID: Big +1 here! CI/CD for the win :-) -- 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 9 October 2017 at 09:23, David Martin wrote: > +1 on automation for keeping the images up to date with master > > On 9 October 2017 at 08:06, Matthias Wessendorf > wrote: > >> Hi, >> >> last week I've converted the "buildfarm-apb" repo ([1]), to an automatic >> build: >> Everytime a PR is merged (to master), a new image is build - instead of >> us doing manually (and inconsistent) uploads of our local builds. >> >> For other 'apb's, like the keycloak-apb, I'd like to do the same; >> >> Any concerns? >> >> Greetings, >> Matthias >> >> >> [1] https://hub.docker.com/r/feedhenry/buildfarm-apb/ >> >> -- >> Project lead AeroGear.org >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > > -- > David Martin > Red Hat Mobile > Twitter: @irldavem > IRC: @irldavem (feedhenry, mobile-internal) > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 11472 bytes Desc: not available URL: From spahuta at redhat.com Mon Oct 9 09:16:25 2017 From: spahuta at redhat.com (Serhii Pahuta) Date: Mon, 9 Oct 2017 11:16:25 +0200 Subject: [feedhenry-dev] Congratulating Summers on 5 great years at Red Hat In-Reply-To: References: Message-ID: Congrats! On Mon, Oct 9, 2017 at 11:02 AM, Luigi Zuccarelli wrote: > Congrats Summers > > On Mon, Oct 9, 2017 at 9:43 AM, Peter Braun wrote: > >> Congratulations Summers! >> >> Am 09.10.2017 um 10:30 schrieb Leigh Griffin : >> >> Hi everyone, >> >> Yesterday Summers marked his 5th anniversary in Red Hat. Summers has led >> the charge on our Open Source efforts for such a long time now that people >> default to him for advice and guidance on all things Open Source. He has >> helped transition the entire Mobile team towards a more Open mentality and >> his work in the SDK team, where he serves as an Android expert, and >> recently in the Mobile.next work is helping to bring our next generation >> offering to fruition. >> >> Summers, congratulations on this immense milestone and wishing you the >> best for the next 5 years. If you could join me in congratulating Summers >> on this great achievement, ideally off list. >> >> Thanks, >> Leigh >> >> -- >> LEIGH GRIFFIN >> >> ENGINEERING MANAGER, MOBILE >> Red Hat Ireland >> Communications House, Cork Road >> Waterford City, Ireland X91NY33 >> >> lgriffin at redhat.com M: +353877545162 IM: lgriffin >> >> TRIED. TESTED. TRUSTED. >> >> @redhatway @redhatinc >> @redhatsnaps >> >> >> >> > > > -- > > LUIGI ZUCCARELLI > > Associate MANAGER , REDHAT MOBILE > > Red Hat 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 vsazel at redhat.com Mon Oct 9 09:31:34 2017 From: vsazel at redhat.com (Vojtech Sazel) Date: Mon, 9 Oct 2017 11:31:34 +0200 Subject: [feedhenry-dev] Congratulating Summers on 5 great years at Red Hat In-Reply-To: References: Message-ID: Congrats Summers! On Mon, Oct 9, 2017 at 11:16 AM, Serhii Pahuta wrote: > Congrats! > > On Mon, Oct 9, 2017 at 11:02 AM, Luigi Zuccarelli > wrote: > >> Congrats Summers >> >> On Mon, Oct 9, 2017 at 9:43 AM, Peter Braun wrote: >> >>> Congratulations Summers! >>> >>> Am 09.10.2017 um 10:30 schrieb Leigh Griffin : >>> >>> Hi everyone, >>> >>> Yesterday Summers marked his 5th anniversary in Red Hat. Summers has led >>> the charge on our Open Source efforts for such a long time now that people >>> default to him for advice and guidance on all things Open Source. He has >>> helped transition the entire Mobile team towards a more Open mentality and >>> his work in the SDK team, where he serves as an Android expert, and >>> recently in the Mobile.next work is helping to bring our next generation >>> offering to fruition. >>> >>> Summers, congratulations on this immense milestone and wishing you the >>> best for the next 5 years. If you could join me in congratulating Summers >>> on this great achievement, ideally off list. >>> >>> Thanks, >>> Leigh >>> >>> -- >>> LEIGH GRIFFIN >>> >>> ENGINEERING MANAGER, MOBILE >>> Red Hat Ireland >>> Communications House, Cork Road >>> Waterford City, Ireland X91NY33 >>> >>> lgriffin at redhat.com M: +353877545162 IM: lgriffin >>> >>> TRIED. TESTED. TRUSTED. >>> >>> @redhatway @redhatinc >>> @redhatsnaps >>> >>> >>> >>> >> >> >> -- >> >> LUIGI ZUCCARELLI >> >> Associate MANAGER , REDHAT MOBILE >> >> Red Hat Mobile >> >> Red Hat Mobile Communications House Ireland >> >> Cork Road Waterford City X91NY33 >> >> lzuccare at redhat.com M: +353852156995 IM: lzuccarelli >> >> TRIED. TESTED. TRUSTED. >> > > -- 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: From jgallaso at redhat.com Mon Oct 9 09:46:29 2017 From: jgallaso at redhat.com (Jose Miguel Gallas Olmedo) Date: Mon, 9 Oct 2017 11:46:29 +0200 Subject: [feedhenry-dev] Congratulating Summers on 5 great years at Red Hat In-Reply-To: References: Message-ID: ?Happy 5 years Summers! ??? JOSE MIGUEL GALLAS OLMEDO ASSOCIATE QE, mobile Red Hat M: +34618488633 On 9 October 2017 at 11:31, Vojtech Sazel wrote: > Congrats Summers! > > > On Mon, Oct 9, 2017 at 11:16 AM, Serhii Pahuta wrote: > >> Congrats! >> >> On Mon, Oct 9, 2017 at 11:02 AM, Luigi Zuccarelli >> wrote: >> >>> Congrats Summers >>> >>> On Mon, Oct 9, 2017 at 9:43 AM, Peter Braun wrote: >>> >>>> Congratulations Summers! >>>> >>>> Am 09.10.2017 um 10:30 schrieb Leigh Griffin : >>>> >>>> Hi everyone, >>>> >>>> Yesterday Summers marked his 5th anniversary in Red Hat. Summers has >>>> led the charge on our Open Source efforts for such a long time now that >>>> people default to him for advice and guidance on all things Open Source. He >>>> has helped transition the entire Mobile team towards a more Open mentality >>>> and his work in the SDK team, where he serves as an Android expert, and >>>> recently in the Mobile.next work is helping to bring our next generation >>>> offering to fruition. >>>> >>>> Summers, congratulations on this immense milestone and wishing you the >>>> best for the next 5 years. If you could join me in congratulating Summers >>>> on this great achievement, ideally off list. >>>> >>>> Thanks, >>>> Leigh >>>> >>>> -- >>>> LEIGH GRIFFIN >>>> >>>> ENGINEERING MANAGER, MOBILE >>>> Red Hat Ireland >>>> Communications House, Cork Road >>>> Waterford City, Ireland X91NY33 >>>> >>>> lgriffin at redhat.com M: +353877545162 IM: lgriffin >>>> >>>> TRIED. TESTED. TRUSTED. >>>> >>>> @redhatway @redhatinc >>>> @redhatsnaps >>>> >>>> >>>> >>>> >>> >>> >>> -- >>> >>> LUIGI ZUCCARELLI >>> >>> Associate MANAGER , REDHAT MOBILE >>> >>> Red Hat Mobile >>> >>> Red Hat Mobile Communications House Ireland >>> >>> Cork Road Waterford City X91NY33 >>> >>> lzuccare at redhat.com M: +353852156995 IM: lzuccarelli >>> >>> TRIED. TESTED. TRUSTED. >>> >> >> > > > -- > > 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: From bofarrel at redhat.com Mon Oct 9 09:48:32 2017 From: bofarrel at redhat.com (Brendan O'Farrell) Date: Mon, 9 Oct 2017 10:48:32 +0100 Subject: [feedhenry-dev] Congratulating Summers on 5 great years at Red Hat In-Reply-To: References: Message-ID: Congrats Summers On Mon, Oct 9, 2017 at 9:30 AM, Leigh Griffin wrote: > Hi everyone, > > Yesterday Summers marked his 5th anniversary in Red Hat. Summers has led > the charge on our Open Source efforts for such a long time now that people > default to him for advice and guidance on all things Open Source. He has > helped transition the entire Mobile team towards a more Open mentality and > his work in the SDK team, where he serves as an Android expert, and > recently in the Mobile.next work is helping to bring our next generation > offering to fruition. > > Summers, congratulations on this immense milestone and wishing you the > best for the next 5 years. If you could join me in congratulating Summers > on this great achievement, ideally off list. > > Thanks, > Leigh > > -- > > LEIGH GRIFFIN > > ENGINEERING MANAGER, MOBILE > > Red Hat Ireland > > Communications House, Cork Road > > Waterford City, Ireland X91NY33 > > lgriffin at redhat.com M: +353877545162 IM: lgriffin > > TRIED. TESTED. TRUSTED. > > @redhatway @redhatinc > @redhatsnaps > > -- BRENDAN O'FARRELL ASSOCIATE ENGINEERING MANAGER, MOBILE Red Hat Ireland Communications House, Cork Road Waterford, Ireland. X91 NY33 bofarrel at redhat.com T: 00353518260110 M: 00353868143848 IM: @bofarrel TRIED. TESTED. TRUSTED. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfrizell at redhat.com Mon Oct 9 10:12:18 2017 From: jfrizell at redhat.com (John Frizelle) Date: Mon, 9 Oct 2017 11:12:18 +0100 Subject: [feedhenry-dev] Self Signed Certs in Android In-Reply-To: References: Message-ID: This is going to be a challenge - not just for us, but for others who try to run our software locally, so we should invest some time and headspace in figuring it out. @Summers - Re: "The second choice is for us to design our API layers such that pins can be injected and used by our underlying HTTP mechanisms" - Can you provide some more information here - it seems like the most robust option from what you have outlined. @Julio - Re: "There is some code you can add to allow connection despite the self signed certificate, but it's not a good option." - Can you provide some more information here please. What are the options for running with just HTTP in development mode - in terms of OpenShift, Android and iOS? I know that apple were planning to mandate everything over https but have pulled back from it a bit... -- 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 6 October 2017 at 17:15, Vojtech Sazel wrote: > Hi, > > I think that MCP will be hosted on site like* openshift.io > *. Doesn't they have simple some container that does > set up Letsencrypt for the subdomain? However > it's necessary to have access to public internet for Letsencrypt. > I think that it would be ok to disable SSL certificate checks for debug > mode apps. > > Vojtech > > On Fri, Oct 6, 2017 at 4:14 PM, Julio Cesar Sanchez Hernandez < > jusanche at redhat.com> wrote: > >> On Cordova Android apps, self signed certificates work in debug but fail >> to connect in release. >> On Cordova iOS and iOS native, self signed certificates don't work, even >> configuring ATS to allow everything, self signed don't fall into the >> "everything". There is some code you can add to allow connection despite >> the self signed certificate, but it's not a good option. Apple might reject >> the app if you forget to remove it before releasing the app. >> >> On Fri, Oct 6, 2017 at 3:17 PM, Summers Pittman >> wrote: >> >>> While I'm testing out MCP and some of the client sdk sync refactoring I >>> regularly get hit with Android not liking self signed certificates.* >>> >>> There are several work around for development such as >>> * setting up and maintaining a CA infrastructure and signing everything >>> in correct fashion >>> * setting up DNS for developer to host their own domains and distribute >>> well signed keys** >>> * injecting a SSL Handler that just doesn't check anything >>> >>> These are impractical, tedious and/or dangerous. I will leave it as an >>> exercise to the reader to decide which is which. >>> >>> However, for development scenarios we have the option of certificate >>> pinning. This is a fancy word for "If you see the certificate at this URL >>> you are golden, ignore the haters".*** There are two general ways to pin, >>> but they each have drawbacks. >>> >>> First, Android N has support for defining pins in your AndroidManifest. >>> Android handles all of the dirty work for you, but this is only in Android >>> N and above. There do seem to be some attempts at back porting, but I >>> haven't researched them too far, >>> >>> The second choice is for us to design our API layers such that pins can >>> be injected and used by our underlying HTTP mechanisms. Many frameworks >>> already support pinning so it shouldn't be too hard to expose, but it will >>> require more coordination and thought. >>> >>> So wdyt? For the next couple of sprints we should be fine just using >>> Android N's pinning, and eventually it will be the default solution. >>> >>> Also, I don't know how self-signed certificates run on cordova, windows, >>> iOS, etc. I wouldn't mind if those platforms' experts chime in. >>> >>> Summers >>> >>> * Java and thus Android won't by default make a connection if the >>> certificate can't be authenticated both by a chain of trust and matching >>> the domain the certificate claims to be for. >>> >>> ** This is kind of what fhcap does. It works great fro Android >>> development in an emulator but isn't practical for testing on devices as >>> the DNS magic has to be set up on the device which fhcap can't control. >>> >>> *** I may have not used the correct technical jargon here. >>> >>> >>> >>> _______________________________________________ >>> 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 >> >> > > > -- > > 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 > > -------------- 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 jusanche at redhat.com Mon Oct 9 10:27:46 2017 From: jusanche at redhat.com (Julio Cesar Sanchez Hernandez) Date: Mon, 9 Oct 2017 12:27:46 +0200 Subject: [feedhenry-dev] Self Signed Certs in Android In-Reply-To: References: Message-ID: This is the code needed @implementation NSURLRequest(DataController) + (BOOL)allowsAnyHTTPSCertificateForHost:(NSString *)host { return YES; } @end Other option is to tell the users to install the certificate on the device and trust it. I'm +1 on using HTTP in development mode if possible On Mon, Oct 9, 2017 at 12:12 PM, John Frizelle wrote: > This is going to be a challenge - not just for us, but for others who try > to run our software locally, so we should invest some time and headspace in > figuring it out. > > @Summers - Re: "The second choice is for us to design our API layers such > that pins can be injected and used by our underlying HTTP mechanisms" - Can > you provide some more information here - it seems like the most robust > option from what you have outlined. > > @Julio - Re: "There is some code you can add to allow connection despite > the self signed certificate, but it's not a good option." - Can you provide > some more information here please. > > What are the options for running with just HTTP in development mode - in > terms of OpenShift, Android and iOS? I know that apple were planning to > mandate everything over https but have pulled back from it a bit... > > > > > -- > 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 6 October 2017 at 17:15, Vojtech Sazel wrote: > >> Hi, >> >> I think that MCP will be hosted on site like* openshift.io >> *. Doesn't they have simple some container that >> does set up Letsencrypt for the subdomain? >> However it's necessary to have access to public internet for Letsencrypt. >> I think that it would be ok to disable SSL certificate checks for debug >> mode apps. >> >> Vojtech >> >> On Fri, Oct 6, 2017 at 4:14 PM, Julio Cesar Sanchez Hernandez < >> jusanche at redhat.com> wrote: >> >>> On Cordova Android apps, self signed certificates work in debug but fail >>> to connect in release. >>> On Cordova iOS and iOS native, self signed certificates don't work, even >>> configuring ATS to allow everything, self signed don't fall into the >>> "everything". There is some code you can add to allow connection despite >>> the self signed certificate, but it's not a good option. Apple might reject >>> the app if you forget to remove it before releasing the app. >>> >>> On Fri, Oct 6, 2017 at 3:17 PM, Summers Pittman >>> wrote: >>> >>>> While I'm testing out MCP and some of the client sdk sync refactoring I >>>> regularly get hit with Android not liking self signed certificates.* >>>> >>>> There are several work around for development such as >>>> * setting up and maintaining a CA infrastructure and signing >>>> everything in correct fashion >>>> * setting up DNS for developer to host their own domains and >>>> distribute well signed keys** >>>> * injecting a SSL Handler that just doesn't check anything >>>> >>>> These are impractical, tedious and/or dangerous. I will leave it as an >>>> exercise to the reader to decide which is which. >>>> >>>> However, for development scenarios we have the option of certificate >>>> pinning. This is a fancy word for "If you see the certificate at this URL >>>> you are golden, ignore the haters".*** There are two general ways to pin, >>>> but they each have drawbacks. >>>> >>>> First, Android N has support for defining pins in your >>>> AndroidManifest. Android handles all of the dirty work for you, but this >>>> is only in Android N and above. There do seem to be some attempts at back >>>> porting, but I haven't researched them too far, >>>> >>>> The second choice is for us to design our API layers such that pins can >>>> be injected and used by our underlying HTTP mechanisms. Many frameworks >>>> already support pinning so it shouldn't be too hard to expose, but it will >>>> require more coordination and thought. >>>> >>>> So wdyt? For the next couple of sprints we should be fine just using >>>> Android N's pinning, and eventually it will be the default solution. >>>> >>>> Also, I don't know how self-signed certificates run on cordova, >>>> windows, iOS, etc. I wouldn't mind if those platforms' experts chime in. >>>> >>>> Summers >>>> >>>> * Java and thus Android won't by default make a connection if the >>>> certificate can't be authenticated both by a chain of trust and matching >>>> the domain the certificate claims to be for. >>>> >>>> ** This is kind of what fhcap does. It works great fro Android >>>> development in an emulator but isn't practical for testing on devices as >>>> the DNS magic has to be set up on the device which fhcap can't control. >>>> >>>> *** I may have not used the correct technical jargon here. >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >> >> >> -- >> >> 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 >> >> > -------------- 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 cbennett at redhat.com Mon Oct 9 10:31:08 2017 From: cbennett at redhat.com (Colum Bennett) Date: Mon, 9 Oct 2017 03:31:08 -0700 Subject: [feedhenry-dev] TypeScript Documentation Message-ID: Hi All, Quick question tot he community, has anyone used the any of the attached links for generating Typescript documentation? Even better can anyone recommend one? Thanks in advance, Colum [1] https://www.npmjs.com/package/tsdoc [2] http://typedoc.org/ __ COL?M BENNETT CONSULTANT, RED HAT MOBILE Red Hat Mobile Communication House, Cork Road, Waterford, Ireland, X91NY33. cbennett at redhat.com T: +353-51-810127 <00353-51-810127> IM: cbennett *Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com .* TRIED. TESTED. TRUSTED. @redhatnews Red Hat Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sig-redhat.png Type: image/png Size: 910 bytes Desc: not available URL: From wtrocki at redhat.com Mon Oct 9 11:01:36 2017 From: wtrocki at redhat.com (Wojciech Trocki) Date: Mon, 9 Oct 2017 12:01:36 +0100 Subject: [feedhenry-dev] TypeScript Documentation In-Reply-To: References: Message-ID: RainCatcher is using typedocs. Feedhenry-JS sdk is using that as well. We done some investigations and considering all requirements we had typedocs was the best tool for the job Main problem I had is that all libraries around generate html only. It will be nice to get something that will generate non html contents like markdown. On Mon, Oct 9, 2017 at 11:31 AM, Colum Bennett wrote: > Hi All, > > Quick question tot he community, has anyone used the any of the attached > links for generating Typescript documentation? Even better can anyone > recommend one? > > Thanks in advance, > > Colum > > > [1] https://www.npmjs.com/package/tsdoc > [2] http://typedoc.org/ > > > __ > > > COL?M BENNETT > > CONSULTANT, RED HAT MOBILE > > Red Hat Mobile > > Communication House, Cork Road, > > Waterford, Ireland, X91NY33. > > cbennett at redhat.com T: +353-51-810127 <00353-51-810127> IM: > cbennett > > *Better technology. Faster innovation. Powered by community collaboration. > See how it works at redhat.com .* > > TRIED. TESTED. TRUSTED. > > @redhatnews Red Hat > Red Hat > > > > > > _______________________________________________ > 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: sig-redhat.png Type: image/png Size: 910 bytes Desc: not available URL: From kpiwko at redhat.com Mon Oct 9 11:05:16 2017 From: kpiwko at redhat.com (Karel Piwko) Date: Mon, 9 Oct 2017 13:05:16 +0200 Subject: [feedhenry-dev] Congratulating Summers on 5 great years at Red Hat In-Reply-To: References: Message-ID: Congrats Summers, well done and thanks for all the contributions so far! Now the next milestone is 10 years ;-) Karel On 9 October 2017 at 10:30, Leigh Griffin wrote: > Hi everyone, > > Yesterday Summers marked his 5th anniversary in Red Hat. Summers has led > the charge on our Open Source efforts for such a long time now that people > default to him for advice and guidance on all things Open Source. He has > helped transition the entire Mobile team towards a more Open mentality and > his work in the SDK team, where he serves as an Android expert, and > recently in the Mobile.next work is helping to bring our next generation > offering to fruition. > > Summers, congratulations on this immense milestone and wishing you the > best for the next 5 years. If you could join me in congratulating Summers > on this great achievement, ideally off list. > > Thanks, > Leigh > > -- > > LEIGH GRIFFIN > > ENGINEERING MANAGER, MOBILE > > Red Hat Ireland > > Communications House, Cork Road > > Waterford City, Ireland X91NY33 > > lgriffin at redhat.com M: +353877545162 IM: lgriffin > > TRIED. TESTED. TRUSTED. > > @redhatway @redhatinc > @redhatsnaps > > -- KAREL PIWKO MANAGER, MOBILE QE Red Hat Czech Republic Purky?ova 647/111 612 00 Brno, Czech Republic kpiwko at redhat.com IM: kpiwko TRIED. TESTED. TRUSTED. @redhatway @redhatinc @redhatsnaps -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Mon Oct 9 12:33:21 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Mon, 9 Oct 2017 14:33:21 +0200 Subject: [feedhenry-dev] keycloak-apb -> automated build on docker-hub ? In-Reply-To: References: Message-ID: alright - will do it On Mon, Oct 9, 2017 at 11:11 AM, John Frizelle wrote: > Big +1 here! > > CI/CD for the win :-) > > -- > 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 9 October 2017 at 09:23, David Martin wrote: > >> +1 on automation for keeping the images up to date with master >> >> On 9 October 2017 at 08:06, Matthias Wessendorf >> wrote: >> >>> Hi, >>> >>> last week I've converted the "buildfarm-apb" repo ([1]), to an automatic >>> build: >>> Everytime a PR is merged (to master), a new image is build - instead of >>> us doing manually (and inconsistent) uploads of our local builds. >>> >>> For other 'apb's, like the keycloak-apb, I'd like to do the same; >>> >>> Any concerns? >>> >>> Greetings, >>> Matthias >>> >>> >>> [1] https://hub.docker.com/r/feedhenry/buildfarm-apb/ >>> >>> -- >>> Project lead AeroGear.org >>> >>> _______________________________________________ >>> feedhenry-dev mailing list >>> feedhenry-dev at redhat.com >>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>> >>> >> >> >> -- >> David Martin >> Red Hat Mobile >> Twitter: @irldavem >> IRC: @irldavem (feedhenry, mobile-internal) >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- 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 Mon Oct 9 12:45:59 2017 From: supittma at redhat.com (Summers Pittman) Date: Mon, 9 Oct 2017 08:45:59 -0400 Subject: [feedhenry-dev] Self Signed Certs in Android In-Reply-To: References: Message-ID: On Mon, Oct 9, 2017 at 6:12 AM, John Frizelle wrote: > This is going to be a challenge - not just for us, but for others who try > to run our software locally, so we should invest some time and headspace in > figuring it out. > > @Summers - Re: "The second choice is for us to design our API layers such > that pins can be injected and used by our underlying HTTP mechanisms" - Can > you provide some more information here - it seems like the most robust > option from what you have outlined. > > Sure thing. Most Android Http libraries provide support for certificate pinning; OkHTTP has this for example : String hostname = "publicobject.com"; CertificatePinner certificatePinner = new CertificatePinner.Builder() .add(hostname, "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=") .build(); OkHttpClient client = OkHttpClient.Builder() .certificatePinner(certificatePinner) .build(); We provide, in code, the certificate hashes and the host names that they are signed for. If all of the MCP support libraries use OkHttp then, for example, we can provide an option for developers to pass in their own configured client to use instead of using one provided by MCP. Another alternative would be providing this information in a configuration file and having our build time or run time tooling parse the file to build our HTTP client. A benefit of the second approach is it doesn't bind our libraries to OkHttp. > @Julio - Re: "There is some code you can add to allow connection despite > the self signed certificate, but it's not a good option." - Can you provide > some more information here please. > > What are the options for running with just HTTP in development mode - in > terms of OpenShift, Android and iOS? I know that apple were planning to > mandate everything over https but have pulled back from it a bit... > > > > > -- > 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 6 October 2017 at 17:15, Vojtech Sazel wrote: > >> Hi, >> >> I think that MCP will be hosted on site like* openshift.io >> *. Doesn't they have simple some container that >> does set up Letsencrypt for the subdomain? >> However it's necessary to have access to public internet for Letsencrypt. >> I think that it would be ok to disable SSL certificate checks for debug >> mode apps. >> >> Vojtech >> >> On Fri, Oct 6, 2017 at 4:14 PM, Julio Cesar Sanchez Hernandez < >> jusanche at redhat.com> wrote: >> >>> On Cordova Android apps, self signed certificates work in debug but fail >>> to connect in release. >>> On Cordova iOS and iOS native, self signed certificates don't work, even >>> configuring ATS to allow everything, self signed don't fall into the >>> "everything". There is some code you can add to allow connection despite >>> the self signed certificate, but it's not a good option. Apple might reject >>> the app if you forget to remove it before releasing the app. >>> >>> On Fri, Oct 6, 2017 at 3:17 PM, Summers Pittman >>> wrote: >>> >>>> While I'm testing out MCP and some of the client sdk sync refactoring I >>>> regularly get hit with Android not liking self signed certificates.* >>>> >>>> There are several work around for development such as >>>> * setting up and maintaining a CA infrastructure and signing >>>> everything in correct fashion >>>> * setting up DNS for developer to host their own domains and >>>> distribute well signed keys** >>>> * injecting a SSL Handler that just doesn't check anything >>>> >>>> These are impractical, tedious and/or dangerous. I will leave it as an >>>> exercise to the reader to decide which is which. >>>> >>>> However, for development scenarios we have the option of certificate >>>> pinning. This is a fancy word for "If you see the certificate at this URL >>>> you are golden, ignore the haters".*** There are two general ways to pin, >>>> but they each have drawbacks. >>>> >>>> First, Android N has support for defining pins in your >>>> AndroidManifest. Android handles all of the dirty work for you, but this >>>> is only in Android N and above. There do seem to be some attempts at back >>>> porting, but I haven't researched them too far, >>>> >>>> The second choice is for us to design our API layers such that pins can >>>> be injected and used by our underlying HTTP mechanisms. Many frameworks >>>> already support pinning so it shouldn't be too hard to expose, but it will >>>> require more coordination and thought. >>>> >>>> So wdyt? For the next couple of sprints we should be fine just using >>>> Android N's pinning, and eventually it will be the default solution. >>>> >>>> Also, I don't know how self-signed certificates run on cordova, >>>> windows, iOS, etc. I wouldn't mind if those platforms' experts chime in. >>>> >>>> Summers >>>> >>>> * Java and thus Android won't by default make a connection if the >>>> certificate can't be authenticated both by a chain of trust and matching >>>> the domain the certificate claims to be for. >>>> >>>> ** This is kind of what fhcap does. It works great fro Android >>>> development in an emulator but isn't practical for testing on devices as >>>> the DNS magic has to be set up on the device which fhcap can't control. >>>> >>>> *** I may have not used the correct technical jargon here. >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >> >> >> -- >> >> 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 >> >> > > _______________________________________________ > 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 Mon Oct 9 12:54:46 2017 From: supittma at redhat.com (Summers Pittman) Date: Mon, 9 Oct 2017 08:54:46 -0400 Subject: [feedhenry-dev] Self Signed Certs in Android In-Reply-To: References: Message-ID: On Mon, Oct 9, 2017 at 8:45 AM, Summers Pittman wrote: > > > On Mon, Oct 9, 2017 at 6:12 AM, John Frizelle wrote: > >> This is going to be a challenge - not just for us, but for others who try >> to run our software locally, so we should invest some time and headspace in >> figuring it out. >> >> @Summers - Re: "The second choice is for us to design our API layers such >> that pins can be injected and used by our underlying HTTP mechanisms" - Can >> you provide some more information here - it seems like the most robust >> option from what you have outlined. >> >> > Sure thing. > > Most Android Http libraries provide support for certificate pinning; > OkHTTP has this for example : > > String hostname = "publicobject.com"; > CertificatePinner certificatePinner = new CertificatePinner.Builder() > .add(hostname, "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=") > .build(); > OkHttpClient client = OkHttpClient.Builder() > .certificatePinner(certificatePinner) > .build(); > > We provide, in code, the certificate hashes and the host names that they > are signed for. If all of the MCP support libraries use OkHttp then, for > example, we can provide an option for developers to pass in their own > configured client to use instead of using one provided by MCP. Another > alternative would be providing this information in a configuration file and > having our build time or run time tooling parse the file to build our HTTP > client. A benefit of the second approach is it doesn't bind our libraries > to OkHttp. > > > I'm actually starting to like it more. If you only put your pinning configurations in non release Android build flavors then they won't "leak" into production. The mcp plugin could take care of this automatically even. > > > > > >> @Julio - Re: "There is some code you can add to allow connection despite >> the self signed certificate, but it's not a good option." - Can you provide >> some more information here please. >> >> What are the options for running with just HTTP in development mode - in >> terms of OpenShift, Android and iOS? I know that apple were planning to >> mandate everything over https but have pulled back from it a bit... >> >> >> >> >> -- >> 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 6 October 2017 at 17:15, Vojtech Sazel wrote: >> >>> Hi, >>> >>> I think that MCP will be hosted on site like* openshift.io >>> *. Doesn't they have simple some container that >>> does set up Letsencrypt for the subdomain? >>> However it's necessary to have access to public internet for Letsencrypt. >>> I think that it would be ok to disable SSL certificate checks for debug >>> mode apps. >>> >>> Vojtech >>> >>> On Fri, Oct 6, 2017 at 4:14 PM, Julio Cesar Sanchez Hernandez < >>> jusanche at redhat.com> wrote: >>> >>>> On Cordova Android apps, self signed certificates work in debug but >>>> fail to connect in release. >>>> On Cordova iOS and iOS native, self signed certificates don't work, >>>> even configuring ATS to allow everything, self signed don't fall into the >>>> "everything". There is some code you can add to allow connection despite >>>> the self signed certificate, but it's not a good option. Apple might reject >>>> the app if you forget to remove it before releasing the app. >>>> >>>> On Fri, Oct 6, 2017 at 3:17 PM, Summers Pittman >>>> wrote: >>>> >>>>> While I'm testing out MCP and some of the client sdk sync refactoring >>>>> I regularly get hit with Android not liking self signed certificates.* >>>>> >>>>> There are several work around for development such as >>>>> * setting up and maintaining a CA infrastructure and signing >>>>> everything in correct fashion >>>>> * setting up DNS for developer to host their own domains and >>>>> distribute well signed keys** >>>>> * injecting a SSL Handler that just doesn't check anything >>>>> >>>>> These are impractical, tedious and/or dangerous. I will leave it as >>>>> an exercise to the reader to decide which is which. >>>>> >>>>> However, for development scenarios we have the option of certificate >>>>> pinning. This is a fancy word for "If you see the certificate at this URL >>>>> you are golden, ignore the haters".*** There are two general ways to pin, >>>>> but they each have drawbacks. >>>>> >>>>> First, Android N has support for defining pins in your >>>>> AndroidManifest. Android handles all of the dirty work for you, but this >>>>> is only in Android N and above. There do seem to be some attempts at back >>>>> porting, but I haven't researched them too far, >>>>> >>>>> The second choice is for us to design our API layers such that pins >>>>> can be injected and used by our underlying HTTP mechanisms. Many >>>>> frameworks already support pinning so it shouldn't be too hard to expose, >>>>> but it will require more coordination and thought. >>>>> >>>>> So wdyt? For the next couple of sprints we should be fine just using >>>>> Android N's pinning, and eventually it will be the default solution. >>>>> >>>>> Also, I don't know how self-signed certificates run on cordova, >>>>> windows, iOS, etc. I wouldn't mind if those platforms' experts chime in. >>>>> >>>>> Summers >>>>> >>>>> * Java and thus Android won't by default make a connection if the >>>>> certificate can't be authenticated both by a chain of trust and matching >>>>> the domain the certificate claims to be for. >>>>> >>>>> ** This is kind of what fhcap does. It works great fro Android >>>>> development in an emulator but isn't practical for testing on devices as >>>>> the DNS magic has to be set up on the device which fhcap can't control. >>>>> >>>>> *** I may have not used the correct technical jargon here. >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>> >>> >>> -- >>> >>> 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 >>> >>> >> >> _______________________________________________ >> 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 Mon Oct 9 13:06:28 2017 From: supittma at redhat.com (Summers Pittman) Date: Mon, 9 Oct 2017 09:06:28 -0400 Subject: [feedhenry-dev] Self Signed Certs in Android In-Reply-To: References: Message-ID: On Fri, Oct 6, 2017 at 12:15 PM, Vojtech Sazel wrote: > Hi, > > I think that MCP will be hosted on site like* openshift.io > *. Doesn't they have simple some container that does > set up Letsencrypt for the subdomain? However > it's necessary to have access to public internet for Letsencrypt. > I think that it would be ok to disable SSL certificate checks for debug > mode apps. > If MCP is hosted on services with a robust SSL answer, yes. Getting MCP into a service and hosting it for free is a pretty big ask from a host and there will probably be people who want to run it "on site". I'm of two minds on looser SSL in debug modes. On the one hand it makes development faster and moves hurdles down the road so users can evaluate and learn without a lot of trouble. On the other hand a lot of debug code tends to find its way into production, and there are production situations where you may be using a trusted but self signed certificate (ie internal services) when an app is "released". > > Vojtech > > On Fri, Oct 6, 2017 at 4:14 PM, Julio Cesar Sanchez Hernandez < > jusanche at redhat.com> wrote: > >> On Cordova Android apps, self signed certificates work in debug but fail >> to connect in release. >> On Cordova iOS and iOS native, self signed certificates don't work, even >> configuring ATS to allow everything, self signed don't fall into the >> "everything". There is some code you can add to allow connection despite >> the self signed certificate, but it's not a good option. Apple might reject >> the app if you forget to remove it before releasing the app. >> >> On Fri, Oct 6, 2017 at 3:17 PM, Summers Pittman >> wrote: >> >>> While I'm testing out MCP and some of the client sdk sync refactoring I >>> regularly get hit with Android not liking self signed certificates.* >>> >>> There are several work around for development such as >>> * setting up and maintaining a CA infrastructure and signing everything >>> in correct fashion >>> * setting up DNS for developer to host their own domains and distribute >>> well signed keys** >>> * injecting a SSL Handler that just doesn't check anything >>> >>> These are impractical, tedious and/or dangerous. I will leave it as an >>> exercise to the reader to decide which is which. >>> >>> However, for development scenarios we have the option of certificate >>> pinning. This is a fancy word for "If you see the certificate at this URL >>> you are golden, ignore the haters".*** There are two general ways to pin, >>> but they each have drawbacks. >>> >>> First, Android N has support for defining pins in your AndroidManifest. >>> Android handles all of the dirty work for you, but this is only in Android >>> N and above. There do seem to be some attempts at back porting, but I >>> haven't researched them too far, >>> >>> The second choice is for us to design our API layers such that pins can >>> be injected and used by our underlying HTTP mechanisms. Many frameworks >>> already support pinning so it shouldn't be too hard to expose, but it will >>> require more coordination and thought. >>> >>> So wdyt? For the next couple of sprints we should be fine just using >>> Android N's pinning, and eventually it will be the default solution. >>> >>> Also, I don't know how self-signed certificates run on cordova, windows, >>> iOS, etc. I wouldn't mind if those platforms' experts chime in. >>> >>> Summers >>> >>> * Java and thus Android won't by default make a connection if the >>> certificate can't be authenticated both by a chain of trust and matching >>> the domain the certificate claims to be for. >>> >>> ** This is kind of what fhcap does. It works great fro Android >>> development in an emulator but isn't practical for testing on devices as >>> the DNS magic has to be set up on the device which fhcap can't control. >>> >>> *** I may have not used the correct technical jargon here. >>> >>> >>> >>> _______________________________________________ >>> 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 >> >> > > > -- > > 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: From mogrodni at redhat.com Mon Oct 9 14:44:35 2017 From: mogrodni at redhat.com (Michal Ogrodniczak) Date: Mon, 9 Oct 2017 15:44:35 +0100 Subject: [feedhenry-dev] Congratulating Summers on 5 great years at Red Hat In-Reply-To: References: Message-ID: Congratulations Summers! MICHAL OGRODNICZAK ASSOCIATE SOFTWARE ENGINEER Red Hat Mobile Communications House, Cork Road Waterford City, Ireland X91NY33 mogrodni at redhat.com TRIED. TESTED. TRUSTED. @redhatnews Red Hat Red Hat On Mon, Oct 9, 2017 at 12:05 PM, Karel Piwko wrote: > Congrats Summers, well done and thanks for all the contributions so far! > Now the next milestone is 10 years ;-) > > Karel > > On 9 October 2017 at 10:30, Leigh Griffin wrote: > >> Hi everyone, >> >> Yesterday Summers marked his 5th anniversary in Red Hat. Summers has led >> the charge on our Open Source efforts for such a long time now that people >> default to him for advice and guidance on all things Open Source. He has >> helped transition the entire Mobile team towards a more Open mentality and >> his work in the SDK team, where he serves as an Android expert, and >> recently in the Mobile.next work is helping to bring our next generation >> offering to fruition. >> >> Summers, congratulations on this immense milestone and wishing you the >> best for the next 5 years. If you could join me in congratulating Summers >> on this great achievement, ideally off list. >> >> Thanks, >> Leigh >> >> -- >> >> LEIGH GRIFFIN >> >> ENGINEERING MANAGER, MOBILE >> >> Red Hat Ireland >> >> Communications House, Cork Road >> >> Waterford City, Ireland X91NY33 >> >> lgriffin at redhat.com M: +353877545162 IM: lgriffin >> >> TRIED. TESTED. TRUSTED. >> >> @redhatway @redhatinc >> @redhatsnaps >> >> > > > > -- > > KAREL PIWKO > > MANAGER, MOBILE QE > > Red Hat Czech Republic > > Purky?ova 647/111 > > 612 00 Brno, Czech Republic > > kpiwko at redhat.com IM: kpiwko > > TRIED. TESTED. TRUSTED. > @redhatway @redhatinc > @redhatsnaps > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Mon Oct 9 18:08:52 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Mon, 9 Oct 2017 20:08:52 +0200 Subject: [feedhenry-dev] Congratulating Summers on 5 great years at Red Hat In-Reply-To: References: Message-ID: Congrats, Summers! -M On Mon, Oct 9, 2017 at 1:05 PM, Karel Piwko wrote: > Congrats Summers, well done and thanks for all the contributions so far! > Now the next milestone is 10 years ;-) > > Karel > > On 9 October 2017 at 10:30, Leigh Griffin wrote: > >> Hi everyone, >> >> Yesterday Summers marked his 5th anniversary in Red Hat. Summers has led >> the charge on our Open Source efforts for such a long time now that people >> default to him for advice and guidance on all things Open Source. He has >> helped transition the entire Mobile team towards a more Open mentality and >> his work in the SDK team, where he serves as an Android expert, and >> recently in the Mobile.next work is helping to bring our next generation >> offering to fruition. >> >> Summers, congratulations on this immense milestone and wishing you the >> best for the next 5 years. If you could join me in congratulating Summers >> on this great achievement, ideally off list. >> >> Thanks, >> Leigh >> >> -- >> >> LEIGH GRIFFIN >> >> ENGINEERING MANAGER, MOBILE >> >> Red Hat Ireland >> >> Communications House, Cork Road >> >> Waterford City, Ireland X91NY33 >> >> lgriffin at redhat.com M: +353877545162 IM: lgriffin >> >> TRIED. TESTED. TRUSTED. >> >> @redhatway @redhatinc >> @redhatsnaps >> >> > > > > -- > > KAREL PIWKO > > MANAGER, MOBILE QE > > Red Hat Czech Republic > > Purky?ova 647/111 > > 612 00 Brno, Czech Republic > > kpiwko at redhat.com IM: kpiwko > > TRIED. TESTED. TRUSTED. > @redhatway @redhatinc > @redhatsnaps > > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfreer at redhat.com Tue Oct 10 07:30:42 2017 From: mfreer at redhat.com (Mark Freer) Date: Tue, 10 Oct 2017 08:30:42 +0100 Subject: [feedhenry-dev] Congratulating Summers on 5 great years at Red Hat In-Reply-To: References: Message-ID: Congrats on the milestone Summers On Mon, Oct 9, 2017 at 7:08 PM, Matthias Wessendorf wrote: > Congrats, Summers! > > -M > > On Mon, Oct 9, 2017 at 1:05 PM, Karel Piwko wrote: > >> Congrats Summers, well done and thanks for all the contributions so far! >> Now the next milestone is 10 years ;-) >> >> Karel >> >> On 9 October 2017 at 10:30, Leigh Griffin wrote: >> >>> Hi everyone, >>> >>> Yesterday Summers marked his 5th anniversary in Red Hat. Summers has led >>> the charge on our Open Source efforts for such a long time now that people >>> default to him for advice and guidance on all things Open Source. He has >>> helped transition the entire Mobile team towards a more Open mentality and >>> his work in the SDK team, where he serves as an Android expert, and >>> recently in the Mobile.next work is helping to bring our next generation >>> offering to fruition. >>> >>> Summers, congratulations on this immense milestone and wishing you the >>> best for the next 5 years. If you could join me in congratulating Summers >>> on this great achievement, ideally off list. >>> >>> Thanks, >>> Leigh >>> >>> -- >>> >>> LEIGH GRIFFIN >>> >>> ENGINEERING MANAGER, MOBILE >>> >>> Red Hat Ireland >>> >>> Communications House, Cork Road >>> >>> Waterford City, Ireland X91NY33 >>> >>> lgriffin at redhat.com M: +353877545162 IM: lgriffin >>> >>> TRIED. TESTED. TRUSTED. >>> >>> @redhatway @redhatinc >>> @redhatsnaps >>> >>> >> >> >> >> -- >> >> KAREL PIWKO >> >> MANAGER, MOBILE QE >> >> Red Hat Czech Republic >> >> Purky?ova 647/111 >> >> 612 00 Brno, Czech Republic >> >> kpiwko at redhat.com IM: kpiwko >> >> TRIED. TESTED. TRUSTED. >> @redhatway @redhatinc >> @redhatsnaps >> >> > > > > -- > Project lead AeroGear.org > -- Mark Freer Senior Operations Engineer *Red Hat Mobile * Email: mfreer at redhat.com IRC: @mfreer (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From damurphy at redhat.com Tue Oct 10 08:22:50 2017 From: damurphy at redhat.com (Damien Murphy) Date: Tue, 10 Oct 2017 09:22:50 +0100 Subject: [feedhenry-dev] Congratulating Summers on 5 great years at Red Hat In-Reply-To: References: Message-ID: Congratulations on the milestone Summers - time for 10 now ;D On 10 October 2017 at 08:30, Mark Freer wrote: > Congrats on the milestone Summers > > On Mon, Oct 9, 2017 at 7:08 PM, Matthias Wessendorf > wrote: > >> Congrats, Summers! >> >> -M >> >> On Mon, Oct 9, 2017 at 1:05 PM, Karel Piwko wrote: >> >>> Congrats Summers, well done and thanks for all the contributions so far! >>> Now the next milestone is 10 years ;-) >>> >>> Karel >>> >>> On 9 October 2017 at 10:30, Leigh Griffin wrote: >>> >>>> Hi everyone, >>>> >>>> Yesterday Summers marked his 5th anniversary in Red Hat. Summers has >>>> led the charge on our Open Source efforts for such a long time now that >>>> people default to him for advice and guidance on all things Open Source. He >>>> has helped transition the entire Mobile team towards a more Open mentality >>>> and his work in the SDK team, where he serves as an Android expert, and >>>> recently in the Mobile.next work is helping to bring our next generation >>>> offering to fruition. >>>> >>>> Summers, congratulations on this immense milestone and wishing you the >>>> best for the next 5 years. If you could join me in congratulating Summers >>>> on this great achievement, ideally off list. >>>> >>>> Thanks, >>>> Leigh >>>> >>>> -- >>>> >>>> LEIGH GRIFFIN >>>> >>>> ENGINEERING MANAGER, MOBILE >>>> >>>> Red Hat Ireland >>>> >>>> Communications House, Cork Road >>>> >>>> Waterford City, Ireland X91NY33 >>>> >>>> lgriffin at redhat.com M: +353877545162 IM: lgriffin >>>> >>>> TRIED. TESTED. TRUSTED. >>>> >>>> @redhatway @redhatinc >>>> @redhatsnaps >>>> >>>> >>> >>> >>> >>> -- >>> >>> KAREL PIWKO >>> >>> MANAGER, MOBILE QE >>> >>> Red Hat Czech Republic >>> >>> Purky?ova 647/111 >>> >>> 612 00 Brno, Czech Republic >>> >>> kpiwko at redhat.com IM: kpiwko >>> >>> TRIED. TESTED. TRUSTED. >>> @redhatway @redhatinc >>> @redhatsnaps >>> >>> >> >> >> >> -- >> Project lead AeroGear.org >> > > > > -- > Mark Freer > Senior Operations Engineer > *Red Hat Mobile * > Email: mfreer at redhat.com > IRC: @mfreer (feedhenry, mobile-internal) > -- DAMIEN MURPHY SOFTWARE ENGINEER Red Hat Mobile IM: damurphy -------------- next part -------------- An HTML attachment was scrubbed... URL: From cbennett at redhat.com Tue Oct 10 08:43:32 2017 From: cbennett at redhat.com (Colum Bennett) Date: Tue, 10 Oct 2017 10:43:32 +0200 Subject: [feedhenry-dev] TypeScript Documentation In-Reply-To: References: Message-ID: +1 for markdown output. HTML is fine for current use case. I like typedoc, it is nice and easy to use. I would certainly recommend it. Colum __ COL?M BENNETT CONSULTANT, RED HAT MOBILE Red Hat Mobile Communication House, Cork Road, Waterford, Ireland, X91NY33. cbennett at redhat.com T: +353-51-810127 <00353-51-810127> IM: cbennett *Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com .* TRIED. TESTED. TRUSTED. @redhatnews Red Hat Red Hat On 9 October 2017 at 12:02:19, Wojciech Trocki (wtrocki at redhat.com) wrote: RainCatcher is using typedocs. Feedhenry-JS sdk is using that as well. We done some investigations and considering all requirements we had typedocs was the best tool for the job Main problem I had is that all libraries around generate html only. It will be nice to get something that will generate non html contents like markdown. On Mon, Oct 9, 2017 at 11:31 AM, Colum Bennett wrote: > Hi All, > > Quick question tot he community, has anyone used the any of the attached > links for generating Typescript documentation? Even better can anyone > recommend one? > > Thanks in advance, > > Colum > > > [1] https://www.npmjs.com/package/tsdoc > [2] http://typedoc.org/ > > > __ > > > COL?M BENNETT > > CONSULTANT, RED HAT MOBILE > > Red Hat Mobile > > Communication House, Cork Road, > > Waterford, Ireland, X91NY33. > > cbennett at redhat.com T: +353-51-810127 <00353-51-810127> IM: > cbennett > > *Better technology. Faster innovation. Powered by community collaboration. > See how it works at redhat.com .* > > TRIED. TESTED. TRUSTED. > > @redhatnews Red Hat > Red Hat > > > > > > _______________________________________________ > 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: D81C92E6-32FD-45A0-B403-9D98A40E1BFF Type: application/octet-stream Size: 910 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sig-redhat.png Type: image/png Size: 910 bytes Desc: not available URL: From jmadigan at redhat.com Tue Oct 10 10:42:01 2017 From: jmadigan at redhat.com (Jason Madigan) Date: Tue, 10 Oct 2017 11:42:01 +0100 Subject: [feedhenry-dev] Congratulating Summers on 5 great years at Red Hat In-Reply-To: References: Message-ID: Congrats Summers! On Mon, Oct 9, 2017 at 9:30 AM, Leigh Griffin wrote: > Hi everyone, > > Yesterday Summers marked his 5th anniversary in Red Hat. Summers has led > the charge on our Open Source efforts for such a long time now that people > default to him for advice and guidance on all things Open Source. He has > helped transition the entire Mobile team towards a more Open mentality and > his work in the SDK team, where he serves as an Android expert, and > recently in the Mobile.next work is helping to bring our next generation > offering to fruition. > > Summers, congratulations on this immense milestone and wishing you the > best for the next 5 years. If you could join me in congratulating Summers > on this great achievement, ideally off list. > > Thanks, > Leigh > > -- > > LEIGH GRIFFIN > > ENGINEERING MANAGER, MOBILE > > Red Hat Ireland > > Communications House, Cork Road > > Waterford City, Ireland X91NY33 > > lgriffin at redhat.com M: +353877545162 IM: lgriffin > > TRIED. TESTED. TRUSTED. > > @redhatway @redhatinc > @redhatsnaps > > -- Jason Madigan Engineering Manager, Red Hat Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: From edewit at redhat.com Tue Oct 10 11:34:11 2017 From: edewit at redhat.com (Erik Jan de Wit) Date: Tue, 10 Oct 2017 13:34:11 +0200 Subject: [feedhenry-dev] Congratulating Summers on 5 great years at Red Hat In-Reply-To: References: Message-ID: Congrats Summers! On Tue, Oct 10, 2017 at 12:42 PM, Jason Madigan wrote: > Congrats Summers! > > On Mon, Oct 9, 2017 at 9:30 AM, Leigh Griffin wrote: > >> Hi everyone, >> >> Yesterday Summers marked his 5th anniversary in Red Hat. Summers has led >> the charge on our Open Source efforts for such a long time now that people >> default to him for advice and guidance on all things Open Source. He has >> helped transition the entire Mobile team towards a more Open mentality and >> his work in the SDK team, where he serves as an Android expert, and >> recently in the Mobile.next work is helping to bring our next generation >> offering to fruition. >> >> Summers, congratulations on this immense milestone and wishing you the >> best for the next 5 years. If you could join me in congratulating Summers >> on this great achievement, ideally off list. >> >> Thanks, >> Leigh >> >> -- >> >> LEIGH GRIFFIN >> >> ENGINEERING MANAGER, MOBILE >> >> Red Hat Ireland >> >> Communications House, Cork Road >> >> Waterford City, Ireland X91NY33 >> >> lgriffin at redhat.com M: +353877545162 IM: lgriffin >> >> TRIED. TESTED. TRUSTED. >> >> @redhatway @redhatinc >> @redhatsnaps >> >> > > > > -- > Jason Madigan > Engineering Manager, Red Hat Mobile > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- Cheers, Erik Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmadigan at redhat.com Tue Oct 10 12:03:55 2017 From: jmadigan at redhat.com (Jason Madigan) Date: Tue, 10 Oct 2017 13:03:55 +0100 Subject: [feedhenry-dev] Opening up our MCP comms Message-ID: Hi all, I wanted to shoot an email to list to let folks know that we're going to be making some changes to communication around our Mobile.Next() efforts, particularly around opening up discussion and comms from our MCP team. From here on out, I'd like to propose that we send the following things from the MCP team to this open list: - Decisions (e.g. sprint focus changes from the MCP team, direction changes, big tech/approach changes etc.) - Sprint Boundary updates (e.g. Sprint End & Sprint Start) - Team changes (e.g. membership, cross-functional initiatives) If folks have strong opinions about what not to use an ML for, obviously feel free to discuss in this open forum. It's always a balancing act between signal and noise here, so hoping that we'll be able to strike the right balance with our open comms so that we don't lean too much towards the latter. Thanks, - Jason -- Jason Madigan Engineering Manager, Red Hat Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmadigan at redhat.com Tue Oct 10 12:10:14 2017 From: jmadigan at redhat.com (Jason Madigan) Date: Tue, 10 Oct 2017 13:10:14 +0100 Subject: [feedhenry-dev] MCP PoC - Sprint 5 Goals (and a brief recap on Sprint 4) Message-ID: Hi folks, Just a quick email to let everyone know what goals we've got for Sprint 5 on the Mobile Control Panel PoC. We finish Sprint 4 up a little early, when we decided that for our PoC, AeroGear Digger integration up to Android Debug builds was arguably enough (Digger's a pretty known quantity, and we can pick up where we left off later), and we can shift focus to some of our other PoC integration goals now. Next in line is 3scale integration - we're looking at establishing a steel-thread integration similar to KeyCloak and AeroGear Digger (e.g. an APB, provisioning via the service catalog, and some demonstration of integration with other services). We're looking into 3scale apicast fronting Sync and KeyCloak as a goal. There's also a small mini-goal to create an APB (ansible-playbook) for Sync also, to standardise on using APBs for provisioning (since we feel it works well). There will be some demos from Sprint 4 later this week from Aiden, demonstrating our new Digger integration with MCP. >From here on out, we'll send emails to the list at sprint boundaries (e.g. the Reviews and after Planning). Thanks everyone, - Jason -- Jason Madigan Engineering Manager, Red Hat Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Tue Oct 10 13:17:28 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Tue, 10 Oct 2017 15:17:28 +0200 Subject: [feedhenry-dev] Opening up our MCP comms In-Reply-To: References: Message-ID: Hey Jason, IMO these items are perfectly fine and make sure that _important_ discussions are persisted / summarized on ML. For more chatters there is always IRC ;-) -M On Tue, Oct 10, 2017 at 2:03 PM, Jason Madigan wrote: > Hi all, > > I wanted to shoot an email to list to let folks know that we're going to > be making some changes to communication around our Mobile.Next() efforts, > particularly around opening up discussion and comms from our MCP team. From > here on out, I'd like to propose that we send the following things from the > MCP team to this open list: > > - Decisions (e.g. sprint focus changes from the MCP team, direction > changes, big tech/approach changes etc.) > - Sprint Boundary updates (e.g. Sprint End & Sprint Start) > - Team changes (e.g. membership, cross-functional initiatives) > > If folks have strong opinions about what not to use an ML for, obviously > feel free to discuss in this open forum. It's always a balancing act > between signal and noise here, so hoping that we'll be able to strike the > right balance with our open comms so that we don't lean too much towards > the latter. > > Thanks, > > - Jason > > -- > Jason Madigan > Engineering Manager, Red Hat Mobile > > _______________________________________________ > 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 lgriffin at redhat.com Tue Oct 10 13:39:56 2017 From: lgriffin at redhat.com (Leigh Griffin) Date: Tue, 10 Oct 2017 14:39:56 +0100 Subject: [feedhenry-dev] Opening up our MCP comms In-Reply-To: References: Message-ID: +1 I think it's great to be open and as we involve more products from an interlock perspective the ML becomes the natural convergence point. It's also a good exercise to figure out our Agile model in the open and figure out how to effectively run our Sprints in that manner. While I expect hiccups, we will resolve them and will give ourselves an opportunity to share this with other teams how we work. That level of transparency can only be a good thing :) Leigh On Tue, Oct 10, 2017 at 1:03 PM, Jason Madigan wrote: > Hi all, > > I wanted to shoot an email to list to let folks know that we're going to > be making some changes to communication around our Mobile.Next() efforts, > particularly around opening up discussion and comms from our MCP team. From > here on out, I'd like to propose that we send the following things from the > MCP team to this open list: > > - Decisions (e.g. sprint focus changes from the MCP team, direction > changes, big tech/approach changes etc.) > - Sprint Boundary updates (e.g. Sprint End & Sprint Start) > - Team changes (e.g. membership, cross-functional initiatives) > > If folks have strong opinions about what not to use an ML for, obviously > feel free to discuss in this open forum. It's always a balancing act > between signal and noise here, so hoping that we'll be able to strike the > right balance with our open comms so that we don't lean too much towards > the latter. > > Thanks, > > - Jason > > -- > Jason Madigan > Engineering Manager, Red Hat Mobile > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- LEIGH GRIFFIN ENGINEERING MANAGER, MOBILE Red Hat Ireland Communications House, Cork Road Waterford City, Ireland X91NY33 lgriffin at redhat.com M: +353877545162 IM: lgriffin TRIED. TESTED. TRUSTED. @redhatway @redhatinc @redhatsnaps -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbrookes at redhat.com Tue Oct 10 14:55:53 2017 From: pbrookes at redhat.com (Phil Brookes) Date: Tue, 10 Oct 2017 15:55:53 +0100 Subject: [feedhenry-dev] Update to workflow for APB development Message-ID: Hello Everyone, The current development workflow for APB?s is to run a local oc cluster with the ASB scanning the feedhenry docker org for APB images. Then pushing our development images to the feedhenry repo to test them. As more developers start using these images we increase the possibility that they will pull a broken development image which could lead to a pretty significant waste of developer time trying to identify the problem and could also reduce developers trust in the feedhenry APB images. To address this it is now only possible to update the APB images in the feedhenry org via a merged PR to the master branch of that images github repo. To develop your own changes to an APB you should instead point the ASB of your local oc cluster at your own docker org and push a copy of any APBs you wish to use into that org from the feedhenry org. When building experimental APB images you should update the image in that APB?s apb.yml file, and use make DOCKERORG= to build and push the development APB image. I will be updating the ansible installer in the mcp-standalone repo to automatically pull the APB images from feedhenry and push them into the specified dockerorg in the near future, so we have less manual work to do. Any questions or concerns, please let me know. Thanks, Phil. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From supittma at redhat.com Tue Oct 10 16:01:09 2017 From: supittma at redhat.com (Summers Pittman) Date: Tue, 10 Oct 2017 12:01:09 -0400 Subject: [feedhenry-dev] Congratulating Summers on 5 great years at Red Hat In-Reply-To: References: Message-ID: Thanks for all of the kudos guys, You are a blast to work with. Here's to five more. And for cake, here's a group project I was in for college in 2004 : https://github.com/secondsun/albumserver. Take a look at this and this if you want to see how students thought client/server protocols worked 13 years ago. On Tue, Oct 10, 2017 at 7:34 AM, Erik Jan de Wit wrote: > Congrats Summers! > > On Tue, Oct 10, 2017 at 12:42 PM, Jason Madigan > wrote: > >> Congrats Summers! >> >> On Mon, Oct 9, 2017 at 9:30 AM, Leigh Griffin >> wrote: >> >>> Hi everyone, >>> >>> Yesterday Summers marked his 5th anniversary in Red Hat. Summers has led >>> the charge on our Open Source efforts for such a long time now that people >>> default to him for advice and guidance on all things Open Source. He has >>> helped transition the entire Mobile team towards a more Open mentality and >>> his work in the SDK team, where he serves as an Android expert, and >>> recently in the Mobile.next work is helping to bring our next generation >>> offering to fruition. >>> >>> Summers, congratulations on this immense milestone and wishing you the >>> best for the next 5 years. If you could join me in congratulating Summers >>> on this great achievement, ideally off list. >>> >>> Thanks, >>> Leigh >>> >>> -- >>> >>> LEIGH GRIFFIN >>> >>> ENGINEERING MANAGER, MOBILE >>> >>> Red Hat Ireland >>> >>> Communications House, Cork Road >>> >>> Waterford City, Ireland X91NY33 >>> >>> lgriffin at redhat.com M: +353877545162 IM: lgriffin >>> >>> TRIED. TESTED. TRUSTED. >>> >>> @redhatway @redhatinc >>> @redhatsnaps >>> >>> >> >> >> >> -- >> Jason Madigan >> Engineering Manager, Red Hat Mobile >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > > -- > Cheers, > Erik Jan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eshortis at redhat.com Tue Oct 10 17:04:23 2017 From: eshortis at redhat.com (Evan Shortiss) Date: Tue, 10 Oct 2017 10:04:23 -0700 Subject: [feedhenry-dev] Congratulating Summers on 5 great years at Red Hat In-Reply-To: References: Message-ID: Congrats Summers! On Tue, Oct 10, 2017 at 9:01 AM, Summers Pittman wrote: > Thanks for all of the kudos guys, You are a blast to work with. > > Here's to five more. > > And for cake, here's a group project I was in for college in 2004 : > https://github.com/secondsun/albumserver. Take a look at this > and > this > if > you want to see how students thought client/server protocols worked 13 > years ago. > > > > On Tue, Oct 10, 2017 at 7:34 AM, Erik Jan de Wit > wrote: > >> Congrats Summers! >> >> On Tue, Oct 10, 2017 at 12:42 PM, Jason Madigan >> wrote: >> >>> Congrats Summers! >>> >>> On Mon, Oct 9, 2017 at 9:30 AM, Leigh Griffin >>> wrote: >>> >>>> Hi everyone, >>>> >>>> Yesterday Summers marked his 5th anniversary in Red Hat. Summers has >>>> led the charge on our Open Source efforts for such a long time now that >>>> people default to him for advice and guidance on all things Open Source. He >>>> has helped transition the entire Mobile team towards a more Open mentality >>>> and his work in the SDK team, where he serves as an Android expert, and >>>> recently in the Mobile.next work is helping to bring our next generation >>>> offering to fruition. >>>> >>>> Summers, congratulations on this immense milestone and wishing you the >>>> best for the next 5 years. If you could join me in congratulating Summers >>>> on this great achievement, ideally off list. >>>> >>>> Thanks, >>>> Leigh >>>> >>>> -- >>>> >>>> LEIGH GRIFFIN >>>> >>>> ENGINEERING MANAGER, MOBILE >>>> >>>> Red Hat Ireland >>>> >>>> Communications House, Cork Road >>>> >>>> Waterford City, Ireland X91NY33 >>>> >>>> lgriffin at redhat.com M: +353877545162 IM: lgriffin >>>> >>>> TRIED. TESTED. TRUSTED. >>>> >>>> @redhatway @redhatinc >>>> @redhatsnaps >>>> >>>> >>> >>> >>> >>> -- >>> Jason Madigan >>> Engineering Manager, Red Hat Mobile >>> >>> _______________________________________________ >>> feedhenry-dev mailing list >>> feedhenry-dev at redhat.com >>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>> >>> >> >> >> -- >> Cheers, >> Erik Jan >> > > -- EVAN SHORTISS MOBILE PRACTICE ARCHITECT, RED HAT MOBILE Los Angeles, USA evan.shortiss at redhat.com M: +1-781-354-2834 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfrizell at redhat.com Tue Oct 10 20:01:31 2017 From: jfrizell at redhat.com (John Frizelle) Date: Tue, 10 Oct 2017 21:01:31 +0100 Subject: [feedhenry-dev] Update to workflow for APB development In-Reply-To: References: Message-ID: Hi Phil, Thanks for the mail & agree with the suggestions. Are there any docs available that detail how to "point the ASB of your local oc cluster at your own docker org and push a copy of any APBs you wish to use into that org from the feedhenry org"? 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 10 October 2017 at 15:55, Phil Brookes wrote: > Hello Everyone, > > The current development workflow for APB?s is to run a local oc cluster > with the ASB scanning the feedhenry docker org for APB images. Then pushing > our development images to the feedhenry repo to test them. > > As more developers start using these images we increase the possibility > that they will pull a broken development image which could lead to a pretty > significant waste of developer time trying to identify the problem and > could also reduce developers trust in the feedhenry APB images. > > To address this it is now only possible to update the APB images in the > feedhenry org via a merged PR to the master branch of that images github > repo. > > To develop your own changes to an APB you should instead point the ASB of > your local oc cluster at your own docker org and push a copy of any APBs > you wish to use into that org from the feedhenry org. When building > experimental APB images you should update the image in that APB?s apb.yml > file, and use make DOCKERORG= to build and push the development > APB image. > > I will be updating the ansible installer in the mcp-standalone repo to > automatically pull the APB images from feedhenry and push them into the > specified dockerorg in the near future, so we have less manual work to do. > > Any questions or concerns, please 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 crarobin at redhat.com Tue Oct 10 23:50:03 2017 From: crarobin at redhat.com (Craig Robinson) Date: Wed, 11 Oct 2017 09:50:03 +1000 Subject: [feedhenry-dev] Congratulating Summers on 5 great years at Red Hat In-Reply-To: References: Message-ID: Congratulations Summers. ? "if you didn't write it down, it didn't happen" - Clifford Stoll CRAIG ROBINSON SENIOR CLOUD OPERATIONS ENGINEER, RED HAT MOBILE Red Hat QLD 193 North Quay, BRISBANE, QLD, Australia crarobin at redhat.com M: +61-431-913-345 IM: crarobin TZ: UTC+10 On 11 October 2017 at 03:04, Evan Shortiss wrote: > Congrats Summers! > > On Tue, Oct 10, 2017 at 9:01 AM, Summers Pittman > wrote: > >> Thanks for all of the kudos guys, You are a blast to work with. >> >> Here's to five more. >> >> And for cake, here's a group project I was in for college in 2004 : >> https://github.com/secondsun/albumserver. Take a look at this >> and >> this >> if >> you want to see how students thought client/server protocols worked 13 >> years ago. >> >> >> >> On Tue, Oct 10, 2017 at 7:34 AM, Erik Jan de Wit >> wrote: >> >>> Congrats Summers! >>> >>> On Tue, Oct 10, 2017 at 12:42 PM, Jason Madigan >>> wrote: >>> >>>> Congrats Summers! >>>> >>>> On Mon, Oct 9, 2017 at 9:30 AM, Leigh Griffin >>>> wrote: >>>> >>>>> Hi everyone, >>>>> >>>>> Yesterday Summers marked his 5th anniversary in Red Hat. Summers has >>>>> led the charge on our Open Source efforts for such a long time now that >>>>> people default to him for advice and guidance on all things Open Source. He >>>>> has helped transition the entire Mobile team towards a more Open mentality >>>>> and his work in the SDK team, where he serves as an Android expert, and >>>>> recently in the Mobile.next work is helping to bring our next generation >>>>> offering to fruition. >>>>> >>>>> Summers, congratulations on this immense milestone and wishing you the >>>>> best for the next 5 years. If you could join me in congratulating Summers >>>>> on this great achievement, ideally off list. >>>>> >>>>> Thanks, >>>>> Leigh >>>>> >>>>> -- >>>>> >>>>> LEIGH GRIFFIN >>>>> >>>>> ENGINEERING MANAGER, MOBILE >>>>> >>>>> Red Hat Ireland >>>>> >>>>> Communications House, Cork Road >>>>> >>>>> Waterford City, Ireland X91NY33 >>>>> >>>>> lgriffin at redhat.com M: +353877545162 IM: lgriffin >>>>> >>>>> TRIED. TESTED. TRUSTED. >>>>> >>>>> @redhatway @redhatinc >>>>> @redhatsnaps >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Jason Madigan >>>> Engineering Manager, Red Hat Mobile >>>> >>>> _______________________________________________ >>>> feedhenry-dev mailing list >>>> feedhenry-dev at redhat.com >>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>> >>>> >>> >>> >>> -- >>> Cheers, >>> Erik Jan >>> >> >> > > > -- > > EVAN SHORTISS > > MOBILE PRACTICE ARCHITECT, RED HAT MOBILE > > Los Angeles, USA > > evan.shortiss at redhat.com M: +1-781-354-2834 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Wed Oct 11 07:35:15 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Wed, 11 Oct 2017 09:35:15 +0200 Subject: [feedhenry-dev] 3scale APB - up and running w/ Origin 3.6.0 ? Message-ID: Hola! Done this, on my fork's master branch: 1) oc cluster up --metrics --service-catalog=true 2) make DOCKERORG="matzew" 3) apb bootstrap Got error: Exception occurred! Could not find route to ansible-service-broker. Use --broker or log into the cluster using "oc login" Does the 3scale APB only work w/ the MCP extension, not "vanilla" Openshift Origin (3.6.0), where the service-catalog is enabled ? thanks! Matthias -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbrookes at redhat.com Wed Oct 11 08:27:14 2017 From: pbrookes at redhat.com (Phil Brookes) Date: Wed, 11 Oct 2017 09:27:14 +0100 Subject: [feedhenry-dev] Update to workflow for APB development In-Reply-To: References: Message-ID: Hey John, For pointing the oc cluster at your local docker, that is done from the installer directory of the mcp-standalone cluster: ansible-playbook playbook.yml -e "dockerhub_username=" -e "dockerhub_password=" -e "dockerhub_org=" --ask-become-pass To move the images you need into your own org, you could do something like: for image in aerogear-digger-apb android-app-apb cordova-app-apb ios-app-apb 3scale-apb keycloak-apb; do docker pull docker.io/feedhenry/$image:latest; docker tag docker.io/feedhenry/$image:latest ?/$image:latest; docker push /$image:latest; done ? There might be a way to improve this (if we could pull the name of all the *-apbs from the docker repo that would be ideal), but this will work for now.? Let me know if you have any thoughts. Phil. ? On Tue, Oct 10, 2017 at 9:01 PM, John Frizelle wrote: > Hi Phil, > > Thanks for the mail & agree with the suggestions. > > Are there any docs available that detail how to "point the ASB of your > local oc cluster at your own docker org and push a copy of any APBs you > wish to use into that org from the feedhenry org"? > > 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 10 October 2017 at 15:55, Phil Brookes wrote: > >> Hello Everyone, >> >> The current development workflow for APB?s is to run a local oc cluster >> with the ASB scanning the feedhenry docker org for APB images. Then pushing >> our development images to the feedhenry repo to test them. >> >> As more developers start using these images we increase the possibility >> that they will pull a broken development image which could lead to a pretty >> significant waste of developer time trying to identify the problem and >> could also reduce developers trust in the feedhenry APB images. >> >> To address this it is now only possible to update the APB images in the >> feedhenry org via a merged PR to the master branch of that images github >> repo. >> >> To develop your own changes to an APB you should instead point the ASB of >> your local oc cluster at your own docker org and push a copy of any APBs >> you wish to use into that org from the feedhenry org. When building >> experimental APB images you should update the image in that APB?s apb.yml >> file, and use make DOCKERORG= to build and push the development >> APB image. >> >> I will be updating the ansible installer in the mcp-standalone repo to >> automatically pull the APB images from feedhenry and push them into the >> specified dockerorg in the near future, so we have less manual work to do. >> >> Any questions or concerns, please 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 pbrookes at redhat.com Wed Oct 11 08:28:40 2017 From: pbrookes at redhat.com (Phil Brookes) Date: Wed, 11 Oct 2017 09:28:40 +0100 Subject: [feedhenry-dev] 3scale APB - up and running w/ Origin 3.6.0 ? In-Reply-To: References: Message-ID: Hey Matthias, This happens to me too, if you log in as the system:admin user and look at the routes in the ansible-service-broker project, you can then pass that route into the ?broker argument on the bootstrap command, this makes it work for me, though it can still be flaky. Regards, Phil. ? On Wed, Oct 11, 2017 at 8:35 AM, Matthias Wessendorf wrote: > Hola! > > Done this, on my fork's master branch: > 1) oc cluster up --metrics --service-catalog=true > 2) make DOCKERORG="matzew" > 3) apb bootstrap > > Got error: > Exception occurred! Could not find route to ansible-service-broker. Use > --broker or log into the cluster using "oc login" > > Does the 3scale APB only work w/ the MCP extension, not "vanilla" > Openshift Origin (3.6.0), where the service-catalog is enabled ? > > thanks! > Matthias > > -- > Project lead AeroGear.org > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bdooley at redhat.com Wed Oct 11 08:41:03 2017 From: bdooley at redhat.com (Brian Dooley) Date: Wed, 11 Oct 2017 09:41:03 +0100 Subject: [feedhenry-dev] Congratulating Summers on 5 great years at Red Hat In-Reply-To: References: Message-ID: Congrats Summers. On 11 October 2017 at 00:50, Craig Robinson wrote: > Congratulations Summers. ? > > > "if you didn't write it down, it didn't happen" - Clifford Stoll > > CRAIG ROBINSON > > SENIOR CLOUD OPERATIONS ENGINEER, RED HAT MOBILE > > Red Hat QLD > > 193 North Quay, BRISBANE, QLD, Australia > > > crarobin at redhat.com M: +61-431-913-345 > IM: crarobin TZ: UTC+10 > > > > On 11 October 2017 at 03:04, Evan Shortiss wrote: > >> Congrats Summers! >> >> On Tue, Oct 10, 2017 at 9:01 AM, Summers Pittman >> wrote: >> >>> Thanks for all of the kudos guys, You are a blast to work with. >>> >>> Here's to five more. >>> >>> And for cake, here's a group project I was in for college in 2004 : >>> https://github.com/secondsun/albumserver. Take a look at this >>> and >>> this >>> if >>> you want to see how students thought client/server protocols worked 13 >>> years ago. >>> >>> >>> >>> On Tue, Oct 10, 2017 at 7:34 AM, Erik Jan de Wit >>> wrote: >>> >>>> Congrats Summers! >>>> >>>> On Tue, Oct 10, 2017 at 12:42 PM, Jason Madigan >>>> wrote: >>>> >>>>> Congrats Summers! >>>>> >>>>> On Mon, Oct 9, 2017 at 9:30 AM, Leigh Griffin >>>>> wrote: >>>>> >>>>>> Hi everyone, >>>>>> >>>>>> Yesterday Summers marked his 5th anniversary in Red Hat. Summers has >>>>>> led the charge on our Open Source efforts for such a long time now that >>>>>> people default to him for advice and guidance on all things Open Source. He >>>>>> has helped transition the entire Mobile team towards a more Open mentality >>>>>> and his work in the SDK team, where he serves as an Android expert, and >>>>>> recently in the Mobile.next work is helping to bring our next generation >>>>>> offering to fruition. >>>>>> >>>>>> Summers, congratulations on this immense milestone and wishing you >>>>>> the best for the next 5 years. If you could join me in congratulating >>>>>> Summers on this great achievement, ideally off list. >>>>>> >>>>>> Thanks, >>>>>> Leigh >>>>>> >>>>>> -- >>>>>> >>>>>> LEIGH GRIFFIN >>>>>> >>>>>> ENGINEERING MANAGER, MOBILE >>>>>> >>>>>> Red Hat Ireland >>>>>> >>>>>> Communications House, Cork Road >>>>>> >>>>>> Waterford City, Ireland X91NY33 >>>>>> >>>>>> lgriffin at redhat.com M: +353877545162 IM: lgriffin >>>>>> >>>>>> TRIED. TESTED. TRUSTED. >>>>>> >>>>>> @redhatway @redhatinc >>>>>> @redhatsnaps >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Jason Madigan >>>>> Engineering Manager, Red Hat Mobile >>>>> >>>>> _______________________________________________ >>>>> feedhenry-dev mailing list >>>>> feedhenry-dev at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>>> >>>>> >>>> >>>> >>>> -- >>>> Cheers, >>>> Erik Jan >>>> >>> >>> >> >> >> -- >> >> EVAN SHORTISS >> >> MOBILE PRACTICE ARCHITECT, RED HAT MOBILE >> >> Los Angeles, USA >> >> evan.shortiss at redhat.com M: +1-781-354-2834 >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Wed Oct 11 08:55:38 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Wed, 11 Oct 2017 10:55:38 +0200 Subject: [feedhenry-dev] 3scale APB - up and running w/ Origin 3.6.0 ? In-Reply-To: References: Message-ID: thx - looking into it via MCP now On Wed, Oct 11, 2017 at 10:28 AM, Phil Brookes wrote: > Hey Matthias, > > This happens to me too, if you log in as the system:admin user and look at > the routes in the ansible-service-broker project, you can then pass that > route into the ?broker argument on the bootstrap command, this makes it > work for me, though it can still be flaky. > > Regards, > Phil. > ? > > On Wed, Oct 11, 2017 at 8:35 AM, Matthias Wessendorf > wrote: > >> Hola! >> >> Done this, on my fork's master branch: >> 1) oc cluster up --metrics --service-catalog=true >> 2) make DOCKERORG="matzew" >> 3) apb bootstrap >> >> Got error: >> Exception occurred! Could not find route to ansible-service-broker. Use >> --broker or log into the cluster using "oc login" >> >> Does the 3scale APB only work w/ the MCP extension, not "vanilla" >> Openshift Origin (3.6.0), where the service-catalog is enabled ? >> >> thanks! >> Matthias >> >> -- >> Project lead AeroGear.org >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfrizell at redhat.com Wed Oct 11 09:01:09 2017 From: jfrizell at redhat.com (John Frizelle) Date: Wed, 11 Oct 2017 10:01:09 +0100 Subject: [feedhenry-dev] Update to workflow for APB development In-Reply-To: References: Message-ID: Hi Phil, Thanks for the info. I was not really asking how to do it, but more so if we are maintaining docs anywhere that people can refer to for information such as this. It's a wider question than just this specific HOW TO, so anyone else working on 5.x feel free to chime in. 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 11 October 2017 at 09:27, Phil Brookes wrote: > Hey John, > > For pointing the oc cluster at your local docker, that is done from the > installer directory of the mcp-standalone cluster: > > ansible-playbook playbook.yml -e "dockerhub_username=" -e "dockerhub_password=" -e "dockerhub_org=" --ask-become-pass > > To move the images you need into your own org, you could do something like: > > for image in aerogear-digger-apb android-app-apb cordova-app-apb ios-app-apb 3scale-apb keycloak-apb; do docker pull docker.io/feedhenry/$image:latest; docker tag docker.io/feedhenry/$image:latest > ?/$image:latest; docker push /$image:latest; done > ? > > There might be a way to improve this (if we could pull the name of all the > *-apbs from the docker repo that would be ideal), but this will work for > now.? > > Let me know if you have any thoughts. > Phil. > ? > > On Tue, Oct 10, 2017 at 9:01 PM, John Frizelle > wrote: > >> Hi Phil, >> >> Thanks for the mail & agree with the suggestions. >> >> Are there any docs available that detail how to "point the ASB of your >> local oc cluster at your own docker org and push a copy of any APBs you >> wish to use into that org from the feedhenry org"? >> >> 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 10 October 2017 at 15:55, Phil Brookes wrote: >> >>> Hello Everyone, >>> >>> The current development workflow for APB?s is to run a local oc cluster >>> with the ASB scanning the feedhenry docker org for APB images. Then pushing >>> our development images to the feedhenry repo to test them. >>> >>> As more developers start using these images we increase the possibility >>> that they will pull a broken development image which could lead to a pretty >>> significant waste of developer time trying to identify the problem and >>> could also reduce developers trust in the feedhenry APB images. >>> >>> To address this it is now only possible to update the APB images in the >>> feedhenry org via a merged PR to the master branch of that images github >>> repo. >>> >>> To develop your own changes to an APB you should instead point the ASB >>> of your local oc cluster at your own docker org and push a copy of any APBs >>> you wish to use into that org from the feedhenry org. When building >>> experimental APB images you should update the image in that APB?s >>> apb.yml file, and use make DOCKERORG= to build and push the >>> development APB image. >>> >>> I will be updating the ansible installer in the mcp-standalone repo to >>> automatically pull the APB images from feedhenry and push them into the >>> specified dockerorg in the near future, so we have less manual work to do. >>> >>> Any questions or concerns, please 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 davmarti at redhat.com Wed Oct 11 11:37:17 2017 From: davmarti at redhat.com (David Martin) Date: Wed, 11 Oct 2017 12:37:17 +0100 Subject: [feedhenry-dev] Change of Scope for 3Scale/APICast Integration for 5.x Message-ID: Hi all, As per Jason's mail with subject 'MCP PoC - Sprint 5 Goals', the Goal of the 5.x team current sprint [0] is: "looking into 3scale apicast fronting Sync and KeyCloak" This Goal is actually 2 sub-goals. - Put 3Scale in front of Sync, using App ID/App Key authentication - Put 3Scale in front of Sync, using OpenID Connect authtentication via To give some context, the 3Scale integration will require/involve: - having a 3Scale SaaS account on 3scale.net (90 day trial accounts are available) - provisioning the 3Scale gateway (APICast) via the Service Catalog in OpenShift - MCP will autoconfigure your 3Scale SaaS a/c for sitting in front of Sync with App ID/Key authentication - APICast will make a call to 3Scale SaaS on startup to get it's confguration for doing authentication & proxying to Sync I propose that for this sprint we only focus on the first of these sub-goals. The OpenID Connect authentication integration can be deferred. Rationale for this proposal: - the OpenID Connect authentication option is currently not generally available in 3Scale SaaS (may be in the near future, based on activity on the apicast repo [1]) - the Keycloak service will need to be publicly accessible to 3Scale SaaS to allow it to configure the necessary client(s) in your Keycloak Thoughts & comments welcome Thanks [0] https://issues.jboss.org/secure/RapidBoard.jspa?rapidView=4143 [1] https://github.com/3scale/apicast -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Wed Oct 11 12:06:44 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Wed, 11 Oct 2017 14:06:44 +0200 Subject: [feedhenry-dev] MCP: make clean errors (on Feodra 26) Message-ID: Hi, when doing a 'make clean', I am getting also some errors that the script can not remove all stuff: + sudo rm -rf /home/Matthias/go/src/ github.com/feedhenry/mcp-standalone/ui/openshift-pvs + sudo rm -rf /home/Matthias/go/src/ github.com/feedhenry/mcp-standalone/ui/openshift-volumes rm: cannot remove '/home/Matthias/go/src/ github.com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/cf8bd6d3-ae61-11e7-ad7e-c85b765a6fb1/volumes/kubernetes.io~secret/service-catalog-controller-token-k44wx': Device or resource busy rm: cannot remove '/home/Matthias/go/src/ github.com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/cf8bd6d3-ae61-11e7-ad7e-c85b765a6fb1/volumes/kubernetes.io~secret/service-catalog-ssl': Device or resource busy rm: cannot remove '/home/Matthias/go/src/ github.com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/341b9a7a-ae62-11e7-9b83-c85b765a6fb1/volumes/kubernetes.io~secret/asb-token-l7wjh': Device or resource busy rm: cannot remove '/home/Matthias/go/src/ github.com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/341b9a7a-ae62-11e7-9b83-c85b765a6fb1/volumes/kubernetes.io~secret/asb-auth-volume': Device or resource busy rm: cannot remove '/home/Matthias/go/src/ github.com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/341b9a7a-ae62-11e7-9b83-c85b765a6fb1/volumes/kubernetes.io~secret/asb-tls': Device or resource busy rm: cannot remove '/home/Matthias/go/src/ github.com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/fcea5c92-ae61-11e7-ad7e-c85b765a6fb1/volumes/kubernetes.io~secret/server-certificate': Device or resource busy rm: cannot remove '/home/Matthias/go/src/ github.com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/fcea5c92-ae61-11e7-ad7e-c85b765a6fb1/volumes/kubernetes.io~secret/router-token-k7ph4': Device or resource busy rm: cannot remove '/home/Matthias/go/src/ github.com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/cf891608-ae61-11e7-ad7e-c85b765a6fb1/volumes/kubernetes.io~secret/service-catalog-apiserver-token-scxp5': Device or resource busy rm: cannot remove '/home/Matthias/go/src/ github.com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/cf891608-ae61-11e7-ad7e-c85b765a6fb1/volumes/kubernetes.io~secret/apiserver-ssl': Device or resource busy rm: cannot remove '/home/Matthias/go/src/ github.com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/0512a0f8-ae62-11e7-ad7e-c85b765a6fb1/volumes/kubernetes.io~secret/registry-token-zqmj2': Device or resource busy make: *** [Makefile:64: clean] Error 1 Rebooting my machine does fix this .. - anyone had the same ? -M -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From joreilly at redhat.com Wed Oct 11 12:12:16 2017 From: joreilly at redhat.com (Joe O'Reilly) Date: Wed, 11 Oct 2017 13:12:16 +0100 Subject: [feedhenry-dev] Change of Scope for 3Scale/APICast Integration for 5.x In-Reply-To: References: Message-ID: Thanks David, re. Jason's mail - Where was that sent (not sure myself or Nano received it)? As for the rest - looks fine, the only Q I have is where this leaves the integration of the BuildFarm effort? Thanks, Joe. On 11 October 2017 at 12:37, David Martin wrote: > Hi all, > > As per Jason's mail with subject 'MCP PoC - Sprint 5 Goals', > the Goal of the 5.x team current sprint [0] is: > > "looking into 3scale apicast fronting Sync and KeyCloak" > > This Goal is actually 2 sub-goals. > - Put 3Scale in front of Sync, using App ID/App Key authentication > - Put 3Scale in front of Sync, using OpenID Connect authtentication via > > To give some context, the 3Scale integration will require/involve: > - having a 3Scale SaaS account on 3scale.net (90 day trial accounts are > available) > - provisioning the 3Scale gateway (APICast) via the Service Catalog in > OpenShift > - MCP will autoconfigure your 3Scale SaaS a/c for sitting in front of Sync > with App ID/Key authentication > - APICast will make a call to 3Scale SaaS on startup to get it's > confguration for doing authentication & proxying to Sync > > > I propose that for this sprint we only focus on the first of these > sub-goals. > The OpenID Connect authentication integration can be deferred. > > > Rationale for this proposal: > - the OpenID Connect authentication option is currently not generally > available in 3Scale SaaS (may be in the near future, based on activity on > the apicast repo [1]) > - the Keycloak service will need to be publicly accessible to 3Scale SaaS > to allow it to configure the necessary client(s) in your Keycloak > > > Thoughts & comments welcome > Thanks > > > [0] https://issues.jboss.org/secure/RapidBoard.jspa?rapidView=4143 > [1] https://github.com/3scale/apicast > > > -- > David Martin > Red Hat Mobile > Twitter: @irldavem > IRC: @irldavem (feedhenry, mobile-internal) > -- Joe O'ReILLY GLOBAL PRODUCT MANAGER Red Hat Mobile Red Hat : Communications House, Cork Road, Waterford City, Ireland X91NY33 joreilly at redhat.com M: +353 878205731 TRIED. TESTED. TRUSTED. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cbrookes at redhat.com Wed Oct 11 12:18:42 2017 From: cbrookes at redhat.com (Craig Brookes) Date: Wed, 11 Oct 2017 13:18:42 +0100 Subject: [feedhenry-dev] Change of Scope for 3Scale/APICast Integration for 5.x In-Reply-To: References: Message-ID: @Joe build farm issues are at the top of the backlog for the remaining work. So if the integration for 3scale goes well they will be the first ones brought in to the sprint Craig On Wed, Oct 11, 2017 at 1:12 PM, Joe O'Reilly wrote: > Thanks David, > > re. Jason's mail - Where was that sent (not sure myself or Nano received > it)? > > As for the rest - looks fine, the only Q I have is where this leaves the > integration of the BuildFarm effort? > > Thanks, > > Joe. > > > On 11 October 2017 at 12:37, David Martin wrote: > >> Hi all, >> >> As per Jason's mail with subject 'MCP PoC - Sprint 5 Goals', >> the Goal of the 5.x team current sprint [0] is: >> >> "looking into 3scale apicast fronting Sync and KeyCloak" >> >> This Goal is actually 2 sub-goals. >> - Put 3Scale in front of Sync, using App ID/App Key authentication >> - Put 3Scale in front of Sync, using OpenID Connect authtentication via >> >> To give some context, the 3Scale integration will require/involve: >> - having a 3Scale SaaS account on 3scale.net (90 day trial accounts are >> available) >> - provisioning the 3Scale gateway (APICast) via the Service Catalog in >> OpenShift >> - MCP will autoconfigure your 3Scale SaaS a/c for sitting in front of >> Sync with App ID/Key authentication >> - APICast will make a call to 3Scale SaaS on startup to get it's >> confguration for doing authentication & proxying to Sync >> >> >> I propose that for this sprint we only focus on the first of these >> sub-goals. >> The OpenID Connect authentication integration can be deferred. >> >> >> Rationale for this proposal: >> - the OpenID Connect authentication option is currently not generally >> available in 3Scale SaaS (may be in the near future, based on activity on >> the apicast repo [1]) >> - the Keycloak service will need to be publicly accessible to 3Scale SaaS >> to allow it to configure the necessary client(s) in your Keycloak >> >> >> Thoughts & comments welcome >> Thanks >> >> >> [0] https://issues.jboss.org/secure/RapidBoard.jspa?rapidView=4143 >> [1] https://github.com/3scale/apicast >> >> >> -- >> David Martin >> Red Hat Mobile >> Twitter: @irldavem >> IRC: @irldavem (feedhenry, mobile-internal) >> > > > > -- > Joe O'ReILLY > > GLOBAL PRODUCT MANAGER > > Red Hat Mobile > > Red Hat : Communications House, > > Cork Road, Waterford City, Ireland X91NY33 > > joreilly at redhat.com M: +353 878205731 <+353%2087%20820%205731> > TRIED. TESTED. TRUSTED. > -- Craig Brookes RHMAP @maleck13 Github -------------- next part -------------- An HTML attachment was scrubbed... URL: From joreilly at redhat.com Wed Oct 11 12:22:12 2017 From: joreilly at redhat.com (Joe O'Reilly) Date: Wed, 11 Oct 2017 13:22:12 +0100 Subject: [feedhenry-dev] Change of Scope for 3Scale/APICast Integration for 5.x In-Reply-To: References: Message-ID: I'd thought we'd agreed that adding BF got us an end-to-end flow, making the overall POC really compelling (as is) & that the 3Scale would follow on afterwards? On 11 October 2017 at 13:18, Craig Brookes wrote: > @Joe build farm issues are at the top of the backlog for the remaining > work. So if the integration for 3scale goes well they will be the first > ones brought in to the sprint > > Craig > > On Wed, Oct 11, 2017 at 1:12 PM, Joe O'Reilly wrote: > >> Thanks David, >> >> re. Jason's mail - Where was that sent (not sure myself or Nano received >> it)? >> >> As for the rest - looks fine, the only Q I have is where this leaves the >> integration of the BuildFarm effort? >> >> Thanks, >> >> Joe. >> >> >> On 11 October 2017 at 12:37, David Martin wrote: >> >>> Hi all, >>> >>> As per Jason's mail with subject 'MCP PoC - Sprint 5 Goals', >>> the Goal of the 5.x team current sprint [0] is: >>> >>> "looking into 3scale apicast fronting Sync and KeyCloak" >>> >>> This Goal is actually 2 sub-goals. >>> - Put 3Scale in front of Sync, using App ID/App Key authentication >>> - Put 3Scale in front of Sync, using OpenID Connect authtentication via >>> >>> To give some context, the 3Scale integration will require/involve: >>> - having a 3Scale SaaS account on 3scale.net (90 day trial accounts are >>> available) >>> - provisioning the 3Scale gateway (APICast) via the Service Catalog in >>> OpenShift >>> - MCP will autoconfigure your 3Scale SaaS a/c for sitting in front of >>> Sync with App ID/Key authentication >>> - APICast will make a call to 3Scale SaaS on startup to get it's >>> confguration for doing authentication & proxying to Sync >>> >>> >>> I propose that for this sprint we only focus on the first of these >>> sub-goals. >>> The OpenID Connect authentication integration can be deferred. >>> >>> >>> Rationale for this proposal: >>> - the OpenID Connect authentication option is currently not generally >>> available in 3Scale SaaS (may be in the near future, based on activity on >>> the apicast repo [1]) >>> - the Keycloak service will need to be publicly accessible to 3Scale >>> SaaS to allow it to configure the necessary client(s) in your Keycloak >>> >>> >>> Thoughts & comments welcome >>> Thanks >>> >>> >>> [0] https://issues.jboss.org/secure/RapidBoard.jspa?rapidView=4143 >>> [1] https://github.com/3scale/apicast >>> >>> >>> -- >>> David Martin >>> Red Hat Mobile >>> Twitter: @irldavem >>> IRC: @irldavem (feedhenry, mobile-internal) >>> >> >> >> >> -- >> Joe O'ReILLY >> >> GLOBAL PRODUCT MANAGER >> >> Red Hat Mobile >> >> Red Hat : Communications House, >> >> Cork Road, Waterford City, Ireland X91NY33 >> >> joreilly at redhat.com M: +353 878205731 <+353%2087%20820%205731> >> TRIED. TESTED. TRUSTED. >> > > > > -- > Craig Brookes > RHMAP > @maleck13 Github > -- Joe O'ReILLY GLOBAL PRODUCT MANAGER Red Hat Mobile Red Hat : Communications House, Cork Road, Waterford City, Ireland X91NY33 joreilly at redhat.com M: +353 878205731 TRIED. TESTED. TRUSTED. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cbrookes at redhat.com Wed Oct 11 12:24:15 2017 From: cbrookes at redhat.com (Craig Brookes) Date: Wed, 11 Oct 2017 13:24:15 +0100 Subject: [feedhenry-dev] Change of Scope for 3Scale/APICast Integration for 5.x In-Reply-To: References: Message-ID: Correct. We left the BF with a working debug build. Video for that coming shortly. However there were other things we would have liked to do with the BF which are currently in the backlog. So reducing the scope of 3scale integration, means we may get a little more done on the BF (private repo build etc) Craig On Wed, Oct 11, 2017 at 1:22 PM, Joe O'Reilly wrote: > I'd thought we'd agreed that adding BF got us an end-to-end flow, making > the overall POC really compelling (as is) & that the 3Scale would follow on > afterwards? > > > > On 11 October 2017 at 13:18, Craig Brookes wrote: > >> @Joe build farm issues are at the top of the backlog for the remaining >> work. So if the integration for 3scale goes well they will be the first >> ones brought in to the sprint >> >> Craig >> >> On Wed, Oct 11, 2017 at 1:12 PM, Joe O'Reilly >> wrote: >> >>> Thanks David, >>> >>> re. Jason's mail - Where was that sent (not sure myself or Nano received >>> it)? >>> >>> As for the rest - looks fine, the only Q I have is where this leaves the >>> integration of the BuildFarm effort? >>> >>> Thanks, >>> >>> Joe. >>> >>> >>> On 11 October 2017 at 12:37, David Martin wrote: >>> >>>> Hi all, >>>> >>>> As per Jason's mail with subject 'MCP PoC - Sprint 5 Goals', >>>> the Goal of the 5.x team current sprint [0] is: >>>> >>>> "looking into 3scale apicast fronting Sync and KeyCloak" >>>> >>>> This Goal is actually 2 sub-goals. >>>> - Put 3Scale in front of Sync, using App ID/App Key authentication >>>> - Put 3Scale in front of Sync, using OpenID Connect authtentication via >>>> >>>> To give some context, the 3Scale integration will require/involve: >>>> - having a 3Scale SaaS account on 3scale.net (90 day trial accounts >>>> are available) >>>> - provisioning the 3Scale gateway (APICast) via the Service Catalog in >>>> OpenShift >>>> - MCP will autoconfigure your 3Scale SaaS a/c for sitting in front of >>>> Sync with App ID/Key authentication >>>> - APICast will make a call to 3Scale SaaS on startup to get it's >>>> confguration for doing authentication & proxying to Sync >>>> >>>> >>>> I propose that for this sprint we only focus on the first of these >>>> sub-goals. >>>> The OpenID Connect authentication integration can be deferred. >>>> >>>> >>>> Rationale for this proposal: >>>> - the OpenID Connect authentication option is currently not generally >>>> available in 3Scale SaaS (may be in the near future, based on activity on >>>> the apicast repo [1]) >>>> - the Keycloak service will need to be publicly accessible to 3Scale >>>> SaaS to allow it to configure the necessary client(s) in your Keycloak >>>> >>>> >>>> Thoughts & comments welcome >>>> Thanks >>>> >>>> >>>> [0] https://issues.jboss.org/secure/RapidBoard.jspa?rapidView=4143 >>>> [1] https://github.com/3scale/apicast >>>> >>>> >>>> -- >>>> David Martin >>>> Red Hat Mobile >>>> Twitter: @irldavem >>>> IRC: @irldavem (feedhenry, mobile-internal) >>>> >>> >>> >>> >>> -- >>> Joe O'ReILLY >>> >>> GLOBAL PRODUCT MANAGER >>> >>> Red Hat Mobile >>> >>> Red Hat : Communications House, >>> >>> Cork Road, Waterford City, Ireland X91NY33 >>> >>> joreilly at redhat.com M: +353 878205731 <+353%2087%20820%205731> >>> TRIED. TESTED. TRUSTED. >>> >>> >> >> >> >> -- >> Craig Brookes >> RHMAP >> @maleck13 Github >> > > > > -- > Joe O'ReILLY > > GLOBAL PRODUCT MANAGER > > Red Hat Mobile > > Red Hat : Communications House, > > Cork Road, Waterford City, Ireland X91NY33 > > joreilly at redhat.com M: +353 878205731 <+353%2087%20820%205731> > TRIED. TESTED. TRUSTED. > -- Craig Brookes RHMAP @maleck13 Github -------------- next part -------------- An HTML attachment was scrubbed... URL: From davmarti at redhat.com Wed Oct 11 12:31:29 2017 From: davmarti at redhat.com (David Martin) Date: Wed, 11 Oct 2017 13:31:29 +0100 Subject: [feedhenry-dev] Change of Scope for 3Scale/APICast Integration for 5.x In-Reply-To: References: Message-ID: Hey Joe, re: "re. Jason's mail - Where was that sent (not sure myself or Nano received it)? " There were a mail sent out by Jason in the last day summarising the Build Farm integration sprint (Sprint 4), and the 3Scale integration sprint plans (Sprint 5). Both were sent out to feedhenry-dev (like this mail). Maybe you have it filtered? (i cc'd you directly on this one, which may be why you saw it) Here is an archive of the mail anyways http://feedhenry-dev.2363497.n4.nabble.com/MCP-PoC-Sprint-5-Goals-and-a-brief-recap-on-Sprint-4-tt197.html On 11 October 2017 at 13:24, Craig Brookes wrote: > Correct. We left the BF with a working debug build. Video for that coming > shortly. However there were other things we would have liked to do with the > BF which are currently in the backlog. So reducing the scope of 3scale > integration, means we may get a little more done on the BF (private repo > build etc) > > Craig > > On Wed, Oct 11, 2017 at 1:22 PM, Joe O'Reilly wrote: > >> I'd thought we'd agreed that adding BF got us an end-to-end flow, making >> the overall POC really compelling (as is) & that the 3Scale would follow on >> afterwards? >> >> >> >> On 11 October 2017 at 13:18, Craig Brookes wrote: >> >>> @Joe build farm issues are at the top of the backlog for the remaining >>> work. So if the integration for 3scale goes well they will be the first >>> ones brought in to the sprint >>> >>> Craig >>> >>> On Wed, Oct 11, 2017 at 1:12 PM, Joe O'Reilly >>> wrote: >>> >>>> Thanks David, >>>> >>>> re. Jason's mail - Where was that sent (not sure myself or Nano >>>> received it)? >>>> >>>> As for the rest - looks fine, the only Q I have is where this leaves >>>> the integration of the BuildFarm effort? >>>> >>>> Thanks, >>>> >>>> Joe. >>>> >>>> >>>> On 11 October 2017 at 12:37, David Martin wrote: >>>> >>>>> Hi all, >>>>> >>>>> As per Jason's mail with subject 'MCP PoC - Sprint 5 Goals', >>>>> the Goal of the 5.x team current sprint [0] is: >>>>> >>>>> "looking into 3scale apicast fronting Sync and KeyCloak" >>>>> >>>>> This Goal is actually 2 sub-goals. >>>>> - Put 3Scale in front of Sync, using App ID/App Key authentication >>>>> - Put 3Scale in front of Sync, using OpenID Connect authtentication >>>>> via >>>>> >>>>> To give some context, the 3Scale integration will require/involve: >>>>> - having a 3Scale SaaS account on 3scale.net (90 day trial accounts >>>>> are available) >>>>> - provisioning the 3Scale gateway (APICast) via the Service Catalog in >>>>> OpenShift >>>>> - MCP will autoconfigure your 3Scale SaaS a/c for sitting in front of >>>>> Sync with App ID/Key authentication >>>>> - APICast will make a call to 3Scale SaaS on startup to get it's >>>>> confguration for doing authentication & proxying to Sync >>>>> >>>>> >>>>> I propose that for this sprint we only focus on the first of these >>>>> sub-goals. >>>>> The OpenID Connect authentication integration can be deferred. >>>>> >>>>> >>>>> Rationale for this proposal: >>>>> - the OpenID Connect authentication option is currently not generally >>>>> available in 3Scale SaaS (may be in the near future, based on activity on >>>>> the apicast repo [1]) >>>>> - the Keycloak service will need to be publicly accessible to 3Scale >>>>> SaaS to allow it to configure the necessary client(s) in your Keycloak >>>>> >>>>> >>>>> Thoughts & comments welcome >>>>> Thanks >>>>> >>>>> >>>>> [0] https://issues.jboss.org/secure/RapidBoard.jspa?rapidView=4143 >>>>> [1] https://github.com/3scale/apicast >>>>> >>>>> >>>>> -- >>>>> David Martin >>>>> Red Hat Mobile >>>>> Twitter: @irldavem >>>>> IRC: @irldavem (feedhenry, mobile-internal) >>>>> >>>> >>>> >>>> >>>> -- >>>> Joe O'ReILLY >>>> >>>> GLOBAL PRODUCT MANAGER >>>> >>>> Red Hat Mobile >>>> >>>> Red Hat : Communications House, >>>> >>>> Cork Road, Waterford City, Ireland X91NY33 >>>> >>>> joreilly at redhat.com M: +353 878205731 <+353%2087%20820%205731> >>>> TRIED. TESTED. TRUSTED. >>>> >>>> >>> >>> >>> >>> -- >>> Craig Brookes >>> RHMAP >>> @maleck13 Github >>> >> >> >> >> -- >> Joe O'ReILLY >> >> GLOBAL PRODUCT MANAGER >> >> Red Hat Mobile >> >> Red Hat : Communications House, >> >> Cork Road, Waterford City, Ireland X91NY33 >> >> joreilly at redhat.com M: +353 878205731 <+353%2087%20820%205731> >> TRIED. TESTED. TRUSTED. >> > > > > -- > Craig Brookes > RHMAP > @maleck13 Github > -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From davmarti at redhat.com Wed Oct 11 12:34:55 2017 From: davmarti at redhat.com (David Martin) Date: Wed, 11 Oct 2017 13:34:55 +0100 Subject: [feedhenry-dev] MCP: make clean errors (on Feodra 26) In-Reply-To: References: Message-ID: Hey Matthias, I have seen this. I haven't looked into it other than checking the folder permissions, but couldn't see anything obviously wrong. It hasn't caused any issues for me though. I would typically do a clean (with the above errors), then a re-run of the ansible installer, which brings up a fresh cluster OK. No need to restart. For more info on when this change was added to the clean script, see https://github.com/feedhenry/mcp-standalone/pull/88 On 11 October 2017 at 13:06, Matthias Wessendorf wrote: > Hi, > > when doing a 'make clean', I am getting also some errors that the script > can not remove all stuff: > > + sudo rm -rf /home/Matthias/go/src/github.com/feedhenry/mcp-standalone/ > ui/openshift-pvs > + sudo rm -rf /home/Matthias/go/src/github.com/feedhenry/mcp-standalone/ > ui/openshift-volumes > rm: cannot remove '/home/Matthias/go/src/github. > com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/ > cf8bd6d3-ae61-11e7-ad7e-c85b765a6fb1/volumes/kubernetes.io~secret/service- > catalog-controller-token-k44wx': Device or resource busy > rm: cannot remove '/home/Matthias/go/src/github. > com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/ > cf8bd6d3-ae61-11e7-ad7e-c85b765a6fb1/volumes/kubernetes.io~secret/service- > catalog-ssl': Device or resource busy > rm: cannot remove '/home/Matthias/go/src/github. > com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/ > 341b9a7a-ae62-11e7-9b83-c85b765a6fb1/volumes/kubernetes.io~secret/asb- > token-l7wjh': Device or resource busy > rm: cannot remove '/home/Matthias/go/src/github. > com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/ > 341b9a7a-ae62-11e7-9b83-c85b765a6fb1/volumes/ > kubernetes.io~secret/asb-auth-volume': Device or resource busy > rm: cannot remove '/home/Matthias/go/src/github. > com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/ > 341b9a7a-ae62-11e7-9b83-c85b765a6fb1/volumes/kubernetes.io~secret/asb-tls': > Device or resource busy > rm: cannot remove '/home/Matthias/go/src/github. > com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/ > fcea5c92-ae61-11e7-ad7e-c85b765a6fb1/volumes/kubernetes.io~secret/server- > certificate': Device or resource busy > rm: cannot remove '/home/Matthias/go/src/github. > com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/ > fcea5c92-ae61-11e7-ad7e-c85b765a6fb1/volumes/kubernetes.io~secret/router- > token-k7ph4': Device or resource busy > rm: cannot remove '/home/Matthias/go/src/github. > com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/ > cf891608-ae61-11e7-ad7e-c85b765a6fb1/volumes/kubernetes.io~secret/service- > catalog-apiserver-token-scxp5': Device or resource busy > rm: cannot remove '/home/Matthias/go/src/github. > com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/ > cf891608-ae61-11e7-ad7e-c85b765a6fb1/volumes/kubernetes.io~secret/ > apiserver-ssl': Device or resource busy > rm: cannot remove '/home/Matthias/go/src/github. > com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/ > 0512a0f8-ae62-11e7-ad7e-c85b765a6fb1/volumes/ > kubernetes.io~secret/registry-token-zqmj2': Device or resource busy > make: *** [Makefile:64: clean] Error 1 > > > > Rebooting my machine does fix this .. - anyone had the same ? > > > -M > > > > > -- > Project lead AeroGear.org > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From damurphy at redhat.com Wed Oct 11 12:36:27 2017 From: damurphy at redhat.com (Damien Murphy) Date: Wed, 11 Oct 2017 13:36:27 +0100 Subject: [feedhenry-dev] MCP: make clean errors (on Feodra 26) In-Reply-To: References: Message-ID: Hey Matthias, Had the same issue with OpenShift not unmounting the pods properly - you can unmount the pods manually by running `sudo umount` on each of the problematic pods. Once I did that I could run a `make clean` without issue, Damien On 11 October 2017 at 13:06, Matthias Wessendorf wrote: > Hi, > > when doing a 'make clean', I am getting also some errors that the script > can not remove all stuff: > > + sudo rm -rf /home/Matthias/go/src/github.com/feedhenry/mcp-standalone/ > ui/openshift-pvs > + sudo rm -rf /home/Matthias/go/src/github.com/feedhenry/mcp-standalone/ > ui/openshift-volumes > rm: cannot remove '/home/Matthias/go/src/github. > com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/ > cf8bd6d3-ae61-11e7-ad7e-c85b765a6fb1/volumes/kubernetes.io~secret/service- > catalog-controller-token-k44wx': Device or resource busy > rm: cannot remove '/home/Matthias/go/src/github. > com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/ > cf8bd6d3-ae61-11e7-ad7e-c85b765a6fb1/volumes/kubernetes.io~secret/service- > catalog-ssl': Device or resource busy > rm: cannot remove '/home/Matthias/go/src/github. > com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/ > 341b9a7a-ae62-11e7-9b83-c85b765a6fb1/volumes/kubernetes.io~secret/asb- > token-l7wjh': Device or resource busy > rm: cannot remove '/home/Matthias/go/src/github. > com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/ > 341b9a7a-ae62-11e7-9b83-c85b765a6fb1/volumes/ > kubernetes.io~secret/asb-auth-volume': Device or resource busy > rm: cannot remove '/home/Matthias/go/src/github. > com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/ > 341b9a7a-ae62-11e7-9b83-c85b765a6fb1/volumes/kubernetes.io~secret/asb-tls': > Device or resource busy > rm: cannot remove '/home/Matthias/go/src/github. > com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/ > fcea5c92-ae61-11e7-ad7e-c85b765a6fb1/volumes/kubernetes.io~secret/server- > certificate': Device or resource busy > rm: cannot remove '/home/Matthias/go/src/github. > com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/ > fcea5c92-ae61-11e7-ad7e-c85b765a6fb1/volumes/kubernetes.io~secret/router- > token-k7ph4': Device or resource busy > rm: cannot remove '/home/Matthias/go/src/github. > com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/ > cf891608-ae61-11e7-ad7e-c85b765a6fb1/volumes/kubernetes.io~secret/service- > catalog-apiserver-token-scxp5': Device or resource busy > rm: cannot remove '/home/Matthias/go/src/github. > com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/ > cf891608-ae61-11e7-ad7e-c85b765a6fb1/volumes/kubernetes.io~secret/ > apiserver-ssl': Device or resource busy > rm: cannot remove '/home/Matthias/go/src/github. > com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/ > 0512a0f8-ae62-11e7-ad7e-c85b765a6fb1/volumes/ > kubernetes.io~secret/registry-token-zqmj2': Device or resource busy > make: *** [Makefile:64: clean] Error 1 > > > > Rebooting my machine does fix this .. - anyone had the same ? > > > -M > > > > > -- > 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 joreilly at redhat.com Wed Oct 11 12:37:15 2017 From: joreilly at redhat.com (Joe O'Reilly) Date: Wed, 11 Oct 2017 13:37:15 +0100 Subject: [feedhenry-dev] Change of Scope for 3Scale/APICast Integration for 5.x In-Reply-To: References: Message-ID: Thanks Guys, I didn't get for the mail that "the working debug build" was still included - so this is fine (& covers what we'd discussed). & further updates to the BF can follow on after API... Thanks, Joe. On 11 October 2017 at 13:31, David Martin wrote: > Hey Joe, > > re: "re. Jason's mail - Where was that sent (not sure myself or Nano > received it)? " > > There were a mail sent out by Jason in the last day summarising the Build > Farm integration sprint (Sprint 4), and the 3Scale integration sprint plans > (Sprint 5). > Both were sent out to feedhenry-dev (like this mail). > Maybe you have it filtered? (i cc'd you directly on this one, which may be > why you saw it) > > Here is an archive of the mail anyways > http://feedhenry-dev.2363497.n4.nabble.com/MCP-PoC-Sprint- > 5-Goals-and-a-brief-recap-on-Sprint-4-tt197.html > > > On 11 October 2017 at 13:24, Craig Brookes wrote: > >> Correct. We left the BF with a working debug build. Video for that coming >> shortly. However there were other things we would have liked to do with the >> BF which are currently in the backlog. So reducing the scope of 3scale >> integration, means we may get a little more done on the BF (private repo >> build etc) >> >> Craig >> >> On Wed, Oct 11, 2017 at 1:22 PM, Joe O'Reilly >> wrote: >> >>> I'd thought we'd agreed that adding BF got us an end-to-end flow, making >>> the overall POC really compelling (as is) & that the 3Scale would follow on >>> afterwards? >>> >>> >>> >>> On 11 October 2017 at 13:18, Craig Brookes wrote: >>> >>>> @Joe build farm issues are at the top of the backlog for the remaining >>>> work. So if the integration for 3scale goes well they will be the first >>>> ones brought in to the sprint >>>> >>>> Craig >>>> >>>> On Wed, Oct 11, 2017 at 1:12 PM, Joe O'Reilly >>>> wrote: >>>> >>>>> Thanks David, >>>>> >>>>> re. Jason's mail - Where was that sent (not sure myself or Nano >>>>> received it)? >>>>> >>>>> As for the rest - looks fine, the only Q I have is where this leaves >>>>> the integration of the BuildFarm effort? >>>>> >>>>> Thanks, >>>>> >>>>> Joe. >>>>> >>>>> >>>>> On 11 October 2017 at 12:37, David Martin wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> As per Jason's mail with subject 'MCP PoC - Sprint 5 Goals', >>>>>> the Goal of the 5.x team current sprint [0] is: >>>>>> >>>>>> "looking into 3scale apicast fronting Sync and KeyCloak" >>>>>> >>>>>> This Goal is actually 2 sub-goals. >>>>>> - Put 3Scale in front of Sync, using App ID/App Key authentication >>>>>> - Put 3Scale in front of Sync, using OpenID Connect authtentication >>>>>> via >>>>>> >>>>>> To give some context, the 3Scale integration will require/involve: >>>>>> - having a 3Scale SaaS account on 3scale.net (90 day trial accounts >>>>>> are available) >>>>>> - provisioning the 3Scale gateway (APICast) via the Service Catalog >>>>>> in OpenShift >>>>>> - MCP will autoconfigure your 3Scale SaaS a/c for sitting in front of >>>>>> Sync with App ID/Key authentication >>>>>> - APICast will make a call to 3Scale SaaS on startup to get it's >>>>>> confguration for doing authentication & proxying to Sync >>>>>> >>>>>> >>>>>> I propose that for this sprint we only focus on the first of these >>>>>> sub-goals. >>>>>> The OpenID Connect authentication integration can be deferred. >>>>>> >>>>>> >>>>>> Rationale for this proposal: >>>>>> - the OpenID Connect authentication option is currently not generally >>>>>> available in 3Scale SaaS (may be in the near future, based on activity on >>>>>> the apicast repo [1]) >>>>>> - the Keycloak service will need to be publicly accessible to 3Scale >>>>>> SaaS to allow it to configure the necessary client(s) in your Keycloak >>>>>> >>>>>> >>>>>> Thoughts & comments welcome >>>>>> Thanks >>>>>> >>>>>> >>>>>> [0] https://issues.jboss.org/secure/RapidBoard.jspa?rapidView=4143 >>>>>> [1] https://github.com/3scale/apicast >>>>>> >>>>>> >>>>>> -- >>>>>> David Martin >>>>>> Red Hat Mobile >>>>>> Twitter: @irldavem >>>>>> IRC: @irldavem (feedhenry, mobile-internal) >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Joe O'ReILLY >>>>> >>>>> GLOBAL PRODUCT MANAGER >>>>> >>>>> Red Hat Mobile >>>>> >>>>> Red Hat : Communications House, >>>>> >>>>> Cork Road, Waterford City, Ireland X91NY33 >>>>> >>>>> joreilly at redhat.com M: +353 878205731 <+353%2087%20820%205731> >>>>> TRIED. TESTED. TRUSTED. >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Craig Brookes >>>> RHMAP >>>> @maleck13 Github >>>> >>> >>> >>> >>> -- >>> Joe O'ReILLY >>> >>> GLOBAL PRODUCT MANAGER >>> >>> Red Hat Mobile >>> >>> Red Hat : Communications House, >>> >>> Cork Road, Waterford City, Ireland X91NY33 >>> >>> joreilly at redhat.com M: +353 878205731 <+353%2087%20820%205731> >>> TRIED. TESTED. TRUSTED. >>> >>> >> >> >> >> -- >> Craig Brookes >> RHMAP >> @maleck13 Github >> > > > > -- > David Martin > Red Hat Mobile > Twitter: @irldavem > IRC: @irldavem (feedhenry, mobile-internal) > -- Joe O'ReILLY GLOBAL PRODUCT MANAGER Red Hat Mobile Red Hat : Communications House, Cork Road, Waterford City, Ireland X91NY33 joreilly at redhat.com M: +353 878205731 TRIED. TESTED. TRUSTED. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Wed Oct 11 12:39:01 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Wed, 11 Oct 2017 14:39:01 +0200 Subject: [feedhenry-dev] MCP: make clean errors (on Feodra 26) In-Reply-To: References: Message-ID: ah, that sounds good, thanks Damien! On Wed, Oct 11, 2017 at 2:36 PM, Damien Murphy wrote: > Hey Matthias, > > Had the same issue with OpenShift not unmounting the pods properly - you > can unmount the pods manually by running `sudo umount` on each of the > problematic pods. Once I did that I could run a `make clean` without issue, > > Damien > > On 11 October 2017 at 13:06, Matthias Wessendorf > wrote: > >> Hi, >> >> when doing a 'make clean', I am getting also some errors that the script >> can not remove all stuff: >> >> + sudo rm -rf /home/Matthias/go/src/github.c >> om/feedhenry/mcp-standalone/ui/openshift-pvs >> + sudo rm -rf /home/Matthias/go/src/github.c >> om/feedhenry/mcp-standalone/ui/openshift-volumes >> rm: cannot remove '/home/Matthias/go/src/github. >> com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/cf8bd >> 6d3-ae61-11e7-ad7e-c85b765a6fb1/volumes/kubernetes.io~ >> secret/service-catalog-controller-token-k44wx': Device or resource busy >> rm: cannot remove '/home/Matthias/go/src/github. >> com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/cf8bd >> 6d3-ae61-11e7-ad7e-c85b765a6fb1/volumes/kubernetes.io~ >> secret/service-catalog-ssl': Device or resource busy >> rm: cannot remove '/home/Matthias/go/src/github. >> com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/341b9 >> a7a-ae62-11e7-9b83-c85b765a6fb1/volumes/kubernetes.io~ >> secret/asb-token-l7wjh': Device or resource busy >> rm: cannot remove '/home/Matthias/go/src/github. >> com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/341b9 >> a7a-ae62-11e7-9b83-c85b765a6fb1/volumes/kubernetes.io~ >> secret/asb-auth-volume': Device or resource busy >> rm: cannot remove '/home/Matthias/go/src/github. >> com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/341b9 >> a7a-ae62-11e7-9b83-c85b765a6fb1/volumes/kubernetes.io~secret/asb-tls': >> Device or resource busy >> rm: cannot remove '/home/Matthias/go/src/github. >> com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/fcea5 >> c92-ae61-11e7-ad7e-c85b765a6fb1/volumes/kubernetes.io~ >> secret/server-certificate': Device or resource busy >> rm: cannot remove '/home/Matthias/go/src/github. >> com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/fcea5 >> c92-ae61-11e7-ad7e-c85b765a6fb1/volumes/kubernetes.io~ >> secret/router-token-k7ph4': Device or resource busy >> rm: cannot remove '/home/Matthias/go/src/github. >> com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/cf891 >> 608-ae61-11e7-ad7e-c85b765a6fb1/volumes/kubernetes.io~ >> secret/service-catalog-apiserver-token-scxp5': Device or resource busy >> rm: cannot remove '/home/Matthias/go/src/github. >> com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/cf891 >> 608-ae61-11e7-ad7e-c85b765a6fb1/volumes/kubernetes.io~ >> secret/apiserver-ssl': Device or resource busy >> rm: cannot remove '/home/Matthias/go/src/github. >> com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/0512a >> 0f8-ae62-11e7-ad7e-c85b765a6fb1/volumes/kubernetes.io~ >> secret/registry-token-zqmj2': Device or resource busy >> make: *** [Makefile:64: clean] Error 1 >> >> >> >> Rebooting my machine does fix this .. - anyone had the same ? >> >> >> -M >> >> >> >> >> -- >> Project lead AeroGear.org >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Wed Oct 11 12:39:00 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Wed, 11 Oct 2017 14:39:00 +0200 Subject: [feedhenry-dev] MCP: make clean errors (on Feodra 26) In-Reply-To: References: Message-ID: ah, that sounds good, thanks Damien! On Wed, Oct 11, 2017 at 2:36 PM, Damien Murphy wrote: > Hey Matthias, > > Had the same issue with OpenShift not unmounting the pods properly - you > can unmount the pods manually by running `sudo umount` on each of the > problematic pods. Once I did that I could run a `make clean` without issue, > > Damien > > On 11 October 2017 at 13:06, Matthias Wessendorf > wrote: > >> Hi, >> >> when doing a 'make clean', I am getting also some errors that the script >> can not remove all stuff: >> >> + sudo rm -rf /home/Matthias/go/src/github.c >> om/feedhenry/mcp-standalone/ui/openshift-pvs >> + sudo rm -rf /home/Matthias/go/src/github.c >> om/feedhenry/mcp-standalone/ui/openshift-volumes >> rm: cannot remove '/home/Matthias/go/src/github. >> com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/cf8bd >> 6d3-ae61-11e7-ad7e-c85b765a6fb1/volumes/kubernetes.io~ >> secret/service-catalog-controller-token-k44wx': Device or resource busy >> rm: cannot remove '/home/Matthias/go/src/github. >> com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/cf8bd >> 6d3-ae61-11e7-ad7e-c85b765a6fb1/volumes/kubernetes.io~ >> secret/service-catalog-ssl': Device or resource busy >> rm: cannot remove '/home/Matthias/go/src/github. >> com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/341b9 >> a7a-ae62-11e7-9b83-c85b765a6fb1/volumes/kubernetes.io~ >> secret/asb-token-l7wjh': Device or resource busy >> rm: cannot remove '/home/Matthias/go/src/github. >> com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/341b9 >> a7a-ae62-11e7-9b83-c85b765a6fb1/volumes/kubernetes.io~ >> secret/asb-auth-volume': Device or resource busy >> rm: cannot remove '/home/Matthias/go/src/github. >> com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/341b9 >> a7a-ae62-11e7-9b83-c85b765a6fb1/volumes/kubernetes.io~secret/asb-tls': >> Device or resource busy >> rm: cannot remove '/home/Matthias/go/src/github. >> com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/fcea5 >> c92-ae61-11e7-ad7e-c85b765a6fb1/volumes/kubernetes.io~ >> secret/server-certificate': Device or resource busy >> rm: cannot remove '/home/Matthias/go/src/github. >> com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/fcea5 >> c92-ae61-11e7-ad7e-c85b765a6fb1/volumes/kubernetes.io~ >> secret/router-token-k7ph4': Device or resource busy >> rm: cannot remove '/home/Matthias/go/src/github. >> com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/cf891 >> 608-ae61-11e7-ad7e-c85b765a6fb1/volumes/kubernetes.io~ >> secret/service-catalog-apiserver-token-scxp5': Device or resource busy >> rm: cannot remove '/home/Matthias/go/src/github. >> com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/cf891 >> 608-ae61-11e7-ad7e-c85b765a6fb1/volumes/kubernetes.io~ >> secret/apiserver-ssl': Device or resource busy >> rm: cannot remove '/home/Matthias/go/src/github. >> com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/0512a >> 0f8-ae62-11e7-ad7e-c85b765a6fb1/volumes/kubernetes.io~ >> secret/registry-token-zqmj2': Device or resource busy >> make: *** [Makefile:64: clean] Error 1 >> >> >> >> Rebooting my machine does fix this .. - anyone had the same ? >> >> >> -M >> >> >> >> >> -- >> Project lead AeroGear.org >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfrizell at redhat.com Wed Oct 11 12:38:44 2017 From: jfrizell at redhat.com (John Frizelle) Date: Wed, 11 Oct 2017 13:38:44 +0100 Subject: [feedhenry-dev] Change of Scope for 3Scale/APICast Integration for 5.x In-Reply-To: References: Message-ID: @Joe - as we are still in a POC phase, we are trying to explore and de-risk as mush as possible. The build Farm is a known quantity and we now have a steel thread. By comparison, 3Scale and where/how it fits is a pretty big unknown at the moment - hence the prioritisation to explore and de-risk this integration. -- 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 October 2017 at 13:31, David Martin wrote: > Hey Joe, > > re: "re. Jason's mail - Where was that sent (not sure myself or Nano > received it)? " > > There were a mail sent out by Jason in the last day summarising the Build > Farm integration sprint (Sprint 4), and the 3Scale integration sprint plans > (Sprint 5). > Both were sent out to feedhenry-dev (like this mail). > Maybe you have it filtered? (i cc'd you directly on this one, which may be > why you saw it) > > Here is an archive of the mail anyways > http://feedhenry-dev.2363497.n4.nabble.com/MCP-PoC-Sprint- > 5-Goals-and-a-brief-recap-on-Sprint-4-tt197.html > > > On 11 October 2017 at 13:24, Craig Brookes wrote: > >> Correct. We left the BF with a working debug build. Video for that coming >> shortly. However there were other things we would have liked to do with the >> BF which are currently in the backlog. So reducing the scope of 3scale >> integration, means we may get a little more done on the BF (private repo >> build etc) >> >> Craig >> >> On Wed, Oct 11, 2017 at 1:22 PM, Joe O'Reilly >> wrote: >> >>> I'd thought we'd agreed that adding BF got us an end-to-end flow, making >>> the overall POC really compelling (as is) & that the 3Scale would follow on >>> afterwards? >>> >>> >>> >>> On 11 October 2017 at 13:18, Craig Brookes wrote: >>> >>>> @Joe build farm issues are at the top of the backlog for the remaining >>>> work. So if the integration for 3scale goes well they will be the first >>>> ones brought in to the sprint >>>> >>>> Craig >>>> >>>> On Wed, Oct 11, 2017 at 1:12 PM, Joe O'Reilly >>>> wrote: >>>> >>>>> Thanks David, >>>>> >>>>> re. Jason's mail - Where was that sent (not sure myself or Nano >>>>> received it)? >>>>> >>>>> As for the rest - looks fine, the only Q I have is where this leaves >>>>> the integration of the BuildFarm effort? >>>>> >>>>> Thanks, >>>>> >>>>> Joe. >>>>> >>>>> >>>>> On 11 October 2017 at 12:37, David Martin wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> As per Jason's mail with subject 'MCP PoC - Sprint 5 Goals', >>>>>> the Goal of the 5.x team current sprint [0] is: >>>>>> >>>>>> "looking into 3scale apicast fronting Sync and KeyCloak" >>>>>> >>>>>> This Goal is actually 2 sub-goals. >>>>>> - Put 3Scale in front of Sync, using App ID/App Key authentication >>>>>> - Put 3Scale in front of Sync, using OpenID Connect authtentication >>>>>> via >>>>>> >>>>>> To give some context, the 3Scale integration will require/involve: >>>>>> - having a 3Scale SaaS account on 3scale.net (90 day trial accounts >>>>>> are available) >>>>>> - provisioning the 3Scale gateway (APICast) via the Service Catalog >>>>>> in OpenShift >>>>>> - MCP will autoconfigure your 3Scale SaaS a/c for sitting in front of >>>>>> Sync with App ID/Key authentication >>>>>> - APICast will make a call to 3Scale SaaS on startup to get it's >>>>>> confguration for doing authentication & proxying to Sync >>>>>> >>>>>> >>>>>> I propose that for this sprint we only focus on the first of these >>>>>> sub-goals. >>>>>> The OpenID Connect authentication integration can be deferred. >>>>>> >>>>>> >>>>>> Rationale for this proposal: >>>>>> - the OpenID Connect authentication option is currently not generally >>>>>> available in 3Scale SaaS (may be in the near future, based on activity on >>>>>> the apicast repo [1]) >>>>>> - the Keycloak service will need to be publicly accessible to 3Scale >>>>>> SaaS to allow it to configure the necessary client(s) in your Keycloak >>>>>> >>>>>> >>>>>> Thoughts & comments welcome >>>>>> Thanks >>>>>> >>>>>> >>>>>> [0] https://issues.jboss.org/secure/RapidBoard.jspa?rapidView=4143 >>>>>> [1] https://github.com/3scale/apicast >>>>>> >>>>>> >>>>>> -- >>>>>> David Martin >>>>>> Red Hat Mobile >>>>>> Twitter: @irldavem >>>>>> IRC: @irldavem (feedhenry, mobile-internal) >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Joe O'ReILLY >>>>> >>>>> GLOBAL PRODUCT MANAGER >>>>> >>>>> Red Hat Mobile >>>>> >>>>> Red Hat : Communications House, >>>>> >>>>> Cork Road, Waterford City, Ireland X91NY33 >>>>> >>>>> joreilly at redhat.com M: +353 878205731 <+353%2087%20820%205731> >>>>> TRIED. TESTED. TRUSTED. >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Craig Brookes >>>> RHMAP >>>> @maleck13 Github >>>> >>> >>> >>> >>> -- >>> Joe O'ReILLY >>> >>> GLOBAL PRODUCT MANAGER >>> >>> Red Hat Mobile >>> >>> Red Hat : Communications House, >>> >>> Cork Road, Waterford City, Ireland X91NY33 >>> >>> joreilly at redhat.com M: +353 878205731 <+353%2087%20820%205731> >>> TRIED. TESTED. TRUSTED. >>> >>> >> >> >> >> -- >> Craig Brookes >> RHMAP >> @maleck13 Github >> > > > > -- > David Martin > Red Hat Mobile > Twitter: @irldavem > IRC: @irldavem (feedhenry, mobile-internal) > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 11472 bytes Desc: not available URL: From joreilly at redhat.com Wed Oct 11 12:40:37 2017 From: joreilly at redhat.com (Joe O'Reilly) Date: Wed, 11 Oct 2017 13:40:37 +0100 Subject: [feedhenry-dev] Change of Scope for 3Scale/APICast Integration for 5.x In-Reply-To: References: Message-ID: Thanks John - agreed... as per my previous reply .. I hadn't picked up on the fact that we had the steel-thread completed. On 11 October 2017 at 13:38, John Frizelle wrote: > @Joe - as we are still in a POC phase, we are trying to explore and > de-risk as mush as possible. The build Farm is a known quantity and we now > have a steel thread. > > By comparison, 3Scale and where/how it fits is a pretty big unknown at the > moment - hence the prioritisation to explore and de-risk this integration. > > -- > 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 October 2017 at 13:31, David Martin wrote: > >> Hey Joe, >> >> re: "re. Jason's mail - Where was that sent (not sure myself or Nano >> received it)? " >> >> There were a mail sent out by Jason in the last day summarising the Build >> Farm integration sprint (Sprint 4), and the 3Scale integration sprint plans >> (Sprint 5). >> Both were sent out to feedhenry-dev (like this mail). >> Maybe you have it filtered? (i cc'd you directly on this one, which may >> be why you saw it) >> >> Here is an archive of the mail anyways >> http://feedhenry-dev.2363497.n4.nabble.com/MCP-PoC-Sprint-5- >> Goals-and-a-brief-recap-on-Sprint-4-tt197.html >> >> >> On 11 October 2017 at 13:24, Craig Brookes wrote: >> >>> Correct. We left the BF with a working debug build. Video for that >>> coming shortly. However there were other things we would have liked to do >>> with the BF which are currently in the backlog. So reducing the scope of >>> 3scale integration, means we may get a little more done on the BF (private >>> repo build etc) >>> >>> Craig >>> >>> On Wed, Oct 11, 2017 at 1:22 PM, Joe O'Reilly >>> wrote: >>> >>>> I'd thought we'd agreed that adding BF got us an end-to-end flow, >>>> making the overall POC really compelling (as is) & that the 3Scale would >>>> follow on afterwards? >>>> >>>> >>>> >>>> On 11 October 2017 at 13:18, Craig Brookes wrote: >>>> >>>>> @Joe build farm issues are at the top of the backlog for the remaining >>>>> work. So if the integration for 3scale goes well they will be the first >>>>> ones brought in to the sprint >>>>> >>>>> Craig >>>>> >>>>> On Wed, Oct 11, 2017 at 1:12 PM, Joe O'Reilly >>>>> wrote: >>>>> >>>>>> Thanks David, >>>>>> >>>>>> re. Jason's mail - Where was that sent (not sure myself or Nano >>>>>> received it)? >>>>>> >>>>>> As for the rest - looks fine, the only Q I have is where this leaves >>>>>> the integration of the BuildFarm effort? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Joe. >>>>>> >>>>>> >>>>>> On 11 October 2017 at 12:37, David Martin >>>>>> wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> As per Jason's mail with subject 'MCP PoC - Sprint 5 Goals', >>>>>>> the Goal of the 5.x team current sprint [0] is: >>>>>>> >>>>>>> "looking into 3scale apicast fronting Sync and KeyCloak" >>>>>>> >>>>>>> This Goal is actually 2 sub-goals. >>>>>>> - Put 3Scale in front of Sync, using App ID/App Key authentication >>>>>>> - Put 3Scale in front of Sync, using OpenID Connect authtentication >>>>>>> via >>>>>>> >>>>>>> To give some context, the 3Scale integration will require/involve: >>>>>>> - having a 3Scale SaaS account on 3scale.net (90 day trial accounts >>>>>>> are available) >>>>>>> - provisioning the 3Scale gateway (APICast) via the Service Catalog >>>>>>> in OpenShift >>>>>>> - MCP will autoconfigure your 3Scale SaaS a/c for sitting in front >>>>>>> of Sync with App ID/Key authentication >>>>>>> - APICast will make a call to 3Scale SaaS on startup to get it's >>>>>>> confguration for doing authentication & proxying to Sync >>>>>>> >>>>>>> >>>>>>> I propose that for this sprint we only focus on the first of these >>>>>>> sub-goals. >>>>>>> The OpenID Connect authentication integration can be deferred. >>>>>>> >>>>>>> >>>>>>> Rationale for this proposal: >>>>>>> - the OpenID Connect authentication option is currently not >>>>>>> generally available in 3Scale SaaS (may be in the near future, based on >>>>>>> activity on the apicast repo [1]) >>>>>>> - the Keycloak service will need to be publicly accessible to 3Scale >>>>>>> SaaS to allow it to configure the necessary client(s) in your Keycloak >>>>>>> >>>>>>> >>>>>>> Thoughts & comments welcome >>>>>>> Thanks >>>>>>> >>>>>>> >>>>>>> [0] https://issues.jboss.org/secure/RapidBoard.jspa?rapidView=4143 >>>>>>> [1] https://github.com/3scale/apicast >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> David Martin >>>>>>> Red Hat Mobile >>>>>>> Twitter: @irldavem >>>>>>> IRC: @irldavem (feedhenry, mobile-internal) >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Joe O'ReILLY >>>>>> >>>>>> GLOBAL PRODUCT MANAGER >>>>>> >>>>>> Red Hat Mobile >>>>>> >>>>>> Red Hat : Communications House, >>>>>> >>>>>> Cork Road, Waterford City, Ireland X91NY33 >>>>>> >>>>>> joreilly at redhat.com M: +353 878205731 <+353%2087%20820%205731> >>>>>> TRIED. TESTED. TRUSTED. >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Craig Brookes >>>>> RHMAP >>>>> @maleck13 Github >>>>> >>>> >>>> >>>> >>>> -- >>>> Joe O'ReILLY >>>> >>>> GLOBAL PRODUCT MANAGER >>>> >>>> Red Hat Mobile >>>> >>>> Red Hat : Communications House, >>>> >>>> Cork Road, Waterford City, Ireland X91NY33 >>>> >>>> joreilly at redhat.com M: +353 878205731 <+353%2087%20820%205731> >>>> TRIED. TESTED. TRUSTED. >>>> >>>> >>> >>> >>> >>> -- >>> Craig Brookes >>> RHMAP >>> @maleck13 Github >>> >> >> >> >> -- >> David Martin >> Red Hat Mobile >> Twitter: @irldavem >> IRC: @irldavem (feedhenry, mobile-internal) >> > > -- Joe O'ReILLY GLOBAL PRODUCT MANAGER Red Hat Mobile Red Hat : Communications House, Cork Road, Waterford City, Ireland X91NY33 joreilly at redhat.com M: +353 878205731 TRIED. TESTED. TRUSTED. -------------- 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 jmadigan at redhat.com Wed Oct 11 12:51:02 2017 From: jmadigan at redhat.com (Jason Madigan) Date: Wed, 11 Oct 2017 13:51:02 +0100 Subject: [feedhenry-dev] Change of Scope for 3Scale/APICast Integration for 5.x In-Reply-To: References: Message-ID: It was sent to feedhenry-dev - subscribe here: https://www.redhat.com/mailman/listinfo/feedhenry-dev On Wed, Oct 11, 2017 at 1:12 PM, Joe O'Reilly wrote: > Thanks David, > > re. Jason's mail - Where was that sent (not sure myself or Nano received > it)? > > As for the rest - looks fine, the only Q I have is where this leaves the > integration of the BuildFarm effort? > > Thanks, > > Joe. > > > On 11 October 2017 at 12:37, David Martin wrote: > >> Hi all, >> >> As per Jason's mail with subject 'MCP PoC - Sprint 5 Goals', >> the Goal of the 5.x team current sprint [0] is: >> >> "looking into 3scale apicast fronting Sync and KeyCloak" >> >> This Goal is actually 2 sub-goals. >> - Put 3Scale in front of Sync, using App ID/App Key authentication >> - Put 3Scale in front of Sync, using OpenID Connect authtentication via >> >> To give some context, the 3Scale integration will require/involve: >> - having a 3Scale SaaS account on 3scale.net (90 day trial accounts are >> available) >> - provisioning the 3Scale gateway (APICast) via the Service Catalog in >> OpenShift >> - MCP will autoconfigure your 3Scale SaaS a/c for sitting in front of >> Sync with App ID/Key authentication >> - APICast will make a call to 3Scale SaaS on startup to get it's >> confguration for doing authentication & proxying to Sync >> >> >> I propose that for this sprint we only focus on the first of these >> sub-goals. >> The OpenID Connect authentication integration can be deferred. >> >> >> Rationale for this proposal: >> - the OpenID Connect authentication option is currently not generally >> available in 3Scale SaaS (may be in the near future, based on activity on >> the apicast repo [1]) >> - the Keycloak service will need to be publicly accessible to 3Scale SaaS >> to allow it to configure the necessary client(s) in your Keycloak >> >> >> Thoughts & comments welcome >> Thanks >> >> >> [0] https://issues.jboss.org/secure/RapidBoard.jspa?rapidView=4143 >> [1] https://github.com/3scale/apicast >> >> >> -- >> David Martin >> Red Hat Mobile >> Twitter: @irldavem >> IRC: @irldavem (feedhenry, mobile-internal) >> > > > > -- > Joe O'ReILLY > > GLOBAL PRODUCT MANAGER > > Red Hat Mobile > > Red Hat : Communications House, > > Cork Road, Waterford City, Ireland X91NY33 > > joreilly at redhat.com M: +353 878205731 <+353%2087%20820%205731> > TRIED. TESTED. TRUSTED. > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- Jason Madigan Engineering Manager, Red Hat Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: From damurphy at redhat.com Wed Oct 11 12:51:25 2017 From: damurphy at redhat.com (Damien Murphy) Date: Wed, 11 Oct 2017 13:51:25 +0100 Subject: [feedhenry-dev] MCP: make clean errors (on Feodra 26) In-Reply-To: References: Message-ID: No worries Matthias, it seems it may be a known issue where pods/ volumes don't always unmount properly. Gist with a filthy one-liner I used - https://gist.github.com/damienomurchu/0510507067ed0ba1b6a5412e1e54a274 :-) On 11 October 2017 at 13:39, Matthias Wessendorf wrote: > ah, that sounds good, thanks Damien! > > On Wed, Oct 11, 2017 at 2:36 PM, Damien Murphy > wrote: > >> Hey Matthias, >> >> Had the same issue with OpenShift not unmounting the pods properly - you >> can unmount the pods manually by running `sudo umount` on each of the >> problematic pods. Once I did that I could run a `make clean` without issue, >> >> Damien >> >> On 11 October 2017 at 13:06, Matthias Wessendorf >> wrote: >> >>> Hi, >>> >>> when doing a 'make clean', I am getting also some errors that the script >>> can not remove all stuff: >>> >>> + sudo rm -rf /home/Matthias/go/src/github.c >>> om/feedhenry/mcp-standalone/ui/openshift-pvs >>> + sudo rm -rf /home/Matthias/go/src/github.c >>> om/feedhenry/mcp-standalone/ui/openshift-volumes >>> rm: cannot remove '/home/Matthias/go/src/github. >>> com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/cf8bd >>> 6d3-ae61-11e7-ad7e-c85b765a6fb1/volumes/kubernetes.io~secret >>> /service-catalog-controller-token-k44wx': Device or resource busy >>> rm: cannot remove '/home/Matthias/go/src/github. >>> com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/cf8bd >>> 6d3-ae61-11e7-ad7e-c85b765a6fb1/volumes/kubernetes.io~secret >>> /service-catalog-ssl': Device or resource busy >>> rm: cannot remove '/home/Matthias/go/src/github. >>> com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/341b9 >>> a7a-ae62-11e7-9b83-c85b765a6fb1/volumes/kubernetes.io~secret >>> /asb-token-l7wjh': Device or resource busy >>> rm: cannot remove '/home/Matthias/go/src/github. >>> com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/341b9 >>> a7a-ae62-11e7-9b83-c85b765a6fb1/volumes/kubernetes.io~secret >>> /asb-auth-volume': Device or resource busy >>> rm: cannot remove '/home/Matthias/go/src/github. >>> com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/341b9 >>> a7a-ae62-11e7-9b83-c85b765a6fb1/volumes/kubernetes.io~secret/asb-tls': >>> Device or resource busy >>> rm: cannot remove '/home/Matthias/go/src/github. >>> com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/fcea5 >>> c92-ae61-11e7-ad7e-c85b765a6fb1/volumes/kubernetes.io~secret >>> /server-certificate': Device or resource busy >>> rm: cannot remove '/home/Matthias/go/src/github. >>> com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/fcea5 >>> c92-ae61-11e7-ad7e-c85b765a6fb1/volumes/kubernetes.io~secret >>> /router-token-k7ph4': Device or resource busy >>> rm: cannot remove '/home/Matthias/go/src/github. >>> com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/cf891 >>> 608-ae61-11e7-ad7e-c85b765a6fb1/volumes/kubernetes.io~secret >>> /service-catalog-apiserver-token-scxp5': Device or resource busy >>> rm: cannot remove '/home/Matthias/go/src/github. >>> com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/cf891 >>> 608-ae61-11e7-ad7e-c85b765a6fb1/volumes/kubernetes.io~secret >>> /apiserver-ssl': Device or resource busy >>> rm: cannot remove '/home/Matthias/go/src/github. >>> com/feedhenry/mcp-standalone/ui/openshift-volumes/pods/0512a >>> 0f8-ae62-11e7-ad7e-c85b765a6fb1/volumes/kubernetes.io~secret >>> /registry-token-zqmj2': Device or resource busy >>> make: *** [Makefile:64: clean] Error 1 >>> >>> >>> >>> Rebooting my machine does fix this .. - anyone had the same ? >>> >>> >>> -M >>> >>> >>> >>> >>> -- >>> Project lead AeroGear.org >>> >>> _______________________________________________ >>> feedhenry-dev mailing list >>> feedhenry-dev at redhat.com >>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>> >>> >> >> > > > -- > Project lead AeroGear.org > -- DAMIEN MURPHY SOFTWARE ENGINEER Red Hat Mobile IM: damurphy -------------- next part -------------- An HTML attachment was scrubbed... URL: From davmarti at redhat.com Wed Oct 11 15:30:03 2017 From: davmarti at redhat.com (David Martin) Date: Wed, 11 Oct 2017 16:30:03 +0100 Subject: [feedhenry-dev] Update to workflow for APB development In-Reply-To: References: Message-ID: Hey Phile, I'd say a section in the local development section of the README is a reasonable place to put this info https://github.com/feedhenry/mcp-standalone#local-development e.g. 'Developing APBs locally' On 11 October 2017 at 10:01, John Frizelle wrote: > Hi Phil, > > Thanks for the info. > > I was not really asking how to do it, but more so if we are maintaining > docs anywhere that people can refer to for information such as this. > > It's a wider question than just this specific HOW TO, so anyone else > working on 5.x feel free to chime in. > > 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 11 October 2017 at 09:27, Phil Brookes wrote: > >> Hey John, >> >> For pointing the oc cluster at your local docker, that is done from the >> installer directory of the mcp-standalone cluster: >> >> ansible-playbook playbook.yml -e "dockerhub_username=" -e "dockerhub_password=" -e "dockerhub_org=" --ask-become-pass >> >> To move the images you need into your own org, you could do something >> like: >> >> for image in aerogear-digger-apb android-app-apb cordova-app-apb ios-app-apb 3scale-apb keycloak-apb; do docker pull docker.io/feedhenry/$image:latest; docker tag docker.io/feedhenry/$image:latest >> ?/$image:latest; docker push /$image:latest; done >> ? >> >> There might be a way to improve this (if we could pull the name of all >> the *-apbs from the docker repo that would be ideal), but this will work >> for now.? >> >> Let me know if you have any thoughts. >> Phil. >> ? >> >> On Tue, Oct 10, 2017 at 9:01 PM, John Frizelle >> wrote: >> >>> Hi Phil, >>> >>> Thanks for the mail & agree with the suggestions. >>> >>> Are there any docs available that detail how to "point the ASB of your >>> local oc cluster at your own docker org and push a copy of any APBs you >>> wish to use into that org from the feedhenry org"? >>> >>> 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 10 October 2017 at 15:55, Phil Brookes wrote: >>> >>>> Hello Everyone, >>>> >>>> The current development workflow for APB?s is to run a local oc cluster >>>> with the ASB scanning the feedhenry docker org for APB images. Then pushing >>>> our development images to the feedhenry repo to test them. >>>> >>>> As more developers start using these images we increase the possibility >>>> that they will pull a broken development image which could lead to a pretty >>>> significant waste of developer time trying to identify the problem and >>>> could also reduce developers trust in the feedhenry APB images. >>>> >>>> To address this it is now only possible to update the APB images in the >>>> feedhenry org via a merged PR to the master branch of that images github >>>> repo. >>>> >>>> To develop your own changes to an APB you should instead point the ASB >>>> of your local oc cluster at your own docker org and push a copy of any APBs >>>> you wish to use into that org from the feedhenry org. When building >>>> experimental APB images you should update the image in that APB?s >>>> apb.yml file, and use make DOCKERORG= to build and push the >>>> development APB image. >>>> >>>> I will be updating the ansible installer in the mcp-standalone repo to >>>> automatically pull the APB images from feedhenry and push them into the >>>> specified dockerorg in the near future, so we have less manual work to do. >>>> >>>> Any questions or concerns, please let me know. >>>> >>>> Thanks, >>>> Phil. >>>> ? >>>> >>>> _______________________________________________ >>>> feedhenry-dev mailing list >>>> feedhenry-dev at redhat.com >>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>> >>>> >>> >> > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 11472 bytes Desc: not available URL: From davmarti at redhat.com Thu Oct 12 08:22:15 2017 From: davmarti at redhat.com (David Martin) Date: Thu, 12 Oct 2017 09:22:15 +0100 Subject: [feedhenry-dev] Change of Scope for 3Scale/APICast Integration for 5.x In-Reply-To: References: Message-ID: I've updated the current sprint to : - close out the OIDC investigation issue https://issues.jboss.org/browse/FH-4224 - move the follow up issue https://issues.jboss.org/browse/FH-4235 to the backlog, as the OIDC integration is being defferred The UI related issue for the 3Scale integration was updated to reflect this decision https://issues.jboss.org/browse/FH-4237. App ID/App Key authentication will be the focus of the PoC. On 11 October 2017 at 13:51, Jason Madigan wrote: > It was sent to feedhenry-dev - subscribe here: https://www.redhat.com/ > mailman/listinfo/feedhenry-dev > > On Wed, Oct 11, 2017 at 1:12 PM, Joe O'Reilly wrote: > >> Thanks David, >> >> re. Jason's mail - Where was that sent (not sure myself or Nano received >> it)? >> >> As for the rest - looks fine, the only Q I have is where this leaves the >> integration of the BuildFarm effort? >> >> Thanks, >> >> Joe. >> >> >> On 11 October 2017 at 12:37, David Martin wrote: >> >>> Hi all, >>> >>> As per Jason's mail with subject 'MCP PoC - Sprint 5 Goals', >>> the Goal of the 5.x team current sprint [0] is: >>> >>> "looking into 3scale apicast fronting Sync and KeyCloak" >>> >>> This Goal is actually 2 sub-goals. >>> - Put 3Scale in front of Sync, using App ID/App Key authentication >>> - Put 3Scale in front of Sync, using OpenID Connect authtentication via >>> >>> To give some context, the 3Scale integration will require/involve: >>> - having a 3Scale SaaS account on 3scale.net (90 day trial accounts are >>> available) >>> - provisioning the 3Scale gateway (APICast) via the Service Catalog in >>> OpenShift >>> - MCP will autoconfigure your 3Scale SaaS a/c for sitting in front of >>> Sync with App ID/Key authentication >>> - APICast will make a call to 3Scale SaaS on startup to get it's >>> confguration for doing authentication & proxying to Sync >>> >>> >>> I propose that for this sprint we only focus on the first of these >>> sub-goals. >>> The OpenID Connect authentication integration can be deferred. >>> >>> >>> Rationale for this proposal: >>> - the OpenID Connect authentication option is currently not generally >>> available in 3Scale SaaS (may be in the near future, based on activity on >>> the apicast repo [1]) >>> - the Keycloak service will need to be publicly accessible to 3Scale >>> SaaS to allow it to configure the necessary client(s) in your Keycloak >>> >>> >>> Thoughts & comments welcome >>> Thanks >>> >>> >>> [0] https://issues.jboss.org/secure/RapidBoard.jspa?rapidView=4143 >>> [1] https://github.com/3scale/apicast >>> >>> >>> -- >>> David Martin >>> Red Hat Mobile >>> Twitter: @irldavem >>> IRC: @irldavem (feedhenry, mobile-internal) >>> >> >> >> >> -- >> Joe O'ReILLY >> >> GLOBAL PRODUCT MANAGER >> >> Red Hat Mobile >> >> Red Hat : Communications House, >> >> Cork Road, Waterford City, Ireland X91NY33 >> >> joreilly at redhat.com M: +353 878205731 <+353%2087%20820%205731> >> TRIED. TESTED. TRUSTED. >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > > -- > Jason Madigan > Engineering Manager, Red Hat Mobile > -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From akeating at redhat.com Thu Oct 12 08:42:47 2017 From: akeating at redhat.com (Aiden Keating) Date: Thu, 12 Oct 2017 09:42:47 +0100 Subject: [feedhenry-dev] MCP Demo - Mobile CI/CD Service Message-ID: Hey everyone, We've recorded a demo about the work we've been doing recently on the Mobile CI/CD service (Build farm integration) and using it with the Mobile Control Panel. The demo is quite short and includes setting up the Mobile CI/CD service, building an app and installing it in an emulator. https://youtu.be/89qSN8HXOmk For the PoC the Mobile CI/CD service can only produce debug Android builds from public repositories. In the future we will provide support for private repositories, release builds, including custom environment variables in builds and iOS builds. Thanks, Aiden -------------- next part -------------- An HTML attachment was scrubbed... URL: From bdooley at redhat.com Thu Oct 12 08:50:35 2017 From: bdooley at redhat.com (Brian Dooley) Date: Thu, 12 Oct 2017 09:50:35 +0100 Subject: [feedhenry-dev] MCP Demo - Mobile CI/CD Service In-Reply-To: References: Message-ID: Looks good, Aiden. On 12 October 2017 at 09:42, Aiden Keating wrote: > Hey everyone, > > We've recorded a demo about the work we've been doing recently on the > Mobile CI/CD service (Build farm integration) and using it with the Mobile > Control Panel. > > The demo is quite short and includes setting up the Mobile CI/CD service, > building an app and installing it in an emulator. > > https://youtu.be/89qSN8HXOmk > > For the PoC the Mobile CI/CD service can only produce debug Android builds > from public repositories. In the future we will provide support for private > repositories, release builds, including custom environment variables in > builds and iOS builds. > > Thanks, > Aiden > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfreer at redhat.com Thu Oct 12 08:52:01 2017 From: mfreer at redhat.com (Mark Freer) Date: Thu, 12 Oct 2017 09:52:01 +0100 Subject: [feedhenry-dev] MCP Demo - Mobile CI/CD Service In-Reply-To: References: Message-ID: Nice video Aiden, Great job On Thu, Oct 12, 2017 at 9:50 AM, Brian Dooley wrote: > Looks good, Aiden. > > > On 12 October 2017 at 09:42, Aiden Keating wrote: > >> Hey everyone, >> >> We've recorded a demo about the work we've been doing recently on the >> Mobile CI/CD service (Build farm integration) and using it with the Mobile >> Control Panel. >> >> The demo is quite short and includes setting up the Mobile CI/CD service, >> building an app and installing it in an emulator. >> >> https://youtu.be/89qSN8HXOmk >> >> For the PoC the Mobile CI/CD service can only produce debug Android >> builds from public repositories. In the future we will provide support for >> private repositories, release builds, including custom environment >> variables in builds and iOS builds. >> >> Thanks, >> Aiden >> > > -- Mark Freer Senior Operations Engineer *Red Hat Mobile * Email: mfreer at redhat.com IRC: @mfreer (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From omatskiv at redhat.com Thu Oct 12 08:52:20 2017 From: omatskiv at redhat.com (Oleh Mackiv) Date: Thu, 12 Oct 2017 10:52:20 +0200 Subject: [feedhenry-dev] MCP Demo - Mobile CI/CD Service In-Reply-To: References: Message-ID: Great demo ! ? On Thu, Oct 12, 2017 at 10:42 AM, Aiden Keating wrote: > Hey everyone, > > We've recorded a demo about the work we've been doing recently on the > Mobile CI/CD service (Build farm integration) and using it with the Mobile > Control Panel. > > The demo is quite short and includes setting up the Mobile CI/CD service, > building an app and installing it in an emulator. > > https://youtu.be/89qSN8HXOmk > > For the PoC the Mobile CI/CD service can only produce debug Android builds > from public repositories. In the future we will provide support for private > repositories, release builds, including custom environment variables in > builds and iOS builds. > > Thanks, > Aiden > -- Oleg Matskiv Associate Quality Engineer Red Hat Mobile Application Platform omatskiv at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dffrench at redhat.com Thu Oct 12 09:08:34 2017 From: dffrench at redhat.com (David Ffrench) Date: Thu, 12 Oct 2017 10:08:34 +0100 Subject: [feedhenry-dev] MCP Demo - Mobile CI/CD Service In-Reply-To: References: Message-ID: Another fantastic demo Aiden, great work from the 5.x team! DAVID FFRENCH senior software engineer, RED HAT MOBILE Red Hat Waterford Communications House, Cork Road Waterford, Ireland dffrench at redhat.com On Thu, Oct 12, 2017 at 9:52 AM, Oleh Mackiv wrote: > Great demo ! ? > > On Thu, Oct 12, 2017 at 10:42 AM, Aiden Keating > wrote: > >> Hey everyone, >> >> We've recorded a demo about the work we've been doing recently on the >> Mobile CI/CD service (Build farm integration) and using it with the Mobile >> Control Panel. >> >> The demo is quite short and includes setting up the Mobile CI/CD service, >> building an app and installing it in an emulator. >> >> https://youtu.be/89qSN8HXOmk >> >> For the PoC the Mobile CI/CD service can only produce debug Android >> builds from public repositories. In the future we will provide support for >> private repositories, release builds, including custom environment >> variables in builds and iOS builds. >> >> Thanks, >> Aiden >> > > > > -- > Oleg Matskiv > Associate Quality Engineer > Red Hat Mobile Application Platform > omatskiv at redhat.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbraun at redhat.com Thu Oct 12 09:17:15 2017 From: pbraun at redhat.com (Peter Braun) Date: Thu, 12 Oct 2017 11:17:15 +0200 Subject: [feedhenry-dev] MCP Demo - Mobile CI/CD Service In-Reply-To: References: Message-ID: Great Demo Aiden, thanks for sharing! > Am 12.10.2017 um 10:42 schrieb Aiden Keating : > > Hey everyone, > > We've recorded a demo about the work we've been doing recently on the Mobile CI/CD service (Build farm integration) and using it with the Mobile Control Panel. > > The demo is quite short and includes setting up the Mobile CI/CD service, building an app and installing it in an emulator. > > https://youtu.be/89qSN8HXOmk > > For the PoC the Mobile CI/CD service can only produce debug Android builds from public repositories. In the future we will provide support for private repositories, release builds, including custom environment variables in builds and iOS builds. > > Thanks, > Aiden -------------- next part -------------- An HTML attachment was scrubbed... URL: From damurphy at redhat.com Thu Oct 12 09:31:20 2017 From: damurphy at redhat.com (Damien Murphy) Date: Thu, 12 Oct 2017 10:31:20 +0100 Subject: [feedhenry-dev] MCP Demo - Mobile CI/CD Service In-Reply-To: References: Message-ID: Really nice demo, thanks for sharing Aiden :) Build time seemed a bit long ~25 mins, but am sure that will come down? Damien On 12 October 2017 at 10:17, Peter Braun wrote: > Great Demo Aiden, thanks for sharing! > > Am 12.10.2017 um 10:42 schrieb Aiden Keating : > > Hey everyone, > > We've recorded a demo about the work we've been doing recently on the > Mobile CI/CD service (Build farm integration) and using it with the Mobile > Control Panel. > > The demo is quite short and includes setting up the Mobile CI/CD service, > building an app and installing it in an emulator. > > https://youtu.be/89qSN8HXOmk > > For the PoC the Mobile CI/CD service can only produce debug Android builds > from public repositories. In the future we will provide support for private > repositories, release builds, including custom environment variables in > builds and iOS builds. > > Thanks, > Aiden > > > -- DAMIEN MURPHY SOFTWARE ENGINEER Red Hat Mobile IM: damurphy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmadigan at redhat.com Thu Oct 12 11:18:09 2017 From: jmadigan at redhat.com (Jason Madigan) Date: Thu, 12 Oct 2017 12:18:09 +0100 Subject: [feedhenry-dev] mcp-standalone vs mobile-control-panel Message-ID: Hi all, Not super urgent, but wondering if we should do a swaparoo on these repos at some point, given that mcp-standalone looks to be our route forward. Thoughts? - Jason -- Jason Madigan Engineering Manager, Red Hat Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: From dffrench at redhat.com Thu Oct 12 16:54:14 2017 From: dffrench at redhat.com (David Ffrench) Date: Thu, 12 Oct 2017 17:54:14 +0100 Subject: [feedhenry-dev] Looking for someone with fh-mbaas-express knowledge Message-ID: Hi All, I am looking to talk to someone with a high knowledge of the https://github.com/feedhenry/fh-mbaas-express codebase. Specifically around the use of the multer module. Due to a security vulnerability, i need to upgrade the version of multer from 0.1.8 to 1.0.0 which breaks the app due to a breaking change in the multer api. This will require code modifications in fh-mbaas-express to resolve. There are only 2 locations in the app that multer is used but due to the way it's api has changed, there could be more code modifications required. Any help of guidance would be greatly appreciated. Best Regards, DAVID FFRENCH senior software engineer, RED HAT MOBILE Red Hat Waterford Communications House, Cork Road Waterford, Ireland dffrench at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From eshortis at redhat.com Thu Oct 12 17:09:06 2017 From: eshortis at redhat.com (Evan Shortiss) Date: Thu, 12 Oct 2017 10:09:06 -0700 Subject: [feedhenry-dev] MCP Demo - Mobile CI/CD Service In-Reply-To: References: Message-ID: Nice work guys. I assume the build time was long due to the resource quotas applied to the container? In the future would a dropdown exist where you can specify "android" or "ios" as build targets, or is that handled elsewhere, such as the jenkinsfile? On Thu, Oct 12, 2017 at 2:31 AM, Damien Murphy wrote: > Really nice demo, thanks for sharing Aiden :) > > Build time seemed a bit long ~25 mins, but am sure that will come down? > > Damien > > On 12 October 2017 at 10:17, Peter Braun wrote: > >> Great Demo Aiden, thanks for sharing! >> >> Am 12.10.2017 um 10:42 schrieb Aiden Keating : >> >> Hey everyone, >> >> We've recorded a demo about the work we've been doing recently on the >> Mobile CI/CD service (Build farm integration) and using it with the Mobile >> Control Panel. >> >> The demo is quite short and includes setting up the Mobile CI/CD service, >> building an app and installing it in an emulator. >> >> https://youtu.be/89qSN8HXOmk >> >> For the PoC the Mobile CI/CD service can only produce debug Android >> builds from public repositories. In the future we will provide support for >> private repositories, release builds, including custom environment >> variables in builds and iOS builds. >> >> Thanks, >> Aiden >> >> >> > > > -- > > DAMIEN MURPHY > > SOFTWARE ENGINEER > > > Red Hat Mobile > > IM: damurphy > -- EVAN SHORTISS MOBILE PRACTICE ARCHITECT, RED HAT MOBILE Los Angeles, USA evan.shortiss at redhat.com M: +1-781-354-2834 -------------- next part -------------- An HTML attachment was scrubbed... URL: From cbrookes at redhat.com Thu Oct 12 18:34:00 2017 From: cbrookes at redhat.com (cbrookes at redhat.com) Date: Thu, 12 Oct 2017 19:34:00 +0100 Subject: [feedhenry-dev] MCP Demo - Mobile CI/CD Service In-Reply-To: References: Message-ID: <5BF557B5-69D6-4DAF-9F2A-82D390828D79@redhat.com> Hey Evan, Currently you create an app with a platform type, and builds live under the app. So we will use this type to inform the ui, but you are correct that the Jenkins file will ultimately decide. Craig > On 12 Oct 2017, at 18:09, Evan Shortiss wrote: > > Nice work guys. I assume the build time was long due to the resource quotas applied to the container? In the future would a dropdown exist where you can specify "android" or "ios" as build targets, or is that handled elsewhere, such as the jenkinsfile? > >> On Thu, Oct 12, 2017 at 2:31 AM, Damien Murphy wrote: >> Really nice demo, thanks for sharing Aiden :) >> >> Build time seemed a bit long ~25 mins, but am sure that will come down? >> >> Damien >> >>> On 12 October 2017 at 10:17, Peter Braun wrote: >>> Great Demo Aiden, thanks for sharing! >>> >>>> Am 12.10.2017 um 10:42 schrieb Aiden Keating : >>>> >>>> Hey everyone, >>>> >>>> We've recorded a demo about the work we've been doing recently on the Mobile CI/CD service (Build farm integration) and using it with the Mobile Control Panel. >>>> >>>> The demo is quite short and includes setting up the Mobile CI/CD service, building an app and installing it in an emulator. >>>> >>>> https://youtu.be/89qSN8HXOmk >>>> >>>> For the PoC the Mobile CI/CD service can only produce debug Android builds from public repositories. In the future we will provide support for private repositories, release builds, including custom environment variables in builds and iOS builds. >>>> >>>> Thanks, >>>> Aiden >>> >> >> >> >> -- >> >> DAMIEN MURPHY >> SOFTWARE ENGINEER >> >> Red Hat Mobile >> IM: damurphy >> > > > > -- > EVAN SHORTISS > MOBILE PRACTICE ARCHITECT, RED HAT MOBILE > Los Angeles, USA > evan.shortiss at redhat.com M: +1-781-354-2834 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eshortis at redhat.com Thu Oct 12 23:21:17 2017 From: eshortis at redhat.com (Evan Shortiss) Date: Thu, 12 Oct 2017 16:21:17 -0700 Subject: [feedhenry-dev] MCP Demo - Mobile CI/CD Service In-Reply-To: <5BF557B5-69D6-4DAF-9F2A-82D390828D79@redhat.com> References: <5BF557B5-69D6-4DAF-9F2A-82D390828D79@redhat.com> Message-ID: Thanks for the clarification Craig. On Thu, Oct 12, 2017 at 11:34 AM, cbrookes at redhat.com wrote: > Hey Evan, > Currently you create an app with a platform type, and builds live under > the app. So we will use this type to inform the ui, but you are correct > that the Jenkins file will ultimately decide. > > Craig > > On 12 Oct 2017, at 18:09, Evan Shortiss wrote: > > Nice work guys. I assume the build time was long due to the resource > quotas applied to the container? In the future would a dropdown exist where > you can specify "android" or "ios" as build targets, or is that handled > elsewhere, such as the jenkinsfile? > > On Thu, Oct 12, 2017 at 2:31 AM, Damien Murphy > wrote: > >> Really nice demo, thanks for sharing Aiden :) >> >> Build time seemed a bit long ~25 mins, but am sure that will come down? >> >> Damien >> >> On 12 October 2017 at 10:17, Peter Braun wrote: >> >>> Great Demo Aiden, thanks for sharing! >>> >>> Am 12.10.2017 um 10:42 schrieb Aiden Keating : >>> >>> Hey everyone, >>> >>> We've recorded a demo about the work we've been doing recently on the >>> Mobile CI/CD service (Build farm integration) and using it with the Mobile >>> Control Panel. >>> >>> The demo is quite short and includes setting up the Mobile CI/CD >>> service, building an app and installing it in an emulator. >>> >>> https://youtu.be/89qSN8HXOmk >>> >>> For the PoC the Mobile CI/CD service can only produce debug Android >>> builds from public repositories. In the future we will provide support for >>> private repositories, release builds, including custom environment >>> variables in builds and iOS builds. >>> >>> Thanks, >>> Aiden >>> >>> >>> >> >> >> -- >> >> DAMIEN MURPHY >> >> SOFTWARE ENGINEER >> >> >> Red Hat Mobile >> >> IM: damurphy >> > > > > -- > > EVAN SHORTISS > > MOBILE PRACTICE ARCHITECT, RED HAT MOBILE > > Los Angeles, USA > > evan.shortiss at redhat.com M: +1-781-354-2834 > > > -- EVAN SHORTISS MOBILE PRACTICE ARCHITECT, RED HAT MOBILE Los Angeles, USA evan.shortiss at redhat.com M: +1-781-354-2834 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Fri Oct 13 07:06:07 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Fri, 13 Oct 2017 09:06:07 +0200 Subject: [feedhenry-dev] ASB problem ? Message-ID: Hi, anybody seen this problem before ? [2017-10-13T07:01:14.351Z] [ERROR] Something went wrong loading decoded spec yaml, YAML error: line 17: did not find expected key [2017-10-13T07:01:14.351Z] [ERROR] unable to retrieve spec data for image - YAML error: line 17: did not find expected key [2017-10-13T07:01:14.351Z] [ERROR] unable to fetch specs for registry dh - YAML error: line 17: did not find expected key [2017-10-13T07:01:14.352Z] [WARNING] registry: 0x14ca600 was unable to complete bootstrap - YAML error: line 17: did not find expected key [2017-10-13T07:01:14.352Z] [ERROR] Failed to bootstrap on startup! [2017-10-13T07:01:14.352Z] [ERROR] all registries failed on bootstrap I noticed it start to occur as of yesterday... not exactly sure why/how :-/ -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfrizell at redhat.com Fri Oct 13 08:37:56 2017 From: jfrizell at redhat.com (John Frizelle) Date: Fri, 13 Oct 2017 09:37:56 +0100 Subject: [feedhenry-dev] Looking for someone with fh-mbaas-express knowledge In-Reply-To: References: Message-ID: Hi David, I have had a look through the code and as far as I can tell, the changes are relatively straight forward. There are 3 places where an additional parameter is required in a route definition: - https://github.com/feedhenry/fh-mbaas-express/blob/master/lib/cloud/cloud.js#L45 - https://github.com/feedhenry/fh-mbaas-express/blob/master/lib/mbaas.js#L173 - https://github.com/feedhenry/fh-mbaas-express/blob/master/lib/mbaas.js#L299 In all 3 cases, we need to add upload.any() as the middle param - this will put any uploaded files in a files array, which is what is expected in the rest of the code [1]. Regards, John. [1] https://github.com/feedhenry/fh-mbaas-express/blob/master/lib/cloud/params.js#L42 , https://github.com/feedhenry/fh-mbaas-express/blob/master/lib/common/requestValidator.js#L111 , https://github.com/feedhenry/fh-mbaas-express/blob/master/lib/fh-middleware.js#L25 , https://github.com/feedhenry/fh-mbaas-express/blob/master/lib/cloud/cloud.js#L69 -- John Frizelle Chief Architect, Red Hat Mobile Consulting Engineer mobile: *+353 87 290 1644 * twitter:* @johnfriz* skype: *john_frizelle* mail: *jfrizell at redhat.com * On 12 October 2017 at 17:54, David Ffrench wrote: > Hi All, > > I am looking to talk to someone with a high knowledge of the > https://github.com/feedhenry/fh-mbaas-express codebase. Specifically > around the use of the multer module. > > Due to a security vulnerability, i need to upgrade the version of multer > from 0.1.8 to 1.0.0 which breaks the app due to a breaking change in the > multer api. This will require code modifications in fh-mbaas-express to > resolve. > > There are only 2 locations in the app that multer is used but due to the > way it's api has changed, there could be more code modifications required. > > Any help of guidance would be greatly appreciated. > > Best Regards, > > DAVID FFRENCH > > senior software engineer, RED HAT MOBILE > > Red Hat Waterford > > Communications House, Cork Road > > Waterford, Ireland > > dffrench at redhat.com > > > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 11472 bytes Desc: not available URL: From davmarti at redhat.com Fri Oct 13 08:42:45 2017 From: davmarti at redhat.com (David Martin) Date: Fri, 13 Oct 2017 09:42:45 +0100 Subject: [feedhenry-dev] ASB problem ? In-Reply-To: References: Message-ID: Is it possible the decoded spec yaml from a Docker image is invalid? e.g. the thing in this kind of label https://github.com/feedhenry/aerogear-digger-apb/blob/master/Dockerfile#L4-L24 LABEL "com.blah.apb.spec"=someencodedyamlthatsactuallyinvalid On 13 October 2017 at 08:06, Matthias Wessendorf wrote: > Hi, > > anybody seen this problem before ? > > [2017-10-13T07:01:14.351Z] [ERROR] Something went wrong loading decoded > spec yaml, YAML error: line 17: did not find expected key > [2017-10-13T07:01:14.351Z] [ERROR] unable to retrieve spec data for image > - YAML error: line 17: did not find expected key > [2017-10-13T07:01:14.351Z] [ERROR] unable to fetch specs for registry dh - > YAML error: line 17: did not find expected key > [2017-10-13T07:01:14.352Z] [WARNING] registry: 0x14ca600 was unable to > complete bootstrap - YAML error: line 17: did not find expected key > [2017-10-13T07:01:14.352Z] [ERROR] Failed to bootstrap on startup! > [2017-10-13T07:01:14.352Z] [ERROR] all registries failed on bootstrap > > > I noticed it start to occur as of yesterday... not exactly sure why/how :-/ > > > -- > Project lead AeroGear.org > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Fri Oct 13 08:48:22 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Fri, 13 Oct 2017 10:48:22 +0200 Subject: [feedhenry-dev] ASB problem ? In-Reply-To: References: Message-ID: nope - that was not the issue. I;ve deleted two "inprogress" repos ... from my hub accoiunt: * fh-sync-server-abp * kafka-apb Those were "inprogress", and did cause the entie ASB to fail We are on an older version - have to check if an "invalid" ABP really crashes the entire POD on their latests ... Thanks for the email - I've now "unblocked" myself On Fri, Oct 13, 2017 at 10:42 AM, David Martin wrote: > Is it possible the decoded spec yaml from a Docker image is invalid? > > e.g. the thing in this kind of label > https://github.com/feedhenry/aerogear-digger-apb/blob/ > master/Dockerfile#L4-L24 > > LABEL "com.blah.apb.spec"=someencodedyamlthatsactuallyinvalid > > > On 13 October 2017 at 08:06, Matthias Wessendorf > wrote: > >> Hi, >> >> anybody seen this problem before ? >> >> [2017-10-13T07:01:14.351Z] [ERROR] Something went wrong loading decoded >> spec yaml, YAML error: line 17: did not find expected key >> [2017-10-13T07:01:14.351Z] [ERROR] unable to retrieve spec data for image >> - YAML error: line 17: did not find expected key >> [2017-10-13T07:01:14.351Z] [ERROR] unable to fetch specs for registry dh >> - YAML error: line 17: did not find expected key >> [2017-10-13T07:01:14.352Z] [WARNING] registry: 0x14ca600 was unable to >> complete bootstrap - YAML error: line 17: did not find expected key >> [2017-10-13T07:01:14.352Z] [ERROR] Failed to bootstrap on startup! >> [2017-10-13T07:01:14.352Z] [ERROR] all registries failed on bootstrap >> >> >> I noticed it start to occur as of yesterday... not exactly sure why/how >> :-/ >> >> >> -- >> Project lead AeroGear.org >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > > -- > David Martin > Red Hat Mobile > Twitter: @irldavem > IRC: @irldavem (feedhenry, mobile-internal) > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From davmarti at redhat.com Fri Oct 13 08:51:14 2017 From: davmarti at redhat.com (David Martin) Date: Fri, 13 Oct 2017 09:51:14 +0100 Subject: [feedhenry-dev] MCP Demo - Mobile CI/CD Service In-Reply-To: References: <5BF557B5-69D6-4DAF-9F2A-82D390828D79@redhat.com> Message-ID: Hey Evan, There is a 'Cordova' app type, so a dropdown might make sense for that. It could pass along an env var to the jenkins build to specify the platform type choosen. Then in your Jenkinsfile you can switch what to do based on that env var value. Alternatively, your Cordova Jenkinsfile could build multiple artifacts. According to this https://www.cloudbees.com/blog/top-10-best-practices-jenkins-pipeline-plugin, you can specify different nodes in the 1 pipeline, so you could execute a build for android & ios as part of the one build. e.g. parallel 'cordova-build':{ node('android'){ ... } }, 'functional-tests':{ node('ios'){ ... } } On 13 October 2017 at 00:21, Evan Shortiss wrote: > Thanks for the clarification Craig. > > On Thu, Oct 12, 2017 at 11:34 AM, cbrookes at redhat.com > wrote: > >> Hey Evan, >> Currently you create an app with a platform type, and builds live under >> the app. So we will use this type to inform the ui, but you are correct >> that the Jenkins file will ultimately decide. >> >> Craig >> >> On 12 Oct 2017, at 18:09, Evan Shortiss wrote: >> >> Nice work guys. I assume the build time was long due to the resource >> quotas applied to the container? In the future would a dropdown exist where >> you can specify "android" or "ios" as build targets, or is that handled >> elsewhere, such as the jenkinsfile? >> >> On Thu, Oct 12, 2017 at 2:31 AM, Damien Murphy >> wrote: >> >>> Really nice demo, thanks for sharing Aiden :) >>> >>> Build time seemed a bit long ~25 mins, but am sure that will come down? >>> >>> Damien >>> >>> On 12 October 2017 at 10:17, Peter Braun wrote: >>> >>>> Great Demo Aiden, thanks for sharing! >>>> >>>> Am 12.10.2017 um 10:42 schrieb Aiden Keating : >>>> >>>> Hey everyone, >>>> >>>> We've recorded a demo about the work we've been doing recently on the >>>> Mobile CI/CD service (Build farm integration) and using it with the Mobile >>>> Control Panel. >>>> >>>> The demo is quite short and includes setting up the Mobile CI/CD >>>> service, building an app and installing it in an emulator. >>>> >>>> https://youtu.be/89qSN8HXOmk >>>> >>>> For the PoC the Mobile CI/CD service can only produce debug Android >>>> builds from public repositories. In the future we will provide support for >>>> private repositories, release builds, including custom environment >>>> variables in builds and iOS builds. >>>> >>>> Thanks, >>>> Aiden >>>> >>>> >>>> >>> >>> >>> -- >>> >>> DAMIEN MURPHY >>> >>> SOFTWARE ENGINEER >>> >>> >>> Red Hat Mobile >>> >>> IM: damurphy >>> >> >> >> >> -- >> >> EVAN SHORTISS >> >> MOBILE PRACTICE ARCHITECT, RED HAT MOBILE >> >> Los Angeles, USA >> >> evan.shortiss at redhat.com M: +1-781-354-2834 >> >> >> > > > -- > > EVAN SHORTISS > > MOBILE PRACTICE ARCHITECT, RED HAT MOBILE > > Los Angeles, USA > > evan.shortiss at redhat.com M: +1-781-354-2834 > > -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From pahayes at redhat.com Fri Oct 13 13:50:34 2017 From: pahayes at redhat.com (Dara Hayes) Date: Fri, 13 Oct 2017 14:50:34 +0100 Subject: [feedhenry-dev] MCP Demo - Mobile CI/CD Service In-Reply-To: References: <5BF557B5-69D6-4DAF-9F2A-82D390828D79@redhat.com> Message-ID: Great Job Aiden! You've got the perfect voice for demos! :D Enjoy your weekend, - Dara On Fri, Oct 13, 2017 at 9:51 AM, David Martin wrote: > Hey Evan, > > There is a 'Cordova' app type, so a dropdown might make sense for that. > It could pass along an env var to the jenkins build to specify the > platform type choosen. Then in your Jenkinsfile you can switch what to do > based on that env var value. > > Alternatively, your Cordova Jenkinsfile could build multiple artifacts. > According to this https://www.cloudbees.com/blog/top-10-best- > practices-jenkins-pipeline-plugin, you can specify different nodes in the > 1 pipeline, so you could execute a build for android & ios as part of the > one build. > > e.g. > parallel 'cordova-build':{ > node('android'){ ... } > }, 'functional-tests':{ > node('ios'){ ... } > } > > On 13 October 2017 at 00:21, Evan Shortiss wrote: > >> Thanks for the clarification Craig. >> >> On Thu, Oct 12, 2017 at 11:34 AM, cbrookes at redhat.com < >> cbrookes at redhat.com> wrote: >> >>> Hey Evan, >>> Currently you create an app with a platform type, and builds live under >>> the app. So we will use this type to inform the ui, but you are correct >>> that the Jenkins file will ultimately decide. >>> >>> Craig >>> >>> On 12 Oct 2017, at 18:09, Evan Shortiss wrote: >>> >>> Nice work guys. I assume the build time was long due to the resource >>> quotas applied to the container? In the future would a dropdown exist where >>> you can specify "android" or "ios" as build targets, or is that handled >>> elsewhere, such as the jenkinsfile? >>> >>> On Thu, Oct 12, 2017 at 2:31 AM, Damien Murphy >>> wrote: >>> >>>> Really nice demo, thanks for sharing Aiden :) >>>> >>>> Build time seemed a bit long ~25 mins, but am sure that will come down? >>>> >>>> Damien >>>> >>>> On 12 October 2017 at 10:17, Peter Braun wrote: >>>> >>>>> Great Demo Aiden, thanks for sharing! >>>>> >>>>> Am 12.10.2017 um 10:42 schrieb Aiden Keating : >>>>> >>>>> Hey everyone, >>>>> >>>>> We've recorded a demo about the work we've been doing recently on the >>>>> Mobile CI/CD service (Build farm integration) and using it with the Mobile >>>>> Control Panel. >>>>> >>>>> The demo is quite short and includes setting up the Mobile CI/CD >>>>> service, building an app and installing it in an emulator. >>>>> >>>>> https://youtu.be/89qSN8HXOmk >>>>> >>>>> For the PoC the Mobile CI/CD service can only produce debug Android >>>>> builds from public repositories. In the future we will provide support for >>>>> private repositories, release builds, including custom environment >>>>> variables in builds and iOS builds. >>>>> >>>>> Thanks, >>>>> Aiden >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> DAMIEN MURPHY >>>> >>>> SOFTWARE ENGINEER >>>> >>>> >>>> Red Hat Mobile >>>> >>>> IM: damurphy >>>> >>> >>> >>> >>> -- >>> >>> EVAN SHORTISS >>> >>> MOBILE PRACTICE ARCHITECT, RED HAT MOBILE >>> >>> Los Angeles, USA >>> >>> evan.shortiss at redhat.com M: +1-781-354-2834 >>> >>> >>> >> >> >> -- >> >> EVAN SHORTISS >> >> MOBILE PRACTICE ARCHITECT, RED HAT MOBILE >> >> Los Angeles, USA >> >> evan.shortiss at redhat.com M: +1-781-354-2834 >> >> > > > > -- > David Martin > Red Hat Mobile > Twitter: @irldavem > IRC: @irldavem (feedhenry, mobile-internal) > -- Dara Hayes ASsociate SOFTWARE ENGINEER, RED HAT MOBILE Red Hat Waterford Communications House, Cork Road Waterford, Ireland dara.hayes at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From davmarti at redhat.com Fri Oct 13 20:36:05 2017 From: davmarti at redhat.com (David Martin) Date: Fri, 13 Oct 2017 21:36:05 +0100 Subject: [feedhenry-dev] ASB problem ? In-Reply-To: References: Message-ID: I'm seeing this now in a fresh ec2 instance and install of mcp. [2017-10-13T20:32:06.704Z] [DEBUG] Registry::imageToSpec [2017-10-13T20:32:06.847Z] [ERROR] Something went wrong loading decoded spec yaml, YAML error: line 18: did not find expected key [2017-10-13T20:32:06.847Z] [ERROR] unable to retrieve spec data for image - YAML error: line 18: did not find expected key [2017-10-13T20:32:06.847Z] [ERROR] unable to fetch specs for registry dh - YAML error: line 18: did not find expected key [2017-10-13T20:32:06.847Z] [WARNING] registry: 0x14ca600 was unable to complete bootstrap - YAML error: line 18: did not find expected key [2017-10-13T20:32:06.847Z] [ERROR] Failed to bootstrap on startup! [2017-10-13T20:32:06.847Z] [ERROR] all registries failed on bootstrap It's configured to use the feedhenry dockerhub org. Is there a oddly/old format apb image in the feedhenry org? >From the order of images in the logs, it looks like its failing on feedhenry/fh-sync-server-apb. Is there a way to omit images, or could we remove this image for now to prevent people having issues? On 13 October 2017 at 09:48, Matthias Wessendorf wrote: > nope - that was not the issue. > > I;ve deleted two "inprogress" repos ... from my hub accoiunt: > * fh-sync-server-abp > * kafka-apb > > Those were "inprogress", and did cause the entie ASB to fail > > We are on an older version - have to check if an "invalid" ABP really > crashes the entire POD on their latests ... > > Thanks for the email - I've now "unblocked" myself > > On Fri, Oct 13, 2017 at 10:42 AM, David Martin > wrote: > >> Is it possible the decoded spec yaml from a Docker image is invalid? >> >> e.g. the thing in this kind of label >> https://github.com/feedhenry/aerogear-digger-apb/blob/master >> /Dockerfile#L4-L24 >> >> LABEL "com.blah.apb.spec"=someencodedyamlthatsactuallyinvalid >> >> >> On 13 October 2017 at 08:06, Matthias Wessendorf >> wrote: >> >>> Hi, >>> >>> anybody seen this problem before ? >>> >>> [2017-10-13T07:01:14.351Z] [ERROR] Something went wrong loading decoded >>> spec yaml, YAML error: line 17: did not find expected key >>> [2017-10-13T07:01:14.351Z] [ERROR] unable to retrieve spec data for >>> image - YAML error: line 17: did not find expected key >>> [2017-10-13T07:01:14.351Z] [ERROR] unable to fetch specs for registry dh >>> - YAML error: line 17: did not find expected key >>> [2017-10-13T07:01:14.352Z] [WARNING] registry: 0x14ca600 was unable to >>> complete bootstrap - YAML error: line 17: did not find expected key >>> [2017-10-13T07:01:14.352Z] [ERROR] Failed to bootstrap on startup! >>> [2017-10-13T07:01:14.352Z] [ERROR] all registries failed on bootstrap >>> >>> >>> I noticed it start to occur as of yesterday... not exactly sure why/how >>> :-/ >>> >>> >>> -- >>> Project lead AeroGear.org >>> >>> _______________________________________________ >>> feedhenry-dev mailing list >>> feedhenry-dev at redhat.com >>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>> >>> >> >> >> -- >> David Martin >> Red Hat Mobile >> Twitter: @irldavem >> IRC: @irldavem (feedhenry, mobile-internal) >> > > > > -- > Project lead AeroGear.org > -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From davmarti at redhat.com Fri Oct 13 20:47:03 2017 From: davmarti at redhat.com (David Martin) Date: Fri, 13 Oct 2017 21:47:03 +0100 Subject: [feedhenry-dev] ASB problem ? In-Reply-To: References: Message-ID: Looks like the apb yaml that's in the LABEL could be invalid. Seems like you spotted this already Matthias :) https://github.com/feedhenry/fh-sync-server-apb/pull/1 I'll verify this and push to the feedhenry org On 13 October 2017 at 21:36, David Martin wrote: > I'm seeing this now in a fresh ec2 instance and install of mcp. > > [2017-10-13T20:32:06.704Z] [DEBUG] Registry::imageToSpec > [2017-10-13T20:32:06.847Z] [ERROR] Something went wrong loading decoded > spec yaml, YAML error: line 18: did not find expected key > [2017-10-13T20:32:06.847Z] [ERROR] unable to retrieve spec data for image > - YAML error: line 18: did not find expected key > [2017-10-13T20:32:06.847Z] [ERROR] unable to fetch specs for registry dh - > YAML error: line 18: did not find expected key > [2017-10-13T20:32:06.847Z] [WARNING] registry: 0x14ca600 was unable to > complete bootstrap - YAML error: line 18: did not find expected key > [2017-10-13T20:32:06.847Z] [ERROR] Failed to bootstrap on startup! > [2017-10-13T20:32:06.847Z] [ERROR] all registries failed on bootstrap > > It's configured to use the feedhenry dockerhub org. > Is there a oddly/old format apb image in the feedhenry org? > > From the order of images in the logs, it looks like its failing > on feedhenry/fh-sync-server-apb. > Is there a way to omit images, or could we remove this image for now to > prevent people having issues? > > On 13 October 2017 at 09:48, Matthias Wessendorf > wrote: > >> nope - that was not the issue. >> >> I;ve deleted two "inprogress" repos ... from my hub accoiunt: >> * fh-sync-server-abp >> * kafka-apb >> >> Those were "inprogress", and did cause the entie ASB to fail >> >> We are on an older version - have to check if an "invalid" ABP really >> crashes the entire POD on their latests ... >> >> Thanks for the email - I've now "unblocked" myself >> >> On Fri, Oct 13, 2017 at 10:42 AM, David Martin >> wrote: >> >>> Is it possible the decoded spec yaml from a Docker image is invalid? >>> >>> e.g. the thing in this kind of label >>> https://github.com/feedhenry/aerogear-digger-apb/blob/master >>> /Dockerfile#L4-L24 >>> >>> LABEL "com.blah.apb.spec"=someencodedyamlthatsactuallyinvalid >>> >>> >>> On 13 October 2017 at 08:06, Matthias Wessendorf >>> wrote: >>> >>>> Hi, >>>> >>>> anybody seen this problem before ? >>>> >>>> [2017-10-13T07:01:14.351Z] [ERROR] Something went wrong loading decoded >>>> spec yaml, YAML error: line 17: did not find expected key >>>> [2017-10-13T07:01:14.351Z] [ERROR] unable to retrieve spec data for >>>> image - YAML error: line 17: did not find expected key >>>> [2017-10-13T07:01:14.351Z] [ERROR] unable to fetch specs for registry >>>> dh - YAML error: line 17: did not find expected key >>>> [2017-10-13T07:01:14.352Z] [WARNING] registry: 0x14ca600 was unable to >>>> complete bootstrap - YAML error: line 17: did not find expected key >>>> [2017-10-13T07:01:14.352Z] [ERROR] Failed to bootstrap on startup! >>>> [2017-10-13T07:01:14.352Z] [ERROR] all registries failed on bootstrap >>>> >>>> >>>> I noticed it start to occur as of yesterday... not exactly sure why/how >>>> :-/ >>>> >>>> >>>> -- >>>> Project lead AeroGear.org >>>> >>>> _______________________________________________ >>>> feedhenry-dev mailing list >>>> feedhenry-dev at redhat.com >>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>> >>>> >>> >>> >>> -- >>> David Martin >>> Red Hat Mobile >>> Twitter: @irldavem >>> IRC: @irldavem (feedhenry, mobile-internal) >>> >> >> >> >> -- >> Project lead AeroGear.org >> > > > > -- > David Martin > Red Hat Mobile > Twitter: @irldavem > IRC: @irldavem (feedhenry, mobile-internal) > -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From wtrocki at redhat.com Sun Oct 15 17:10:35 2017 From: wtrocki at redhat.com (Wojciech Trocki) Date: Sun, 15 Oct 2017 18:10:35 +0100 Subject: [feedhenry-dev] Repositories for MCP project Message-ID: Hi I noticed that MCP project github repository had no commits for the last month[1] There is another repository with much more traffic[2] I just want to make sure that mcp-standalone is the repository I should use. Is that right? I have seen great demo that helped with on boarding a lot. IMHO it should be added to project README as it delivers a lots of context over the text documentation. Do you guys have website? Maybe I can help and add project to feedhenry.org along with some info how to contribute? Github has really good checkers for community involvement: https://github.com/feedhenry/mcp-standalone/community [1] https://github.com/feedhenry/mobile-control-panel/graphs/contributors [2] https://github.com/feedhenry/mcp-standalone -- WOJCIECH TROCKI Red Hat Mobile IM: wtrocki -------------- next part -------------- An HTML attachment was scrubbed... URL: From wtrocki at redhat.com Sun Oct 15 17:31:48 2017 From: wtrocki at redhat.com (Wojciech Trocki) Date: Sun, 15 Oct 2017 18:31:48 +0100 Subject: [feedhenry-dev] [MCP] Proposal for file storage service Message-ID: Hi lads I'm representing RainCatcher team. As a team we are planning to work on the functionality that possibly may also exist as MCP service. *Introduction * Ability to store files (large binary data) is really common for the mobile applications. In most of the corporate use cases files cannot be saved on the public storage clouds like ICloud, Google drive etc. Previous versions of RHMAP had unofficial version of the file storage template that was widely used. Adding file storage as service will directly address common problem for most of the *corporate* *mobile* developers. Ability to use file storage service behind Keycloak service may help to validate security use cases. *Technical details:* Service will consist of the server side file server (similar to sync service). Implementation will be delivered in TypeScript. Storage will use GridFS by default, but it will be swappable by using interface. Additionally service will provide client (Cordova for the moment but we may support ReactNative in future) *Is this service useful/interesting for MCP team?* *RainCatcher Community request:* https://www.redhat.com/archives/feedhenry-raincatcher/2017-October/ msg00023.html *Context* As a team we need to deliver File/Image storage functionality, but also make sure that it will be usable even outside RainCatcher solution. I have read about and tried MCP for the last couple days and it looks really interesting. I'm working now (in my spare time) on spiking integration for RainCatcher project with MCP. Focusing mostly on using external sync and Keycloak service. As a team we will widely benefit from MPC (it will simplify our OpenShift deployment). Additionally team can upskill in OpenShift and MCP while delivering this service. *Jira epic:* https://issues.jboss.org/browse/RAINCATCH-1346 Regards -- WOJCIECH TROCKI -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfrizell at redhat.com Sun Oct 15 22:47:43 2017 From: jfrizell at redhat.com (John Frizelle) Date: Sun, 15 Oct 2017 23:47:43 +0100 Subject: [feedhenry-dev] Repositories for MCP project In-Reply-To: References: Message-ID: Hi Wojciech, Yes, https://github.com/feedhenry/mcp-standalone is the active repo. We have not got website updates done yet. Feel free to PR the readme to add the links to the 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 15 October 2017 at 18:10, Wojciech Trocki wrote: > Hi > > I noticed that MCP project github repository had no commits for the last > month[1] > There is another repository with much more traffic[2] > > I just want to make sure that mcp-standalone is the repository I should > use. > Is that right? > > I have seen great demo that helped with on boarding a lot. > IMHO it should be added to project README as it delivers a lots of context > over the text documentation. > > Do you guys have website? > Maybe I can help and add project to feedhenry.org along with some info > how to contribute? > > Github has really good checkers for community involvement: > https://github.com/feedhenry/mcp-standalone/community > > [1] https://github.com/feedhenry/mobile-control-panel/graphs/contributors > [2] https://github.com/feedhenry/mcp-standalone > -- > > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 11472 bytes Desc: not available URL: From dffrench at redhat.com Mon Oct 16 07:39:49 2017 From: dffrench at redhat.com (David Ffrench) Date: Mon, 16 Oct 2017 08:39:49 +0100 Subject: [feedhenry-dev] Looking for someone with fh-mbaas-express knowledge In-Reply-To: References: Message-ID: Thank you very much for the response John, your information is extremely helpful. DAVID FFRENCH senior software engineer, RED HAT MOBILE Red Hat Waterford Communications House, Cork Road Waterford, Ireland dffrench at redhat.com On Fri, Oct 13, 2017 at 9:37 AM, John Frizelle wrote: > Hi David, > > I have had a look through the code and as far as I can tell, the changes > are relatively straight forward. There are 3 places where an additional > parameter is required in a route definition: > > - https://github.com/feedhenry/fh-mbaas-express/blob/master/ > lib/cloud/cloud.js#L45 > - https://github.com/feedhenry/fh-mbaas-express/blob/master/ > lib/mbaas.js#L173 > - https://github.com/feedhenry/fh-mbaas-express/blob/master/ > lib/mbaas.js#L299 > > In all 3 cases, we need to add upload.any() as the middle param - this > will put any uploaded files in a files array, which is what is expected > in the rest of the code [1]. > > Regards, > John. > > [1] https://github.com/feedhenry/fh-mbaas-express/ > blob/master/lib/cloud/params.js#L42, https://github.com/ > feedhenry/fh-mbaas-express/blob/master/lib/common/requestValidator.js#L111 > , https://github.com/feedhenry/fh-mbaas-express/blob/master/lib/ > fh-middleware.js#L25, https://github.com/feedhenry/fh-mbaas- > express/blob/master/lib/cloud/cloud.js#L69 > > > -- > John Frizelle > Chief Architect, Red Hat Mobile > Consulting Engineer > > mobile: *+353 87 290 1644 * > twitter:* @johnfriz* > skype: *john_frizelle* > mail: *jfrizell at redhat.com * > > > > > On 12 October 2017 at 17:54, David Ffrench wrote: > >> Hi All, >> >> I am looking to talk to someone with a high knowledge of the >> https://github.com/feedhenry/fh-mbaas-express codebase. Specifically >> around the use of the multer module. >> >> Due to a security vulnerability, i need to upgrade the version of multer >> from 0.1.8 to 1.0.0 which breaks the app due to a breaking change in the >> multer api. This will require code modifications in fh-mbaas-express to >> resolve. >> >> There are only 2 locations in the app that multer is used but due to the >> way it's api has changed, there could be more code modifications required. >> >> Any help of guidance would be greatly appreciated. >> >> Best Regards, >> >> DAVID FFRENCH >> >> senior software engineer, RED HAT MOBILE >> >> Red Hat Waterford >> >> Communications House, Cork Road >> >> Waterford, Ireland >> >> dffrench at redhat.com >> >> >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 11472 bytes Desc: not available URL: From davmarti at redhat.com Mon Oct 16 08:57:02 2017 From: davmarti at redhat.com (David Martin) Date: Mon, 16 Oct 2017 09:57:02 +0100 Subject: [feedhenry-dev] [Feedhenry-raincatcher] [MCP] Proposal for file storage service In-Reply-To: References: Message-ID: Hi Wojciech, An object storage sounds like a useful Mobile Service. If the service has a docker image that doesn't require special privileges, then it should be good for running on OpenShift. How it could fit in nicely with the 5.x work is having Mobile clients/libraries and examples for different platforms and languages. e.g. Java & Kotlin for Android, Swift for iOS, js/browser for Cordova, js for React Native. Are you already decided on GridFS? Is there a comparison you have done on different store types? Have you looked into any kubernetes addons? e.g. Minio https://docs.minio.io/ On 15 October 2017 at 18:31, Wojciech Trocki wrote: > Hi lads > > I'm representing RainCatcher team. > As a team we are planning to work on the functionality that possibly may > also exist as MCP service. > > *Introduction * > > Ability to store files (large binary data) is really common for the mobile > applications. > In most of the corporate use cases files cannot be saved on the public > storage clouds like ICloud, Google drive etc. > Previous versions of RHMAP had unofficial version of the file storage > template that was widely used. > > Adding file storage as service will directly address common problem for > most of the *corporate* *mobile* developers. > Ability to use file storage service behind Keycloak service may help to > validate security use cases. > > *Technical details:* > > Service will consist of the server side file server (similar to sync > service). > Implementation will be delivered in TypeScript. Storage will use GridFS by > default, but it will be swappable by using interface. > Additionally service will provide client (Cordova for the moment but we > may support ReactNative in future) > > *Is this service useful/interesting for MCP team?* > > *RainCatcher Community request:* > https://www.redhat.com/archives/feedhenry-raincatcher/2017- > October/msg00023.html > > *Context* > > As a team we need to deliver File/Image storage functionality, but also > make sure that it will be usable even outside RainCatcher solution. > I have read about and tried MCP for the last couple days and it looks > really interesting. > I'm working now (in my spare time) on spiking integration for RainCatcher > project with MCP. > Focusing mostly on using external sync and Keycloak service. > As a team we will widely benefit from MPC (it will simplify our OpenShift > deployment). > Additionally team can upskill in OpenShift and MCP while delivering this > service. > > *Jira epic:* > https://issues.jboss.org/browse/RAINCATCH-1346 > > Regards > -- > > WOJCIECH TROCKI > > _______________________________________________ > Feedhenry-raincatcher mailing list > Feedhenry-raincatcher at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-raincatcher > > -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfrizell at redhat.com Mon Oct 16 09:27:19 2017 From: jfrizell at redhat.com (John Frizelle) Date: Mon, 16 Oct 2017 10:27:19 +0100 Subject: [feedhenry-dev] [Feedhenry-raincatcher] [MCP] Proposal for file storage service In-Reply-To: References: Message-ID: +1 on a file / object storage service and on Dave's comments around client libs. Under the 5.x model, we are developing stand alone libs for each service, but with some level of common structure (still TBD I think - it's basically a plugin architecture client side for passing config from the core module to each "plugin" at startup) On the server side storage engine side, my ask is that you look at ceph and gluster as potential storage engines - this would help advance the 5.x integration objectives. I know that the folks on the ops team have looked at these in quite a bit of detail, so should have some good insights to share. 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 16 October 2017 at 09:57, David Martin wrote: > Hi Wojciech, > > An object storage sounds like a useful Mobile Service. > If the service has a docker image that doesn't require special privileges, > then it should be good for running on OpenShift. > How it could fit in nicely with the 5.x work is having Mobile > clients/libraries and examples for different platforms and languages. > e.g. Java & Kotlin for Android, Swift for iOS, js/browser for Cordova, js > for React Native. > > Are you already decided on GridFS? > Is there a comparison you have done on different store types? > > Have you looked into any kubernetes addons? > e.g. Minio https://docs.minio.io/ > > > On 15 October 2017 at 18:31, Wojciech Trocki wrote: > >> Hi lads >> >> I'm representing RainCatcher team. >> As a team we are planning to work on the functionality that possibly may >> also exist as MCP service. >> >> *Introduction * >> >> Ability to store files (large binary data) is really common for the >> mobile applications. >> In most of the corporate use cases files cannot be saved on the public >> storage clouds like ICloud, Google drive etc. >> Previous versions of RHMAP had unofficial version of the file storage >> template that was widely used. >> >> Adding file storage as service will directly address common problem for >> most of the *corporate* *mobile* developers. >> Ability to use file storage service behind Keycloak service may help to >> validate security use cases. >> >> *Technical details:* >> >> Service will consist of the server side file server (similar to sync >> service). >> Implementation will be delivered in TypeScript. Storage will use GridFS >> by default, but it will be swappable by using interface. >> Additionally service will provide client (Cordova for the moment but we >> may support ReactNative in future) >> >> *Is this service useful/interesting for MCP team?* >> >> *RainCatcher Community request:* >> https://www.redhat.com/archives/feedhenry-raincatcher/2017-O >> ctober/msg00023.html >> >> *Context* >> >> As a team we need to deliver File/Image storage functionality, but also >> make sure that it will be usable even outside RainCatcher solution. >> I have read about and tried MCP for the last couple days and it looks >> really interesting. >> I'm working now (in my spare time) on spiking integration for RainCatcher >> project with MCP. >> Focusing mostly on using external sync and Keycloak service. >> As a team we will widely benefit from MPC (it will simplify our >> OpenShift deployment). >> Additionally team can upskill in OpenShift and MCP while delivering this >> service. >> >> *Jira epic:* >> https://issues.jboss.org/browse/RAINCATCH-1346 >> >> Regards >> -- >> >> WOJCIECH TROCKI >> >> _______________________________________________ >> Feedhenry-raincatcher mailing list >> Feedhenry-raincatcher at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-raincatcher >> >> > > > -- > David Martin > Red Hat Mobile > Twitter: @irldavem > IRC: @irldavem (feedhenry, mobile-internal) > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- 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 Mon Oct 16 10:02:08 2017 From: wtrocki at redhat.com (Wojciech Trocki) Date: Mon, 16 Oct 2017 11:02:08 +0100 Subject: [feedhenry-dev] [Feedhenry-raincatcher] [MCP] Proposal for file storage service In-Reply-To: References: Message-ID: Thanks of response > 1) Are you already decided on GridFS? We will abstract from actual storage, similar how sync abstract from the database solution. Gridfs will be just provided as default implementation. We need to have something that will work outside the box) > 2) Is there a comparison you have done on different store types? Server side will provide interface so any possible storage can be used. We trying to focus on resolving file storage (offline sync) problem on the mobile. Server side is open and for the moment we may want to use something that is already available for RainCatcher developers (GridFS) > Have you looked into any kubernetes addons? e.g. Minio https://docs.minio.io/ That may be added later as alternative implementation along with other like NFS, Ceph. This will fit perfectly to interface we going to build. Target is to get something out there as spike, while still meeting RainCatcher functional requirements. > How it could fit in nicely with the 5.x work is having Mobile clients/libraries and examples for different platforms and languages. We can provide only Javascript/Cordova initially. ReactNative later. On Mon, Oct 16, 2017 at 10:27 AM, John Frizelle wrote: > +1 on a file / object storage service and on Dave's comments around client > libs. Under the 5.x model, we are developing stand alone libs for each > service, but with some level of common structure (still TBD I think - it's > basically a plugin architecture client side for passing config from the > core module to each "plugin" at startup) > > On the server side storage engine side, my ask is that you look at ceph > and gluster as potential storage engines - this would help advance the 5.x > integration objectives. I know that the folks on the ops team have looked > at these in quite a bit of detail, so should have some good insights to > share. > > 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 16 October 2017 at 09:57, David Martin wrote: > >> Hi Wojciech, >> >> An object storage sounds like a useful Mobile Service. >> If the service has a docker image that doesn't require special >> privileges, then it should be good for running on OpenShift. >> How it could fit in nicely with the 5.x work is having Mobile >> clients/libraries and examples for different platforms and languages. >> e.g. Java & Kotlin for Android, Swift for iOS, js/browser for Cordova, js >> for React Native. >> >> Are you already decided on GridFS? >> Is there a comparison you have done on different store types? >> >> Have you looked into any kubernetes addons? >> e.g. Minio https://docs.minio.io/ >> >> >> On 15 October 2017 at 18:31, Wojciech Trocki wrote: >> >>> Hi lads >>> >>> I'm representing RainCatcher team. >>> As a team we are planning to work on the functionality that possibly may >>> also exist as MCP service. >>> >>> *Introduction * >>> >>> Ability to store files (large binary data) is really common for the >>> mobile applications. >>> In most of the corporate use cases files cannot be saved on the public >>> storage clouds like ICloud, Google drive etc. >>> Previous versions of RHMAP had unofficial version of the file storage >>> template that was widely used. >>> >>> Adding file storage as service will directly address common problem for >>> most of the *corporate* *mobile* developers. >>> Ability to use file storage service behind Keycloak service may help to >>> validate security use cases. >>> >>> *Technical details:* >>> >>> Service will consist of the server side file server (similar to sync >>> service). >>> Implementation will be delivered in TypeScript. Storage will use GridFS >>> by default, but it will be swappable by using interface. >>> Additionally service will provide client (Cordova for the moment but we >>> may support ReactNative in future) >>> >>> *Is this service useful/interesting for MCP team?* >>> >>> *RainCatcher Community request:* >>> https://www.redhat.com/archives/feedhenry-raincatcher/2017-O >>> ctober/msg00023.html >>> >>> *Context* >>> >>> As a team we need to deliver File/Image storage functionality, but also >>> make sure that it will be usable even outside RainCatcher solution. >>> I have read about and tried MCP for the last couple days and it looks >>> really interesting. >>> I'm working now (in my spare time) on spiking integration for >>> RainCatcher project with MCP. >>> Focusing mostly on using external sync and Keycloak service. >>> As a team we will widely benefit from MPC (it will simplify our >>> OpenShift deployment). >>> Additionally team can upskill in OpenShift and MCP while delivering this >>> service. >>> >>> *Jira epic:* >>> https://issues.jboss.org/browse/RAINCATCH-1346 >>> >>> Regards >>> -- >>> >>> WOJCIECH TROCKI >>> >>> _______________________________________________ >>> Feedhenry-raincatcher mailing list >>> Feedhenry-raincatcher at redhat.com >>> https://www.redhat.com/mailman/listinfo/feedhenry-raincatcher >>> >>> >> >> >> -- >> David Martin >> Red Hat Mobile >> Twitter: @irldavem >> IRC: @irldavem (feedhenry, mobile-internal) >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > -- 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 cbrookes at redhat.com Mon Oct 16 10:07:59 2017 From: cbrookes at redhat.com (Craig Brookes) Date: Mon, 16 Oct 2017 11:07:59 +0100 Subject: [feedhenry-dev] feedhenry-dev Digest, Vol 16, Issue 44 In-Reply-To: References: Message-ID: I also think having file storage would be great. I would strongly recommend doing a spike on minio as pointed out by others as this provides a s3 compatible API on top of your PVs (no need for mongo ) On Mon, Oct 16, 2017 at 11:02 AM, wrote: > Send feedhenry-dev mailing list submissions to > feedhenry-dev at redhat.com > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.redhat.com/mailman/listinfo/feedhenry-dev > or, via email, send a message with subject or body 'help' to > feedhenry-dev-request at redhat.com > > You can reach the person managing the list at > feedhenry-dev-owner at redhat.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of feedhenry-dev digest..." > > > Today's Topics: > > 1. Re: [Feedhenry-raincatcher] [MCP] Proposal for file storage > service (Wojciech Trocki) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 16 Oct 2017 11:02:08 +0100 > From: Wojciech Trocki > To: John Frizelle > Cc: Feedhenry-raincatcher at redhat.com, feedhenry-dev at redhat.com > Subject: Re: [feedhenry-dev] [Feedhenry-raincatcher] [MCP] Proposal > for file storage service > Message-ID: > pGTsh-wA at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Thanks of response > > > 1) Are you already decided on GridFS? > > We will abstract from actual storage, similar how sync abstract from the > database solution. > Gridfs will be just provided as default implementation. We need to have > something that will work outside the box) > > > 2) Is there a comparison you have done on different store types? > > Server side will provide interface so any possible storage can be used. > We trying to focus on resolving file storage (offline sync) problem on the > mobile. > Server side is open and for the moment we may want to use something that is > already available for RainCatcher developers (GridFS) > > > Have you looked into any kubernetes addons? e.g. Minio > https://docs.minio.io/ > > That may be added later as alternative implementation along with other like > NFS, Ceph. > This will fit perfectly to interface we going to build. Target is to get > something out there as spike, while still meeting RainCatcher functional > requirements. > > > How it could fit in nicely with the 5.x work is having Mobile > clients/libraries and examples for different platforms and languages. > > We can provide only Javascript/Cordova initially. ReactNative later. > > On Mon, Oct 16, 2017 at 10:27 AM, John Frizelle > wrote: > > > +1 on a file / object storage service and on Dave's comments around > client > > libs. Under the 5.x model, we are developing stand alone libs for each > > service, but with some level of common structure (still TBD I think - > it's > > basically a plugin architecture client side for passing config from the > > core module to each "plugin" at startup) > > > > On the server side storage engine side, my ask is that you look at ceph > > and gluster as potential storage engines - this would help advance the > 5.x > > integration objectives. I know that the folks on the ops team have looked > > at these in quite a bit of detail, so should have some good insights to > > share. > > > > 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 16 October 2017 at 09:57, David Martin wrote: > > > >> Hi Wojciech, > >> > >> An object storage sounds like a useful Mobile Service. > >> If the service has a docker image that doesn't require special > >> privileges, then it should be good for running on OpenShift. > >> How it could fit in nicely with the 5.x work is having Mobile > >> clients/libraries and examples for different platforms and languages. > >> e.g. Java & Kotlin for Android, Swift for iOS, js/browser for Cordova, > js > >> for React Native. > >> > >> Are you already decided on GridFS? > >> Is there a comparison you have done on different store types? > >> > >> Have you looked into any kubernetes addons? > >> e.g. Minio https://docs.minio.io/ > >> > >> > >> On 15 October 2017 at 18:31, Wojciech Trocki > wrote: > >> > >>> Hi lads > >>> > >>> I'm representing RainCatcher team. > >>> As a team we are planning to work on the functionality that possibly > may > >>> also exist as MCP service. > >>> > >>> *Introduction * > >>> > >>> Ability to store files (large binary data) is really common for the > >>> mobile applications. > >>> In most of the corporate use cases files cannot be saved on the public > >>> storage clouds like ICloud, Google drive etc. > >>> Previous versions of RHMAP had unofficial version of the file storage > >>> template that was widely used. > >>> > >>> Adding file storage as service will directly address common problem for > >>> most of the *corporate* *mobile* developers. > >>> Ability to use file storage service behind Keycloak service may help to > >>> validate security use cases. > >>> > >>> *Technical details:* > >>> > >>> Service will consist of the server side file server (similar to sync > >>> service). > >>> Implementation will be delivered in TypeScript. Storage will use GridFS > >>> by default, but it will be swappable by using interface. > >>> Additionally service will provide client (Cordova for the moment but we > >>> may support ReactNative in future) > >>> > >>> *Is this service useful/interesting for MCP team?* > >>> > >>> *RainCatcher Community request:* > >>> https://www.redhat.com/archives/feedhenry-raincatcher/2017-O > >>> ctober/msg00023.html > >>> > >>> *Context* > >>> > >>> As a team we need to deliver File/Image storage functionality, but also > >>> make sure that it will be usable even outside RainCatcher solution. > >>> I have read about and tried MCP for the last couple days and it looks > >>> really interesting. > >>> I'm working now (in my spare time) on spiking integration for > >>> RainCatcher project with MCP. > >>> Focusing mostly on using external sync and Keycloak service. > >>> As a team we will widely benefit from MPC (it will simplify our > >>> OpenShift deployment). > >>> Additionally team can upskill in OpenShift and MCP while delivering > this > >>> service. > >>> > >>> *Jira epic:* > >>> https://issues.jboss.org/browse/RAINCATCH-1346 > >>> > >>> Regards > >>> -- > >>> > >>> WOJCIECH TROCKI > >>> > >>> _______________________________________________ > >>> Feedhenry-raincatcher mailing list > >>> Feedhenry-raincatcher at redhat.com > >>> https://www.redhat.com/mailman/listinfo/feedhenry-raincatcher > >>> > >>> > >> > >> > >> -- > >> David Martin > >> Red Hat Mobile > >> Twitter: @irldavem > >> IRC: @irldavem (feedhenry, mobile-internal) > >> > >> _______________________________________________ > >> feedhenry-dev mailing list > >> feedhenry-dev at redhat.com > >> https://www.redhat.com/mailman/listinfo/feedhenry-dev > >> > >> > > > > > -- > > WOJCIECH TROCKI > > Red Hat Mobile > > IM: wtrocki > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: attachments/20171016/d14fe871/attachment.html> > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: logo.png > Type: image/png > Size: 11472 bytes > Desc: not available > URL: attachments/20171016/d14fe871/attachment.png> > > ------------------------------ > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > > End of feedhenry-dev Digest, Vol 16, Issue 44 > ********************************************* > -- Craig Brookes RHMAP @maleck13 Github -------------- next part -------------- An HTML attachment was scrubbed... URL: From wtrocki at redhat.com Mon Oct 16 10:50:58 2017 From: wtrocki at redhat.com (Wojciech Trocki) Date: Mon, 16 Oct 2017 11:50:58 +0100 Subject: [feedhenry-dev] feedhenry-dev Digest, Vol 16, Issue 44 In-Reply-To: References: Message-ID: I have done quick spike on minio and I think that we should support that by default. In fact support for it will be mostly documentation and thin wrapper for our interface As we are upstream solution we do not need to care about productization or additional impact of using another service like minio. This is really good example where community and open discussion works! Thank you so much. >From RainCatcher point of view we still need GridFS as it will be available by default without any additional deployment etc. Regards On Mon, Oct 16, 2017 at 11:07 AM, Craig Brookes wrote: > I also think having file storage would be great. I would strongly > recommend doing a spike on minio as pointed out by others as this provides > a s3 compatible API on top of your PVs (no need for mongo ) > > On Mon, Oct 16, 2017 at 11:02 AM, > wrote: > >> Send feedhenry-dev mailing list submissions to >> feedhenry-dev at redhat.com >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> or, via email, send a message with subject or body 'help' to >> feedhenry-dev-request at redhat.com >> >> You can reach the person managing the list at >> feedhenry-dev-owner at redhat.com >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of feedhenry-dev digest..." >> >> >> Today's Topics: >> >> 1. Re: [Feedhenry-raincatcher] [MCP] Proposal for file storage >> service (Wojciech Trocki) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Mon, 16 Oct 2017 11:02:08 +0100 >> From: Wojciech Trocki >> To: John Frizelle >> Cc: Feedhenry-raincatcher at redhat.com, feedhenry-dev at redhat.com >> Subject: Re: [feedhenry-dev] [Feedhenry-raincatcher] [MCP] Proposal >> for file storage service >> Message-ID: >> > gmail.com> >> Content-Type: text/plain; charset="utf-8" >> >> Thanks of response >> >> > 1) Are you already decided on GridFS? >> >> We will abstract from actual storage, similar how sync abstract from the >> database solution. >> Gridfs will be just provided as default implementation. We need to have >> something that will work outside the box) >> >> > 2) Is there a comparison you have done on different store types? >> >> Server side will provide interface so any possible storage can be used. >> We trying to focus on resolving file storage (offline sync) problem on the >> mobile. >> Server side is open and for the moment we may want to use something that >> is >> already available for RainCatcher developers (GridFS) >> >> > Have you looked into any kubernetes addons? e.g. Minio >> https://docs.minio.io/ >> >> That may be added later as alternative implementation along with other >> like >> NFS, Ceph. >> This will fit perfectly to interface we going to build. Target is to get >> something out there as spike, while still meeting RainCatcher functional >> requirements. >> >> > How it could fit in nicely with the 5.x work is having Mobile >> clients/libraries and examples for different platforms and languages. >> >> We can provide only Javascript/Cordova initially. ReactNative later. >> >> On Mon, Oct 16, 2017 at 10:27 AM, John Frizelle >> wrote: >> >> > +1 on a file / object storage service and on Dave's comments around >> client >> > libs. Under the 5.x model, we are developing stand alone libs for each >> > service, but with some level of common structure (still TBD I think - >> it's >> > basically a plugin architecture client side for passing config from the >> > core module to each "plugin" at startup) >> > >> > On the server side storage engine side, my ask is that you look at ceph >> > and gluster as potential storage engines - this would help advance the >> 5.x >> > integration objectives. I know that the folks on the ops team have >> looked >> > at these in quite a bit of detail, so should have some good insights to >> > share. >> > >> > 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 16 October 2017 at 09:57, David Martin wrote: >> > >> >> Hi Wojciech, >> >> >> >> An object storage sounds like a useful Mobile Service. >> >> If the service has a docker image that doesn't require special >> >> privileges, then it should be good for running on OpenShift. >> >> How it could fit in nicely with the 5.x work is having Mobile >> >> clients/libraries and examples for different platforms and languages. >> >> e.g. Java & Kotlin for Android, Swift for iOS, js/browser for Cordova, >> js >> >> for React Native. >> >> >> >> Are you already decided on GridFS? >> >> Is there a comparison you have done on different store types? >> >> >> >> Have you looked into any kubernetes addons? >> >> e.g. Minio https://docs.minio.io/ >> >> >> >> >> >> On 15 October 2017 at 18:31, Wojciech Trocki >> wrote: >> >> >> >>> Hi lads >> >>> >> >>> I'm representing RainCatcher team. > > >> >>> As a team we are planning to work on the functionality that possibly >> may >> >>> also exist as MCP service. >> >>> >> >>> *Introduction * >> >>> >> >>> Ability to store files (large binary data) is really common for the >> >>> mobile applications. >> >>> In most of the corporate use cases files cannot be saved on the public >> >>> storage clouds like ICloud, Google drive etc. >> >>> Previous versions of RHMAP had unofficial version of the file storage >> >>> template that was widely used. >> >>> >> >>> Adding file storage as service will directly address common problem >> for >> >>> most of the *corporate* *mobile* developers. >> >>> Ability to use file storage service behind Keycloak service may help >> to >> >>> validate security use cases. >> >>> >> >>> *Technical details:* >> >>> >> >>> Service will consist of the server side file server (similar to sync >> >>> service). >> >>> Implementation will be delivered in TypeScript. Storage will use >> GridFS >> >>> by default, but it will be swappable by using interface. >> >>> Additionally service will provide client (Cordova for the moment but >> we >> >>> may support ReactNative in future) >> >>> >> >>> *Is this service useful/interesting for MCP team?* >> >>> >> >>> *RainCatcher Community request:* >> >>> https://www.redhat.com/archives/feedhenry-raincatcher/2017-O >> >>> ctober/msg00023.html >> >>> >> >>> *Context* >> >>> >> >>> As a team we need to deliver File/Image storage functionality, but >> also >> >>> make sure that it will be usable even outside RainCatcher solution. >> >>> I have read about and tried MCP for the last couple days and it looks >> >>> really interesting. >> >>> I'm working now (in my spare time) on spiking integration for >> >>> RainCatcher project with MCP. >> >>> Focusing mostly on using external sync and Keycloak service. >> >>> As a team we will widely benefit from MPC (it will simplify our >> >>> OpenShift deployment). >> >>> Additionally team can upskill in OpenShift and MCP while delivering >> this >> >>> service. >> >>> >> >>> *Jira epic:* >> >>> https://issues.jboss.org/browse/RAINCATCH-1346 >> >>> >> >>> Regards >> >>> -- >> >>> >> >>> WOJCIECH TROCKI >> >>> >> >>> _______________________________________________ >> >>> Feedhenry-raincatcher mailing list >> >>> Feedhenry-raincatcher at redhat.com >> >>> https://www.redhat.com/mailman/listinfo/feedhenry-raincatcher >> >>> >> >>> >> >> >> >> >> >> -- >> >> David Martin >> >> Red Hat Mobile >> >> Twitter: @irldavem >> >> IRC: @irldavem (feedhenry, mobile-internal) >> >> >> >> _______________________________________________ >> >> feedhenry-dev mailing list >> >> feedhenry-dev at redhat.com >> >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> >> >> >> > >> >> >> -- >> >> WOJCIECH TROCKI >> >> Red Hat Mobile >> >> IM: wtrocki >> >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: > 20171016/d14fe871/attachment.html> >> -------------- next part -------------- >> A non-text attachment was scrubbed... >> Name: logo.png >> Type: image/png >> Size: 11472 bytes >> Desc: not available >> URL: > 20171016/d14fe871/attachment.png> >> >> ------------------------------ >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> >> End of feedhenry-dev Digest, Vol 16, Issue 44 >> ********************************************* >> > > > > -- > Craig Brookes > RHMAP > @maleck13 Github > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- WOJCIECH TROCKI Red Hat Mobile IM: wtrocki -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmusil at redhat.com Mon Oct 16 11:46:12 2017 From: mmusil at redhat.com (Marek Musil) Date: Mon, 16 Oct 2017 13:46:12 +0200 Subject: [feedhenry-dev] Congratulating Summers on 5 great years at Red Hat In-Reply-To: References: Message-ID: Congrats Summers! Marek Musil Intern, Mobile QE Red Hat Mobile Application Platform mmusil at redhat.com @redhatway @redhatinc @redhatsnaps 2017-10-11 10:41 GMT+02:00 Brian Dooley : > Congrats Summers. > > > On 11 October 2017 at 00:50, Craig Robinson wrote: > >> Congratulations Summers. ? >> >> >> "if you didn't write it down, it didn't happen" - Clifford Stoll >> >> CRAIG ROBINSON >> >> SENIOR CLOUD OPERATIONS ENGINEER, RED HAT MOBILE >> >> Red Hat QLD >> >> 193 North Quay, BRISBANE, QLD, Australia >> >> >> crarobin at redhat.com M: +61-431-913-345 >> IM: crarobin TZ: UTC+10 >> >> >> >> On 11 October 2017 at 03:04, Evan Shortiss wrote: >> >>> Congrats Summers! >>> >>> On Tue, Oct 10, 2017 at 9:01 AM, Summers Pittman >>> wrote: >>> >>>> Thanks for all of the kudos guys, You are a blast to work with. >>>> >>>> Here's to five more. >>>> >>>> And for cake, here's a group project I was in for college in 2004 : >>>> https://github.com/secondsun/albumserver. Take a look at this >>>> and >>>> this >>>> if >>>> you want to see how students thought client/server protocols worked 13 >>>> years ago. >>>> >>>> >>>> >>>> On Tue, Oct 10, 2017 at 7:34 AM, Erik Jan de Wit >>>> wrote: >>>> >>>>> Congrats Summers! >>>>> >>>>> On Tue, Oct 10, 2017 at 12:42 PM, Jason Madigan >>>>> wrote: >>>>> >>>>>> Congrats Summers! >>>>>> >>>>>> On Mon, Oct 9, 2017 at 9:30 AM, Leigh Griffin >>>>>> wrote: >>>>>> >>>>>>> Hi everyone, >>>>>>> >>>>>>> Yesterday Summers marked his 5th anniversary in Red Hat. Summers has >>>>>>> led the charge on our Open Source efforts for such a long time now that >>>>>>> people default to him for advice and guidance on all things Open Source. He >>>>>>> has helped transition the entire Mobile team towards a more Open mentality >>>>>>> and his work in the SDK team, where he serves as an Android expert, and >>>>>>> recently in the Mobile.next work is helping to bring our next generation >>>>>>> offering to fruition. >>>>>>> >>>>>>> Summers, congratulations on this immense milestone and wishing you >>>>>>> the best for the next 5 years. If you could join me in congratulating >>>>>>> Summers on this great achievement, ideally off list. >>>>>>> >>>>>>> Thanks, >>>>>>> Leigh >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> LEIGH GRIFFIN >>>>>>> >>>>>>> ENGINEERING MANAGER, MOBILE >>>>>>> >>>>>>> Red Hat Ireland >>>>>>> >>>>>>> Communications House, Cork Road >>>>>>> >>>>>>> Waterford City, Ireland X91NY33 >>>>>>> >>>>>>> lgriffin at redhat.com M: +353877545162 IM: lgriffin >>>>>>> >>>>>>> TRIED. TESTED. TRUSTED. >>>>>>> >>>>>>> @redhatway @redhatinc >>>>>>> @redhatsnaps >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Jason Madigan >>>>>> Engineering Manager, Red Hat Mobile >>>>>> >>>>>> _______________________________________________ >>>>>> feedhenry-dev mailing list >>>>>> feedhenry-dev at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Cheers, >>>>> Erik Jan >>>>> >>>> >>>> >>> >>> >>> -- >>> >>> EVAN SHORTISS >>> >>> MOBILE PRACTICE ARCHITECT, RED HAT MOBILE >>> >>> Los Angeles, USA >>> >>> evan.shortiss at redhat.com M: +1-781-354-2834 >>> >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbrookes at redhat.com Mon Oct 16 12:29:27 2017 From: pbrookes at redhat.com (Phil Brookes) Date: Mon, 16 Oct 2017 13:29:27 +0100 Subject: [feedhenry-dev] Update to workflow for APB development In-Reply-To: References: Message-ID: Hey Guys, Just wanted to update this conversation and mention that I have updated the docs in the repo now: https://github.com/feedhenry/mcp-standalone#developing-apbs-locally Let me know if you have any questions or suggestions for improvements! Regards, Phil. ? On Wed, Oct 11, 2017 at 4:30 PM, David Martin wrote: > Hey Phile, > I'd say a section in the local development section of the README is a > reasonable place to put this info https://github.com/feedhenry/ > mcp-standalone#local-development > > e.g. 'Developing APBs locally' > > On 11 October 2017 at 10:01, John Frizelle wrote: > >> Hi Phil, >> >> Thanks for the info. >> >> I was not really asking how to do it, but more so if we are maintaining >> docs anywhere that people can refer to for information such as this. >> >> It's a wider question than just this specific HOW TO, so anyone else >> working on 5.x feel free to chime in. >> >> 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 11 October 2017 at 09:27, Phil Brookes wrote: >> >>> Hey John, >>> >>> For pointing the oc cluster at your local docker, that is done from the >>> installer directory of the mcp-standalone cluster: >>> >>> ansible-playbook playbook.yml -e "dockerhub_username=" -e "dockerhub_password=" -e "dockerhub_org=" --ask-become-pass >>> >>> To move the images you need into your own org, you could do something >>> like: >>> >>> for image in aerogear-digger-apb android-app-apb cordova-app-apb ios-app-apb 3scale-apb keycloak-apb; do docker pull docker.io/feedhenry/$image:latest; docker tag docker.io/feedhenry/$image:latest >>> ?/$image:latest; docker push /$image:latest; done >>> ? >>> >>> There might be a way to improve this (if we could pull the name of all >>> the *-apbs from the docker repo that would be ideal), but this will work >>> for now.? >>> >>> Let me know if you have any thoughts. >>> Phil. >>> ? >>> >>> On Tue, Oct 10, 2017 at 9:01 PM, John Frizelle >>> wrote: >>> >>>> Hi Phil, >>>> >>>> Thanks for the mail & agree with the suggestions. >>>> >>>> Are there any docs available that detail how to "point the ASB of your >>>> local oc cluster at your own docker org and push a copy of any APBs you >>>> wish to use into that org from the feedhenry org"? >>>> >>>> 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 10 October 2017 at 15:55, Phil Brookes wrote: >>>> >>>>> Hello Everyone, >>>>> >>>>> The current development workflow for APB?s is to run a local oc >>>>> cluster with the ASB scanning the feedhenry docker org for APB images. Then >>>>> pushing our development images to the feedhenry repo to test them. >>>>> >>>>> As more developers start using these images we increase the >>>>> possibility that they will pull a broken development image which could lead >>>>> to a pretty significant waste of developer time trying to identify the >>>>> problem and could also reduce developers trust in the feedhenry APB images. >>>>> >>>>> To address this it is now only possible to update the APB images in >>>>> the feedhenry org via a merged PR to the master branch of that images >>>>> github repo. >>>>> >>>>> To develop your own changes to an APB you should instead point the ASB >>>>> of your local oc cluster at your own docker org and push a copy of any APBs >>>>> you wish to use into that org from the feedhenry org. When building >>>>> experimental APB images you should update the image in that APB?s >>>>> apb.yml file, and use make DOCKERORG= to build and push the >>>>> development APB image. >>>>> >>>>> I will be updating the ansible installer in the mcp-standalone repo to >>>>> automatically pull the APB images from feedhenry and push them into the >>>>> specified dockerorg in the near future, so we have less manual work to do. >>>>> >>>>> Any questions or concerns, please let me know. >>>>> >>>>> Thanks, >>>>> Phil. >>>>> ? >>>>> >>>>> _______________________________________________ >>>>> feedhenry-dev mailing list >>>>> feedhenry-dev at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>>> >>>>> >>>> >>> >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > > -- > David Martin > Red Hat Mobile > Twitter: @irldavem > IRC: @irldavem (feedhenry, mobile-internal) > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 11472 bytes Desc: not available URL: From supittma at redhat.com Mon Oct 16 14:02:18 2017 From: supittma at redhat.com (Summers Pittman) Date: Mon, 16 Oct 2017 10:02:18 -0400 Subject: [feedhenry-dev] Demo : MCP Plugin for Android https edition Message-ID: A few weeks ago I wrote a POC plugin for gradle that manages the mcp configuration for you app. I've "enhanced" that plugin to configure the Android app to handle Self Signed certificates correctly. Here is a demo where I go into more detail : https://www.youtube.com/watch?v=GVexDvcvofo Thoughts, Questions, etc? I'm interested in if we want to make a repo for it under the feedhenry organization for the POC work. Summers -------------- next part -------------- An HTML attachment was scrubbed... URL: From davmarti at redhat.com Tue Oct 17 08:04:00 2017 From: davmarti at redhat.com (David Martin) Date: Tue, 17 Oct 2017 09:04:00 +0100 Subject: [feedhenry-dev] Demo : MCP Plugin for Android https edition In-Reply-To: References: Message-ID: Hey Summers, Thats a nice addition to the plugin that should save some time. As the plugin is geared at the mcp, a repo in the feedhenry org sounds right to me. On 16 October 2017 at 15:02, Summers Pittman wrote: > A few weeks ago I wrote a POC plugin for gradle that manages the mcp > configuration for you app. I've "enhanced" that plugin to configure the > Android app to handle Self Signed certificates correctly. > > Here is a demo where I go into more detail : https://www.youtube.com/ > watch?v=GVexDvcvofo > > Thoughts, Questions, etc? > > I'm interested in if we want to make a repo for it under the feedhenry > organization for the POC work. > > Summers > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Tue Oct 17 08:07:50 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Tue, 17 Oct 2017 10:07:50 +0200 Subject: [feedhenry-dev] Demo : MCP Plugin for Android https edition In-Reply-To: References: Message-ID: It would be also nice to tweet that... but the https://twitter.com/feedhenry account looks pretty much 'dead' On Tue, Oct 17, 2017 at 10:04 AM, David Martin wrote: > Hey Summers, > > Thats a nice addition to the plugin that should save some time. > > As the plugin is geared at the mcp, a repo in the feedhenry org sounds > right to me. > > On 16 October 2017 at 15:02, Summers Pittman wrote: > >> A few weeks ago I wrote a POC plugin for gradle that manages the mcp >> configuration for you app. I've "enhanced" that plugin to configure the >> Android app to handle Self Signed certificates correctly. >> >> Here is a demo where I go into more detail : https://www.youtube.com/watc >> h?v=GVexDvcvofo >> >> Thoughts, Questions, etc? >> >> I'm interested in if we want to make a repo for it under the feedhenry >> organization for the POC work. >> >> Summers >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > > -- > David Martin > Red Hat Mobile > Twitter: @irldavem > IRC: @irldavem (feedhenry, mobile-internal) > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfrizell at redhat.com Tue Oct 17 08:22:36 2017 From: jfrizell at redhat.com (John Frizelle) Date: Tue, 17 Oct 2017 09:22:36 +0100 Subject: [feedhenry-dev] Demo : MCP Plugin for Android https edition In-Reply-To: References: Message-ID: Looks really cool summers and a very useful feature. These are the kinds of handy time saving things we want to be adding lots of :-) -- 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 17 October 2017 at 09:04, David Martin wrote: > Hey Summers, > > Thats a nice addition to the plugin that should save some time. > > As the plugin is geared at the mcp, a repo in the feedhenry org sounds > right to me. > > On 16 October 2017 at 15:02, Summers Pittman wrote: > >> A few weeks ago I wrote a POC plugin for gradle that manages the mcp >> configuration for you app. I've "enhanced" that plugin to configure the >> Android app to handle Self Signed certificates correctly. >> >> Here is a demo where I go into more detail : https://www.youtube.com/watc >> h?v=GVexDvcvofo >> >> Thoughts, Questions, etc? >> >> I'm interested in if we want to make a repo for it under the feedhenry >> organization for the POC work. >> >> Summers >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > > -- > David Martin > Red Hat Mobile > Twitter: @irldavem > IRC: @irldavem (feedhenry, mobile-internal) > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 11472 bytes Desc: not available URL: From jmadigan at redhat.com Tue Oct 17 14:23:39 2017 From: jmadigan at redhat.com (Jason Madigan) Date: Tue, 17 Oct 2017 15:23:39 +0100 Subject: [feedhenry-dev] Update to workflow for APB development In-Reply-To: References: Message-ID: Think this was mentioned on IRC already, but I think it could be worth moving this into a `docs/` folder doc (and linked from the README) instead. I'd imagine we'll start to add more and more docs, so good to have a handy home in the repo? On Mon, Oct 16, 2017 at 1:29 PM, Phil Brookes wrote: > Hey Guys, > > Just wanted to update this conversation and mention that I have updated > the docs in the repo now: > https://github.com/feedhenry/mcp-standalone#developing-apbs-locally > > Let me know if you have any questions or suggestions for improvements! > > Regards, > Phil. > ? > > On Wed, Oct 11, 2017 at 4:30 PM, David Martin wrote: > >> Hey Phile, >> I'd say a section in the local development section of the README is a >> reasonable place to put this info https://github.com/feedhenry/m >> cp-standalone#local-development >> >> e.g. 'Developing APBs locally' >> >> On 11 October 2017 at 10:01, John Frizelle wrote: >> >>> Hi Phil, >>> >>> Thanks for the info. >>> >>> I was not really asking how to do it, but more so if we are maintaining >>> docs anywhere that people can refer to for information such as this. >>> >>> It's a wider question than just this specific HOW TO, so anyone else >>> working on 5.x feel free to chime in. >>> >>> 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 11 October 2017 at 09:27, Phil Brookes wrote: >>> >>>> Hey John, >>>> >>>> For pointing the oc cluster at your local docker, that is done from the >>>> installer directory of the mcp-standalone cluster: >>>> >>>> ansible-playbook playbook.yml -e "dockerhub_username=" -e "dockerhub_password=" -e "dockerhub_org=" --ask-become-pass >>>> >>>> To move the images you need into your own org, you could do something >>>> like: >>>> >>>> for image in aerogear-digger-apb android-app-apb cordova-app-apb ios-app-apb 3scale-apb keycloak-apb; do docker pull docker.io/feedhenry/$image:latest; docker tag docker.io/feedhenry/$image:latest >>>> ?/$image:latest; docker push /$image:latest; done >>>> ? >>>> >>>> There might be a way to improve this (if we could pull the name of all >>>> the *-apbs from the docker repo that would be ideal), but this will work >>>> for now.? >>>> >>>> Let me know if you have any thoughts. >>>> Phil. >>>> ? >>>> >>>> On Tue, Oct 10, 2017 at 9:01 PM, John Frizelle >>>> wrote: >>>> >>>>> Hi Phil, >>>>> >>>>> Thanks for the mail & agree with the suggestions. >>>>> >>>>> Are there any docs available that detail how to "point the ASB of your >>>>> local oc cluster at your own docker org and push a copy of any APBs you >>>>> wish to use into that org from the feedhenry org"? >>>>> >>>>> 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 10 October 2017 at 15:55, Phil Brookes wrote: >>>>> >>>>>> Hello Everyone, >>>>>> >>>>>> The current development workflow for APB?s is to run a local oc >>>>>> cluster with the ASB scanning the feedhenry docker org for APB images. Then >>>>>> pushing our development images to the feedhenry repo to test them. >>>>>> >>>>>> As more developers start using these images we increase the >>>>>> possibility that they will pull a broken development image which could lead >>>>>> to a pretty significant waste of developer time trying to identify the >>>>>> problem and could also reduce developers trust in the feedhenry APB images. >>>>>> >>>>>> To address this it is now only possible to update the APB images in >>>>>> the feedhenry org via a merged PR to the master branch of that images >>>>>> github repo. >>>>>> >>>>>> To develop your own changes to an APB you should instead point the >>>>>> ASB of your local oc cluster at your own docker org and push a copy of any >>>>>> APBs you wish to use into that org from the feedhenry org. When building >>>>>> experimental APB images you should update the image in that APB?s >>>>>> apb.yml file, and use make DOCKERORG= to build and push the >>>>>> development APB image. >>>>>> >>>>>> I will be updating the ansible installer in the mcp-standalone repo >>>>>> to automatically pull the APB images from feedhenry and push them into the >>>>>> specified dockerorg in the near future, so we have less manual work to do. >>>>>> >>>>>> Any questions or concerns, please let me know. >>>>>> >>>>>> Thanks, >>>>>> Phil. >>>>>> ? >>>>>> >>>>>> _______________________________________________ >>>>>> feedhenry-dev mailing list >>>>>> feedhenry-dev at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>>>> >>>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> feedhenry-dev mailing list >>> feedhenry-dev at redhat.com >>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>> >>> >> >> >> -- >> David Martin >> Red Hat Mobile >> Twitter: @irldavem >> IRC: @irldavem (feedhenry, mobile-internal) >> > > > _______________________________________________ > 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: logo.png Type: image/png Size: 11472 bytes Desc: not available URL: From mwessend at redhat.com Tue Oct 17 14:39:31 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Tue, 17 Oct 2017 16:39:31 +0200 Subject: [feedhenry-dev] Update to workflow for APB development In-Reply-To: References: Message-ID: this, basically, will be in "docs/development' https://gist.github.com/matzew/485e40a54863a9bf51ce5087be078a64 and the stuff from the root's README will just link to that doc On Tue, Oct 17, 2017 at 4:23 PM, Jason Madigan wrote: > Think this was mentioned on IRC already, but I think it could be worth > moving this into a `docs/` folder doc (and linked from the README) instead. > I'd imagine we'll start to add more and more docs, so good to have a handy > home in the repo? > > On Mon, Oct 16, 2017 at 1:29 PM, Phil Brookes wrote: > >> Hey Guys, >> >> Just wanted to update this conversation and mention that I have updated >> the docs in the repo now: >> https://github.com/feedhenry/mcp-standalone#developing-apbs-locally >> >> Let me know if you have any questions or suggestions for improvements! >> >> Regards, >> Phil. >> ? >> >> On Wed, Oct 11, 2017 at 4:30 PM, David Martin >> wrote: >> >>> Hey Phile, >>> I'd say a section in the local development section of the README is a >>> reasonable place to put this info https://github.com/feedhenry/m >>> cp-standalone#local-development >>> >>> e.g. 'Developing APBs locally' >>> >>> On 11 October 2017 at 10:01, John Frizelle wrote: >>> >>>> Hi Phil, >>>> >>>> Thanks for the info. >>>> >>>> I was not really asking how to do it, but more so if we are maintaining >>>> docs anywhere that people can refer to for information such as this. >>>> >>>> It's a wider question than just this specific HOW TO, so anyone else >>>> working on 5.x feel free to chime in. >>>> >>>> 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 11 October 2017 at 09:27, Phil Brookes wrote: >>>> >>>>> Hey John, >>>>> >>>>> For pointing the oc cluster at your local docker, that is done from >>>>> the installer directory of the mcp-standalone cluster: >>>>> >>>>> ansible-playbook playbook.yml -e "dockerhub_username=" -e "dockerhub_password=" -e "dockerhub_org=" --ask-become-pass >>>>> >>>>> To move the images you need into your own org, you could do something >>>>> like: >>>>> >>>>> for image in aerogear-digger-apb android-app-apb cordova-app-apb ios-app-apb 3scale-apb keycloak-apb; do docker pull docker.io/feedhenry/$image:latest; docker tag docker.io/feedhenry/$image:latest >>>>> ?/$image:latest; docker push /$image:latest; done >>>>> ? >>>>> >>>>> There might be a way to improve this (if we could pull the name of all >>>>> the *-apbs from the docker repo that would be ideal), but this will work >>>>> for now.? >>>>> >>>>> Let me know if you have any thoughts. >>>>> Phil. >>>>> ? >>>>> >>>>> On Tue, Oct 10, 2017 at 9:01 PM, John Frizelle >>>>> wrote: >>>>> >>>>>> Hi Phil, >>>>>> >>>>>> Thanks for the mail & agree with the suggestions. >>>>>> >>>>>> Are there any docs available that detail how to "point the ASB of >>>>>> your local oc cluster at your own docker org and push a copy of any APBs >>>>>> you wish to use into that org from the feedhenry org"? >>>>>> >>>>>> 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 10 October 2017 at 15:55, Phil Brookes >>>>>> wrote: >>>>>> >>>>>>> Hello Everyone, >>>>>>> >>>>>>> The current development workflow for APB?s is to run a local oc >>>>>>> cluster with the ASB scanning the feedhenry docker org for APB images. Then >>>>>>> pushing our development images to the feedhenry repo to test them. >>>>>>> >>>>>>> As more developers start using these images we increase the >>>>>>> possibility that they will pull a broken development image which could lead >>>>>>> to a pretty significant waste of developer time trying to identify the >>>>>>> problem and could also reduce developers trust in the feedhenry APB images. >>>>>>> >>>>>>> To address this it is now only possible to update the APB images in >>>>>>> the feedhenry org via a merged PR to the master branch of that images >>>>>>> github repo. >>>>>>> >>>>>>> To develop your own changes to an APB you should instead point the >>>>>>> ASB of your local oc cluster at your own docker org and push a copy of any >>>>>>> APBs you wish to use into that org from the feedhenry org. When building >>>>>>> experimental APB images you should update the image in that APB?s >>>>>>> apb.yml file, and use make DOCKERORG= to build and push >>>>>>> the development APB image. >>>>>>> >>>>>>> I will be updating the ansible installer in the mcp-standalone repo >>>>>>> to automatically pull the APB images from feedhenry and push them into the >>>>>>> specified dockerorg in the near future, so we have less manual work to do. >>>>>>> >>>>>>> Any questions or concerns, please let me know. >>>>>>> >>>>>>> Thanks, >>>>>>> Phil. >>>>>>> ? >>>>>>> >>>>>>> _______________________________________________ >>>>>>> feedhenry-dev mailing list >>>>>>> feedhenry-dev at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> feedhenry-dev mailing list >>>> feedhenry-dev at redhat.com >>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>> >>>> >>> >>> >>> -- >>> David Martin >>> Red Hat Mobile >>> Twitter: @irldavem >>> IRC: @irldavem (feedhenry, mobile-internal) >>> >> >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > > -- > Jason Madigan > Engineering Manager, Red Hat Mobile > > _______________________________________________ > 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 jmadigan at redhat.com Tue Oct 17 16:54:16 2017 From: jmadigan at redhat.com (Jason Madigan) Date: Tue, 17 Oct 2017 17:54:16 +0100 Subject: [feedhenry-dev] Update to workflow for APB development In-Reply-To: References: Message-ID: Ideal, thanks Matthias On Tue, Oct 17, 2017 at 3:39 PM, Matthias Wessendorf wrote: > this, basically, will be in "docs/development' > > https://gist.github.com/matzew/485e40a54863a9bf51ce5087be078a64 > > and the stuff from the root's README will just link to that doc > > On Tue, Oct 17, 2017 at 4:23 PM, Jason Madigan > wrote: > >> Think this was mentioned on IRC already, but I think it could be worth >> moving this into a `docs/` folder doc (and linked from the README) instead. >> I'd imagine we'll start to add more and more docs, so good to have a handy >> home in the repo? >> >> On Mon, Oct 16, 2017 at 1:29 PM, Phil Brookes >> wrote: >> >>> Hey Guys, >>> >>> Just wanted to update this conversation and mention that I have updated >>> the docs in the repo now: >>> https://github.com/feedhenry/mcp-standalone#developing-apbs-locally >>> >>> Let me know if you have any questions or suggestions for improvements! >>> >>> Regards, >>> Phil. >>> ? >>> >>> On Wed, Oct 11, 2017 at 4:30 PM, David Martin >>> wrote: >>> >>>> Hey Phile, >>>> I'd say a section in the local development section of the README is a >>>> reasonable place to put this info https://github.com/feedhenry/m >>>> cp-standalone#local-development >>>> >>>> e.g. 'Developing APBs locally' >>>> >>>> On 11 October 2017 at 10:01, John Frizelle wrote: >>>> >>>>> Hi Phil, >>>>> >>>>> Thanks for the info. >>>>> >>>>> I was not really asking how to do it, but more so if we are >>>>> maintaining docs anywhere that people can refer to for information such as >>>>> this. >>>>> >>>>> It's a wider question than just this specific HOW TO, so anyone else >>>>> working on 5.x feel free to chime in. >>>>> >>>>> 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 11 October 2017 at 09:27, Phil Brookes wrote: >>>>> >>>>>> Hey John, >>>>>> >>>>>> For pointing the oc cluster at your local docker, that is done from >>>>>> the installer directory of the mcp-standalone cluster: >>>>>> >>>>>> ansible-playbook playbook.yml -e "dockerhub_username=" -e "dockerhub_password=" -e "dockerhub_org=" --ask-become-pass >>>>>> >>>>>> To move the images you need into your own org, you could do something >>>>>> like: >>>>>> >>>>>> for image in aerogear-digger-apb android-app-apb cordova-app-apb ios-app-apb 3scale-apb keycloak-apb; do docker pull docker.io/feedhenry/$image:latest; docker tag docker.io/feedhenry/$image:latest >>>>>> ?/$image:latest; docker push /$image:latest; done >>>>>> ? >>>>>> >>>>>> There might be a way to improve this (if we could pull the name of >>>>>> all the *-apbs from the docker repo that would be ideal), but this will >>>>>> work for now.? >>>>>> >>>>>> Let me know if you have any thoughts. >>>>>> Phil. >>>>>> ? >>>>>> >>>>>> On Tue, Oct 10, 2017 at 9:01 PM, John Frizelle >>>>>> wrote: >>>>>> >>>>>>> Hi Phil, >>>>>>> >>>>>>> Thanks for the mail & agree with the suggestions. >>>>>>> >>>>>>> Are there any docs available that detail how to "point the ASB of >>>>>>> your local oc cluster at your own docker org and push a copy of any APBs >>>>>>> you wish to use into that org from the feedhenry org"? >>>>>>> >>>>>>> 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 10 October 2017 at 15:55, Phil Brookes >>>>>>> wrote: >>>>>>> >>>>>>>> Hello Everyone, >>>>>>>> >>>>>>>> The current development workflow for APB?s is to run a local oc >>>>>>>> cluster with the ASB scanning the feedhenry docker org for APB images. Then >>>>>>>> pushing our development images to the feedhenry repo to test them. >>>>>>>> >>>>>>>> As more developers start using these images we increase the >>>>>>>> possibility that they will pull a broken development image which could lead >>>>>>>> to a pretty significant waste of developer time trying to identify the >>>>>>>> problem and could also reduce developers trust in the feedhenry APB images. >>>>>>>> >>>>>>>> To address this it is now only possible to update the APB images in >>>>>>>> the feedhenry org via a merged PR to the master branch of that images >>>>>>>> github repo. >>>>>>>> >>>>>>>> To develop your own changes to an APB you should instead point the >>>>>>>> ASB of your local oc cluster at your own docker org and push a copy of any >>>>>>>> APBs you wish to use into that org from the feedhenry org. When building >>>>>>>> experimental APB images you should update the image in that APB?s >>>>>>>> apb.yml file, and use make DOCKERORG= to build and push >>>>>>>> the development APB image. >>>>>>>> >>>>>>>> I will be updating the ansible installer in the mcp-standalone repo >>>>>>>> to automatically pull the APB images from feedhenry and push them into the >>>>>>>> specified dockerorg in the near future, so we have less manual work to do. >>>>>>>> >>>>>>>> Any questions or concerns, please let me know. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Phil. >>>>>>>> ? >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> feedhenry-dev mailing list >>>>>>>> feedhenry-dev at redhat.com >>>>>>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> feedhenry-dev mailing list >>>>> feedhenry-dev at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>>> >>>>> >>>> >>>> >>>> -- >>>> David Martin >>>> Red Hat Mobile >>>> Twitter: @irldavem >>>> IRC: @irldavem (feedhenry, mobile-internal) >>>> >>> >>> >>> _______________________________________________ >>> feedhenry-dev mailing list >>> feedhenry-dev at redhat.com >>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>> >>> >> >> >> -- >> Jason Madigan >> Engineering Manager, Red Hat Mobile >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > > -- > Project lead AeroGear.org > -- Jason Madigan Engineering Manager, Red Hat Mobile -------------- 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 bsutter at redhat.com Tue Oct 17 18:15:05 2017 From: bsutter at redhat.com (Burr Sutter) Date: 17 Oct 2017 14:15:05 -0400 Subject: [feedhenry-dev] Upcoming Red Hat DevNation Live Tech Talk: Domain Driven Design for Mere Mortals Message-ID: <9f2d863939d941448201b05f4f27fe6c@1795> Read the online version . "Red Hat" Hi RedHat, Join the Red Hat DevNation for an upcoming live session on October 19, 2017. Justin Holmes, senior application architect, presents Domain Driven Design for Mere Mortals. Domain-driven design (DDD) is a proven approach to building software that people love, and that delivers lasting business value. Unfortunately, the way we commonly present DDD in the community has made the subject feel academic and complex. Join this tech talk, where we?ll: *Focus on the surprisingly simple core principles that make DDD so powerful. *How other teams of mere mortals are establishing and maintaining domain-driven design in software projects Speaker: Justin Holmes, senior application architect, Open Innovations Lab, Red Hat Justin Holmes is a passionate consultant who helps teams deliver better software products, faster. He is a fan of methods that lead delivery teams toward shared understanding and technologies that capture that understanding in software. Justin is active in the Behavior Driven Development, Domain Driven Design, and Lean Product Development communities. You can also find him helping customers accelerate their innovative ideas in Red Hat? Open Innovation Labs . Register Now For more information and to view the schedule, click here . We hope you join us! Regards, Burr Sutter The Red Hat Developer Program __________________________________________________________________ [f1]Contact our sales team [f2]Manage your newsletter preferences [f3]Read our privacy policy [f4]Unsubscribe from all Red Hat email "Red Hat" and the "Shadowman" logo are trademarks or registered trademarks of Red Hat, Inc. Linux is a registered trademark of Linus Torvalds. ? 2016 Red Hat, Inc. All rights reserved. 100 East Davie Street Raleigh, NC 27601 [f5][twitter.png] [f6][facebook.png] [f7][redhat.png] References f1. http://www.redhat.com/apps/webform.html?event_type=contact_sales&eid=21 f2. https://www.redhat.com/wapps/ugc/email-subscriptions.html?elqc=241&elq=9f2d863939d941448201b05f4f27fe6c f3. http://www.redhat.com/legal/privacy_statement.html f4. https://www.redhat.com/wapps/ugc/master-unsubscribe.html?elqc=241&elq=9f2d863939d941448201b05f4f27fe6c f5. http://www.twitter.com/redhatnews f6. http://www.facebook.com/pages/Red-Hat/11218770329 f7. http://www.redhat.com/community/?sc_cid=70160000000I9TnAAK -------------- next part -------------- An HTML attachment was scrubbed... URL: From vsazel at redhat.com Thu Oct 19 08:42:30 2017 From: vsazel at redhat.com (Vojtech Sazel) Date: Thu, 19 Oct 2017 10:42:30 +0200 Subject: [feedhenry-dev] MCP on non-RH distros? Message-ID: Hi, did anyone have success with getting it working on Ubuntu/Mint? I seem to be getting error on this step: export DOCKERHUB_USERNAME=""export DOCKERHUB_PASSWORD=""cd installer/ && ansible-playbook playbook.yml -e "dockerhub_username=$DOCKERHUB_USERNAME" -e "dockerhub_password=$DOCKERHUB_PASSWORD" --ask-become-pass It ends with: / TASK [andrewrothstein.unarchive-deps : install common \ \ pkgs...] / ------------------------------------------------------- \ ^__^ \ (oo)\_______ (__)\ )\/\ ||----w | || || ok: [localhost] => (item=unzip) ok: [localhost] => (item=gzip) ok: [localhost] => (item=bzip2) ok: [localhost] => (item=tar) *failed: [localhost] (item=xz) => {"failed": true, "item": "xz", "msg": "No package matching 'xz' is available"}* * to retry, use: --limit @/home/vsazel/go/src/github.com/feedhenry/mcp-standalone/installer/playbook.retry * ____________ < PLAY RECAP > ------------ \ ^__^ \ (oo)\_______ (__)\ )\/\ ||----w | || || localhost : ok=1 changed=0 unreachable=0 failed=1 I think it might be related to that on Ubuntu, packages is named xz-utils. But so far with my low experience with Ansible, I can't fix the error. It seems to be in that andrewrothstein.unarchive-deps module. -- 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: From mwessend at redhat.com Thu Oct 19 11:01:16 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Thu, 19 Oct 2017 13:01:16 +0200 Subject: [feedhenry-dev] MCP on non-RH distros? In-Reply-To: References: Message-ID: never tried on ubuntu ... perhaps... create an xz alias ? :-) On Thu, Oct 19, 2017 at 10:42 AM, Vojtech Sazel wrote: > Hi, > > did anyone have success with getting it working on Ubuntu/Mint? > I seem to be getting error on this step: > > export DOCKERHUB_USERNAME=""export DOCKERHUB_PASSWORD=""cd installer/ && ansible-playbook playbook.yml -e "dockerhub_username=$DOCKERHUB_USERNAME" -e "dockerhub_password=$DOCKERHUB_PASSWORD" --ask-become-pass > > > It ends with: > / TASK [andrewrothstein.unarchive-deps : install common \ > \ pkgs...] / > ------------------------------------------------------- > \ ^__^ > \ (oo)\_______ > (__)\ )\/\ > ||----w | > || || > > ok: [localhost] => (item=unzip) > ok: [localhost] => (item=gzip) > ok: [localhost] => (item=bzip2) > ok: [localhost] => (item=tar) > *failed: [localhost] (item=xz) => {"failed": true, "item": "xz", "msg": > "No package matching 'xz' is available"}* > * to retry, use: --limit > @/home/vsazel/go/src/github.com/feedhenry/mcp-standalone/installer/playbook.retry > * > ____________ > < PLAY RECAP > > ------------ > \ ^__^ > \ (oo)\_______ > (__)\ )\/\ > ||----w | > || || > > localhost : ok=1 changed=0 unreachable=0 > failed=1 > > I think it might be related to that on Ubuntu, packages is named xz-utils. > But so far with my low experience with Ansible, I can't fix the error. It > seems to be in that andrewrothstein.unarchive-deps module. > > -- > > 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 > > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From davmarti at redhat.com Thu Oct 19 16:39:58 2017 From: davmarti at redhat.com (David Martin) Date: Thu, 19 Oct 2017 17:39:58 +0100 Subject: [feedhenry-dev] MCP on non-RH distros? In-Reply-To: References: Message-ID: I have only tried on Fedora Linux. I'm not sure how far you'll get with Ubuntu. The Origin docs say "You can quickly get OpenShift Origin running in a container using images from Docker Hub on a Linux system. This method is supported on Fedora, CentOS, and Red Hat Enterprise Linux (RHEL) hosts only." https://docs.openshift.org/latest/getting_started/administrators.html As we're using the container method via 'oc cluster up', I believe this applies On 19 October 2017 at 12:01, Matthias Wessendorf wrote: > never tried on ubuntu ... perhaps... create an xz alias ? :-) > > On Thu, Oct 19, 2017 at 10:42 AM, Vojtech Sazel wrote: > >> Hi, >> >> did anyone have success with getting it working on Ubuntu/Mint? >> I seem to be getting error on this step: >> >> export DOCKERHUB_USERNAME=""export DOCKERHUB_PASSWORD=""cd installer/ && ansible-playbook playbook.yml -e "dockerhub_username=$DOCKERHUB_USERNAME" -e "dockerhub_password=$DOCKERHUB_PASSWORD" --ask-become-pass >> >> >> It ends with: >> / TASK [andrewrothstein.unarchive-deps : install common \ >> \ pkgs...] / >> ------------------------------------------------------- >> \ ^__^ >> \ (oo)\_______ >> (__)\ )\/\ >> ||----w | >> || || >> >> ok: [localhost] => (item=unzip) >> ok: [localhost] => (item=gzip) >> ok: [localhost] => (item=bzip2) >> ok: [localhost] => (item=tar) >> *failed: [localhost] (item=xz) => {"failed": true, "item": "xz", "msg": >> "No package matching 'xz' is available"}* >> * to retry, use: --limit >> @/home/vsazel/go/src/github.com/feedhenry/mcp-standalone/installer/playbook.retry >> * >> ____________ >> < PLAY RECAP > >> ------------ >> \ ^__^ >> \ (oo)\_______ >> (__)\ )\/\ >> ||----w | >> || || >> >> localhost : ok=1 changed=0 unreachable=0 >> failed=1 >> >> I think it might be related to that on Ubuntu, packages is named >> xz-utils. But so far with my low experience with Ansible, I can't fix the >> error. It seems to be in that andrewrothstein.unarchive-deps module. >> >> -- >> >> 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 >> >> > > > -- > Project lead AeroGear.org > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From wtrocki at redhat.com Mon Oct 23 09:02:12 2017 From: wtrocki at redhat.com (Wojciech Trocki) Date: Mon, 23 Oct 2017 10:02:12 +0100 Subject: [feedhenry-dev] [Feedhenry-raincatcher] Ability to subscribe to more than one event at a time In-Reply-To: References: Message-ID: Hi Michael There are two side effects in Feedhenry sync that are important for your cases. 1) Line that was forwarded to us is responsible for triggering notification. If you have specific notification then global notification will not be triggered. https://github.com/feedhenry/fh-sync-js/blob/6392b02813b09e252b1e7537249ce50dd8f5e5cb/src/sync-client.js#L360 IMHO both should be triggered as this is how most of the event implementation works. This is trivial fix, but it may cause some backwards compatibility problems. 2) When you register notifications for specific datasets previous notifier will be removed https://github.com/feedhenry/fh-sync-js/blob/6392b02813b09e252b1e7537249ce50dd8f5e5cb/src/sync-client.js#L118 IMHO this may relay on something like event emitter, but that will require a lots of changes in the library. *With that in mind - we cannot have more than 1 notification handler per dataset* RainCatcher team can provide wrapper for that method in RainCatcher that will allow us to notify more than one listener per dataset. Sending to feedhenry-dev for other opinions, before executing any actions. On Fri, Oct 20, 2017 at 6:07 PM, Michael Hearne wrote: > There is a bug in sync where we cannot subscribe to events more than once > at a time. The following fails: > > workorderService.subscribeToDatasetUpdates(() => { > ... > }); > > https://github.com/feedhenry/fh-sync-js/blob/6392b02813b09e2 > 52b1e7537249ce50dd8f5e5cb/src/sync-client.js#L360-L361 > > -- > > MICHAEL HEARNE > > MOBILE CONSULTANT > > mhearne at redhat.com > > @m ickhearne | IM: #mhearne > > _______________________________________________ > Feedhenry-raincatcher mailing list > Feedhenry-raincatcher at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-raincatcher > > -- WOJCIECH TROCKI Red Hat Mobile IM: wtrocki -------------- next part -------------- An HTML attachment was scrubbed... URL: From weil at redhat.com Mon Oct 23 11:10:47 2017 From: weil at redhat.com (Wei Li) Date: Mon, 23 Oct 2017 12:10:47 +0100 Subject: [feedhenry-dev] [Feedhenry-raincatcher] Ability to subscribe to more than one event at a time In-Reply-To: References: Message-ID: +1 on using the event emitter. It should be the default implementation for the js sync client library. I also think this should be fixed inside the sync framework itself. For the js client, one options is that we could init an event emitter for each dataset. Then the event emitter can be used to manage the events for the bound dataset. I think no changes to the sync API required to support this. On Mon, Oct 23, 2017 at 10:02 AM, Wojciech Trocki wrote: > Hi Michael > > There are two side effects in Feedhenry sync that are important for your > cases. > > 1) Line that was forwarded to us is responsible for triggering > notification. > If you have specific notification then global notification will not be > triggered. > > https://github.com/feedhenry/fh-sync-js/blob/ > 6392b02813b09e252b1e7537249ce50dd8f5e5cb/src/sync-client.js#L360 > > IMHO both should be triggered as this is how most of the event > implementation works. > This is trivial fix, but it may cause some backwards compatibility > problems. > > 2) When you register notifications for specific datasets previous notifier > will be removed > https://github.com/feedhenry/fh-sync-js/blob/ > 6392b02813b09e252b1e7537249ce50dd8f5e5cb/src/sync-client.js#L118 > > IMHO this may relay on something like event emitter, but that will require > a lots of changes in the library. > > *With that in mind - we cannot have more than 1 notification handler per > dataset* > RainCatcher team can provide wrapper for that method in RainCatcher that > will allow us to notify more than one listener per dataset. > > Sending to feedhenry-dev for other opinions, before executing any actions. > > > On Fri, Oct 20, 2017 at 6:07 PM, Michael Hearne > wrote: > >> There is a bug in sync where we cannot subscribe to events more than once >> at a time. The following fails: >> >> workorderService.subscribeToDatasetUpdates(() => { >> ... >> }); >> >> https://github.com/feedhenry/fh-sync-js/blob/6392b02813b09e2 >> 52b1e7537249ce50dd8f5e5cb/src/sync-client.js#L360-L361 >> >> -- >> >> MICHAEL HEARNE >> >> MOBILE CONSULTANT >> >> mhearne at redhat.com >> >> @m ickhearne | IM: #mhearne >> >> _______________________________________________ >> Feedhenry-raincatcher mailing list >> Feedhenry-raincatcher at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-raincatcher >> >> > > > -- > > WOJCIECH TROCKI > > Red Hat Mobile > > IM: wtrocki > > > _______________________________________________ > 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 Tue Oct 24 08:37:20 2017 From: wtrocki at redhat.com (Wojciech Trocki) Date: Tue, 24 Oct 2017 09:37:20 +0100 Subject: [feedhenry-dev] [Feedhenry-raincatcher] Ability to subscribe to more than one event at a time In-Reply-To: References: Message-ID: Great to have agreement! We can do that change directly in sync without compromising it's api. Created ticket for that in RainCatcher project. On Mon, Oct 23, 2017 at 12:10 PM, Wei Li wrote: > +1 on using the event emitter. It should be the default implementation for > the js sync client library. > > I also think this should be fixed inside the sync framework itself. > > For the js client, one options is that we could init an event emitter for > each dataset. Then the event emitter can be used to manage the events for > the bound dataset. I think no changes to the sync API required to support > this. > > On Mon, Oct 23, 2017 at 10:02 AM, Wojciech Trocki > wrote: > >> Hi Michael >> >> There are two side effects in Feedhenry sync that are important for your >> cases. >> >> 1) Line that was forwarded to us is responsible for triggering >> notification. >> If you have specific notification then global notification will not be >> triggered. >> >> https://github.com/feedhenry/fh-sync-js/blob/6392b02813b09e2 >> 52b1e7537249ce50dd8f5e5cb/src/sync-client.js#L360 >> >> IMHO both should be triggered as this is how most of the event >> implementation works. >> This is trivial fix, but it may cause some backwards compatibility >> problems. >> >> 2) When you register notifications for specific datasets previous >> notifier will be removed >> https://github.com/feedhenry/fh-sync-js/blob/6392b02813b09e2 >> 52b1e7537249ce50dd8f5e5cb/src/sync-client.js#L118 >> >> IMHO this may relay on something like event emitter, but that will >> require a lots of changes in the library. >> >> *With that in mind - we cannot have more than 1 notification handler per >> dataset* >> RainCatcher team can provide wrapper for that method in RainCatcher that >> will allow us to notify more than one listener per dataset. >> >> Sending to feedhenry-dev for other opinions, before executing any >> actions. >> >> >> On Fri, Oct 20, 2017 at 6:07 PM, Michael Hearne >> wrote: >> >>> There is a bug in sync where we cannot subscribe to events more than >>> once at a time. The following fails: >>> >>> workorderService.subscribeToDatasetUpdates(() => { >>> ... >>> }); >>> >>> https://github.com/feedhenry/fh-sync-js/blob/6392b02813b09e2 >>> 52b1e7537249ce50dd8f5e5cb/src/sync-client.js#L360-L361 >>> >>> -- >>> >>> MICHAEL HEARNE >>> >>> MOBILE CONSULTANT >>> >>> mhearne at redhat.com >>> >>> @m ickhearne | IM: #mhearne >>> >>> _______________________________________________ >>> Feedhenry-raincatcher mailing list >>> Feedhenry-raincatcher at redhat.com >>> https://www.redhat.com/mailman/listinfo/feedhenry-raincatcher >>> >>> >> >> >> -- >> >> WOJCIECH TROCKI >> >> Red Hat Mobile >> >> IM: wtrocki >> >> >> _______________________________________________ >> 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 Wed Oct 25 08:18:45 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Wed, 25 Oct 2017 10:18:45 +0200 Subject: [feedhenry-dev] RFC: Release process for the Ansible Playbook Bundles (APBs) Message-ID: Hi, we have some independent APBs, like for 3scale, Keycloak or AeroGear Digger, and those live in their own GH repository. We recently have converted their matching Dockerhub repositories to be build automatically once changes on the source code occur: * master changes (e.g. PRs got merged) -> triggers a new build of the "latest" docker image * Tags: pushing a new tag in github triggers a build of a "tagged" docker image. Current convention: GH tag == Docker tag (e.g. a version like "0.0.5" is same in both worlds) How should we run releases for these APB repos ? Usually after changes did land on master, and there is a *demand* for a release, the last commit is used, and a tag is created and pushed to github. This also - as stated above - does release a matching Docker image to the wild. So far so good For automation, we could use a little script like: ```bash version="0.0.7-rc" latest_commit="$(git rev-parse HEAD)" | git tag -a ${version} ${latest_commit=} -m "signing tag" && git push origin ${version} ``` I personally would like to use -s, instead of -a, to actually sign the tag. This is a good practice that we are doing in AeroGear land (and other jboss projects). For more see [1]. Any thoughts? -Matthias PS: working on something similar for the MCP itself, which is a bit more tricky ;-) [1] https://github.com/aerogear/collateral/wiki/Release-Process-(Java) -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From weil at redhat.com Wed Oct 25 08:41:45 2017 From: weil at redhat.com (Wei Li) Date: Wed, 25 Oct 2017 09:41:45 +0100 Subject: [feedhenry-dev] RFC: Release process for the Ansible Playbook Bundles (APBs) In-Reply-To: References: Message-ID: +1. What about change logs? can we auto-generate them as part of the release? On Wed, Oct 25, 2017 at 9:18 AM, Matthias Wessendorf wrote: > Hi, > > we have some independent APBs, like for 3scale, Keycloak or AeroGear > Digger, and those live in their own GH repository. We recently have > converted their matching Dockerhub repositories to be build automatically > once changes on the source code occur: > > * master changes (e.g. PRs got merged) -> triggers a new build of the > "latest" docker image > * Tags: pushing a new tag in github triggers a build of a "tagged" docker > image. Current convention: GH tag == Docker tag (e.g. a version like > "0.0.5" is same in both worlds) > > How should we run releases for these APB repos ? > > Usually after changes did land on master, and there is a *demand* for a > release, the last commit is used, and a tag is created and pushed to > github. This also - as stated above - does release a matching Docker image > to the wild. So far so good > > For automation, we could use a little script like: > > ```bash > version="0.0.7-rc" > > latest_commit="$(git rev-parse HEAD)" | git tag -a ${version} > ${latest_commit=} -m "signing tag" && git push origin ${version} > ``` > > I personally would like to use -s, instead of -a, to actually sign the > tag. This is a good practice that we are doing in AeroGear land (and other > jboss projects). For more see [1]. > > Any thoughts? > -Matthias > > PS: working on something similar for the MCP itself, which is a bit more > tricky ;-) > > > [1] https://github.com/aerogear/collateral/wiki/Release-Process-(Java) > > -- > Project lead AeroGear.org > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- WEI LI SENIOR SOFTWARE ENGINEER Red Hat Mobile weil at redhat.com M: +353862393272 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Wed Oct 25 08:45:32 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Wed, 25 Oct 2017 10:45:32 +0200 Subject: [feedhenry-dev] RFC: Release process for the Ansible Playbook Bundles (APBs) In-Reply-To: References: Message-ID: yep, not done in a long time, but the AeroGear document says something like: >> ... git-extras installed, this way you can easily generate a change log by running git changelog , that will create an history.md file containing your changelog ... >> So, that could work and be evaluated ;-) On Wed, Oct 25, 2017 at 10:41 AM, Wei Li wrote: > +1. What about change logs? can we auto-generate them as part of the > release? > > On Wed, Oct 25, 2017 at 9:18 AM, Matthias Wessendorf > wrote: > >> Hi, >> >> we have some independent APBs, like for 3scale, Keycloak or AeroGear >> Digger, and those live in their own GH repository. We recently have >> converted their matching Dockerhub repositories to be build automatically >> once changes on the source code occur: >> >> * master changes (e.g. PRs got merged) -> triggers a new build of the >> "latest" docker image >> * Tags: pushing a new tag in github triggers a build of a "tagged" docker >> image. Current convention: GH tag == Docker tag (e.g. a version like >> "0.0.5" is same in both worlds) >> >> How should we run releases for these APB repos ? >> >> Usually after changes did land on master, and there is a *demand* for a >> release, the last commit is used, and a tag is created and pushed to >> github. This also - as stated above - does release a matching Docker image >> to the wild. So far so good >> >> For automation, we could use a little script like: >> >> ```bash >> version="0.0.7-rc" >> >> latest_commit="$(git rev-parse HEAD)" | git tag -a ${version} >> ${latest_commit=} -m "signing tag" && git push origin ${version} >> ``` >> >> I personally would like to use -s, instead of -a, to actually sign the >> tag. This is a good practice that we are doing in AeroGear land (and other >> jboss projects). For more see [1]. >> >> Any thoughts? >> -Matthias >> >> PS: working on something similar for the MCP itself, which is a bit more >> tricky ;-) >> >> >> [1] https://github.com/aerogear/collateral/wiki/Release-Process-(Java) >> >> -- >> Project lead AeroGear.org >> >> _______________________________________________ >> 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 > > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Wed Oct 25 08:51:38 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Wed, 25 Oct 2017 10:51:38 +0200 Subject: [feedhenry-dev] RFC: Release process for the Ansible Playbook Bundles (APBs) In-Reply-To: References: Message-ID: I just installed it: https://github.com/tj/git-extras/blob/master/Installation.md and yep 'git changelog' generated the CHANGELOG.md file On Wed, Oct 25, 2017 at 10:45 AM, Matthias Wessendorf wrote: > yep, > > not done in a long time, but the AeroGear document says something like: > > >> > ... > git-extras installed, this way you can easily generate a change log by > running git changelog , that will create an history.md file containing > your changelog > ... > >> > > So, that could work and be evaluated ;-) > > > > On Wed, Oct 25, 2017 at 10:41 AM, Wei Li wrote: > >> +1. What about change logs? can we auto-generate them as part of the >> release? >> >> On Wed, Oct 25, 2017 at 9:18 AM, Matthias Wessendorf > > wrote: >> >>> Hi, >>> >>> we have some independent APBs, like for 3scale, Keycloak or AeroGear >>> Digger, and those live in their own GH repository. We recently have >>> converted their matching Dockerhub repositories to be build automatically >>> once changes on the source code occur: >>> >>> * master changes (e.g. PRs got merged) -> triggers a new build of the >>> "latest" docker image >>> * Tags: pushing a new tag in github triggers a build of a "tagged" >>> docker image. Current convention: GH tag == Docker tag (e.g. a version like >>> "0.0.5" is same in both worlds) >>> >>> How should we run releases for these APB repos ? >>> >>> Usually after changes did land on master, and there is a *demand* for a >>> release, the last commit is used, and a tag is created and pushed to >>> github. This also - as stated above - does release a matching Docker image >>> to the wild. So far so good >>> >>> For automation, we could use a little script like: >>> >>> ```bash >>> version="0.0.7-rc" >>> >>> latest_commit="$(git rev-parse HEAD)" | git tag -a ${version} >>> ${latest_commit=} -m "signing tag" && git push origin ${version} >>> ``` >>> >>> I personally would like to use -s, instead of -a, to actually sign the >>> tag. This is a good practice that we are doing in AeroGear land (and other >>> jboss projects). For more see [1]. >>> >>> Any thoughts? >>> -Matthias >>> >>> PS: working on something similar for the MCP itself, which is a bit more >>> tricky ;-) >>> >>> >>> [1] https://github.com/aerogear/collateral/wiki/Release-Process-(Java) >>> >>> -- >>> Project lead AeroGear.org >>> >>> _______________________________________________ >>> 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 >> >> > > > > -- > Project lead AeroGear.org > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Wed Oct 25 09:48:43 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Wed, 25 Oct 2017 11:48:43 +0200 Subject: [feedhenry-dev] RFC: Release process for the Ansible Playbook Bundles (APBs) In-Reply-To: References: Message-ID: > > > For automation, we could use a little script like: > > ```bash > version="0.0.7-rc" > > latest_commit="$(git rev-parse HEAD)" | git tag -a ${version} > ${latest_commit=} -m "signing tag" && git push origin ${version} > ``` > One more thought/comment. The "origin" does not ultimately fly - since folks could have renamed it to upstream etc. So, IMO that should be also a variable. More advanced tools, like the awesome maven-release-plugin, leverages that information from some SCM metadata in the pom.xml file: https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/pom.xml#L35-L40 But that's perhaps a bit of overhead here ;-) So my initial vote would be make the name of the origin also configurable Thoughts ? -M -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From davmarti at redhat.com Wed Oct 25 09:54:07 2017 From: davmarti at redhat.com (David Martin) Date: Wed, 25 Oct 2017 10:54:07 +0100 Subject: [feedhenry-dev] ServiceClass icons handled differently in OCP 3.7 Message-ID: Noticed an issue with the icons in the Mobile Overview screen. Created an Bug and dropped it into the sprint https://issues.jboss.org/browse/FH-4325 -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Wed Oct 25 10:00:08 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Wed, 25 Oct 2017 12:00:08 +0200 Subject: [feedhenry-dev] ServiceClass icons handled differently in OCP 3.7 In-Reply-To: References: Message-ID: is that something on the service-catalog itself? Looks like we do use the " console.openshift.io/iconClass", e.g.: https://github.com/feedhenry/fh-sync-server-apb/blob/master/apb.yml#L10 -M On Wed, Oct 25, 2017 at 11:54 AM, David Martin wrote: > Noticed an issue with the icons in the Mobile Overview screen. > Created an Bug and dropped it into the sprint > > https://issues.jboss.org/browse/FH-4325 > > -- > David Martin > Red Hat Mobile > Twitter: @irldavem > IRC: @irldavem (feedhenry, mobile-internal) > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhellar at redhat.com Wed Oct 25 11:56:19 2017 From: jhellar at redhat.com (Jan Hellar) Date: Wed, 25 Oct 2017 13:56:19 +0200 Subject: [feedhenry-dev] oc cluster up - router not starting Message-ID: Hi, recently I wanted to install MCP on mac. I followed installation guide for mcp-standalone [1]. Ansible playbook fails when it waits for oc cluster to become ready. When running `oc cluster status` I get `Notice: Router is not yet ready`. I have also tried to run `oc cluster up` manually - same issue. When running `oc get pods` in `default` project, I can see that pod for router is in ContainerCreating state. Looking at events for the router pod I can see these two events: - Sandbox changed - Pod sandbox changed, it will be killed and re-created. 12 times in the last minute - Failed sync - Error syncing pod - 13 times in the last minute I have latest version of docker installed (Version 17.09.0-ce-mac35 (19611)). Tried latest version (3.6.0) of openshift-cli from both github and brew. Can anybody help with this issue? Thank you. Best regards, Jan Hellar [1] https://github.com/feedhenry/mcp-standalone/blob/master/docs/walkthroughs/local-setup.adoc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfrizell at redhat.com Wed Oct 25 12:02:14 2017 From: jfrizell at redhat.com (John Frizelle) Date: Wed, 25 Oct 2017 13:02:14 +0100 Subject: [feedhenry-dev] oc cluster up - router not starting In-Reply-To: References: Message-ID: Hi Jan, This seems to be an OpenShift problem rather than something specific to mobile. Suggest you ask the question on an OpenShift list - (i.e. with references to MCP removed and just focused on the fact that oc cluster up is not working Regards, John. -- John Frizelle Chief Architect, Red Hat Mobile Consulting Engineer mobile: *+353 87 290 1644 * twitter:* @johnfriz* skype: *john_frizelle* mail: *jfrizell at redhat.com * On 25 October 2017 at 12:56, Jan Hellar wrote: > Hi, > > recently I wanted to install MCP on mac. I followed installation guide for > mcp-standalone [1]. Ansible playbook fails when it waits for oc cluster to > become ready. When running `oc cluster status` I get `Notice: Router is not > yet ready`. I have also tried to run `oc cluster up` manually - same issue. > When running `oc get pods` in `default` project, I can see that pod for > router is in ContainerCreating state. Looking at events for the router pod > I can see these two events: > - Sandbox changed - Pod sandbox changed, it will be killed and re-created. > 12 times in the last minute > - Failed sync - Error syncing pod - 13 times in the last minute > > I have latest version of docker installed (Version 17.09.0-ce-mac35 > (19611)). Tried latest version (3.6.0) of openshift-cli from both github > and brew. > > Can anybody help with this issue? Thank you. > > Best regards, > > Jan Hellar > > [1] https://github.com/feedhenry/mcp-standalone/blob/ > master/docs/walkthroughs/local-setup.adoc > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 11472 bytes Desc: not available URL: From davmarti at redhat.com Wed Oct 25 15:39:30 2017 From: davmarti at redhat.com (David Martin) Date: Wed, 25 Oct 2017 16:39:30 +0100 Subject: [feedhenry-dev] ServiceClass icons handled differently in OCP 3.7 In-Reply-To: References: Message-ID: I'd say the structure of the clusterserviceclass has changed somewhat, so the icon may be elsewhere. Here's the mcp ui code to get the icon based on the service name https://github.com/feedhenry/mcp-standalone/blob/c320a357fa7209484e3010feef813756d6c58881/ui/public/scripts/components/mobile-overview/object-card.component.js#L53-L74 On 25 October 2017 at 11:00, Matthias Wessendorf wrote: > is that something on the service-catalog itself? Looks like we do use the " > console.openshift.io/iconClass", e.g.: > https://github.com/feedhenry/fh-sync-server-apb/blob/master/apb.yml#L10 > > -M > > On Wed, Oct 25, 2017 at 11:54 AM, David Martin > wrote: > >> Noticed an issue with the icons in the Mobile Overview screen. >> Created an Bug and dropped it into the sprint >> >> https://issues.jboss.org/browse/FH-4325 >> >> -- >> David Martin >> Red Hat Mobile >> Twitter: @irldavem >> IRC: @irldavem (feedhenry, mobile-internal) >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > > -- > Project lead AeroGear.org > -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Wed Oct 25 18:20:30 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Wed, 25 Oct 2017 20:20:30 +0200 Subject: [feedhenry-dev] RFC: MCP-standalone Release Process Message-ID: Hi, as a follow up on [1], here are some thoughts on the MCP release itself. The raw process is described here: https://github.com/matzew/mcp-standalone/blob/Release_Process/docs/Release.md#mcp-release The first part is trivial (but not complete), we simply create a TAGGED (versioned) image, and push it to docker. Afterwards the mcp-standalone in dockerhub is updated. What's missing here is creation of a canonical TAG in git, more later; Now, the (three) dependent APBs of the MCP also need to be released. This requires a bit of manual steps, as described here: https://github.com/matzew/mcp-standalone/blob/Release_Process/docs/Release.md#mcp-included-apbs 1) manual modify the openshift template (which is included in the dependent APBs) 2) creating image tags and pushing all to dockerhub (-> make apbs ) In 2) we also modify code, by copying the template over, for that I've added a "release" commit in the Makefile target: https://github.com/matzew/mcp-standalone/commit/8d693cc6b2d58d9a2d83e33ea6cf9e31ce8bcac5 But we still have a locally modified file on the disk (the original openshift template). This is bad. The changes to the template must be committed before we can actually move on. To enforce that, I've added the following to the "make apbs" target: https://github.com/feedhenry/mcp-standalone/commit/260fd86868e7d12fb33197bf1ca9672a2f7d4b1a#commitcomment-25186889 if there are not committed files, the "make apbs" fails- this is inspired by the awesome ;-) Maven Release Plugin. As the last step, after the different pushes to dockerhub (mcp-standalone and its dependent APBs), we must create a release tag in git, and push it. Only with these "rules" (e.g. no locally modified files, and proper release tags, we end up having both in sync dockerhub images, and the matching TAG in git) I think these new rules help to get a more solid release, and with a bit of work can be applied by some "release script" But before hacking too much, I am generally interested in feedback on these already committed changes. Thanks! Matthias [1] https://www.redhat.com/archives/feedhenry-dev/2017-October/msg00114.html -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbrookes at redhat.com Thu Oct 26 07:43:13 2017 From: pbrookes at redhat.com (Phil Brookes) Date: Thu, 26 Oct 2017 08:43:13 +0100 Subject: [feedhenry-dev] RFC: MCP-standalone Release Process In-Reply-To: References: Message-ID: Hey Matthias, Now, the (three) dependent APBs of the MCP also need to be released. This > requires a bit of manual steps, as described here: > https://github.com/matzew/mcp-standalone/blob/Release_ > Process/docs/Release.md#mcp-included-apbs > > 1) manual modify the openshift template (which is included in the > dependent APBs) > 2) creating image tags and pushing all to dockerhub (-> make apbs ) > If the APBs that are currently included in the mcp-standalone repo were in their own separate repos (just like keycloak, 3scale, etc are currently) would that remove the requirement for these manual steps? ? I think it would be superior if we could have a standard workflow that all APBs follow, rather than some APBs working one way and some working another and requiring developers to remember which is which. Regards, Phil.? On Wed, Oct 25, 2017 at 7:20 PM, Matthias Wessendorf wrote: > Hi, > > as a follow up on [1], here are some thoughts on the MCP release itself. > > The raw process is described here: > https://github.com/matzew/mcp-standalone/blob/Release_ > Process/docs/Release.md#mcp-release > > The first part is trivial (but not complete), we simply create a TAGGED > (versioned) image, and push it to docker. Afterwards the mcp-standalone in > dockerhub is updated. > > What's missing here is creation of a canonical TAG in git, more later; > > Now, the (three) dependent APBs of the MCP also need to be released. This > requires a bit of manual steps, as described here: > https://github.com/matzew/mcp-standalone/blob/Release_ > Process/docs/Release.md#mcp-included-apbs > > 1) manual modify the openshift template (which is included in the > dependent APBs) > 2) creating image tags and pushing all to dockerhub (-> make apbs ) > > > In 2) we also modify code, by copying the template over, for that I've > added a "release" commit in the Makefile target: > https://github.com/matzew/mcp-standalone/commit/ > 8d693cc6b2d58d9a2d83e33ea6cf9e31ce8bcac5 > > But we still have a locally modified file on the disk (the original > openshift template). This is bad. > The changes to the template must be committed before we can actually move > on. To enforce that, I've added the following to the "make apbs" target: > https://github.com/feedhenry/mcp-standalone/commit/ > 260fd86868e7d12fb33197bf1ca9672a2f7d4b1a#commitcomment-25186889 > > if there are not committed files, the "make apbs" fails- this is inspired > by the awesome ;-) Maven Release Plugin. > > As the last step, after the different pushes to dockerhub (mcp-standalone > and its dependent APBs), we must create a release tag in git, and push it. > > Only with these "rules" (e.g. no locally modified files, and proper > release tags, we end up having both in sync dockerhub images, and the > matching TAG in git) > > I think these new rules help to get a more solid release, and with a bit > of work can be applied by some "release script" > > But before hacking too much, I am generally interested in feedback on > these already committed changes. > > Thanks! > Matthias > > > [1] https://www.redhat.com/archives/feedhenry-dev/2017- > October/msg00114.html > > > -- > Project lead AeroGear.org > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Thu Oct 26 07:52:05 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Thu, 26 Oct 2017 09:52:05 +0200 Subject: [feedhenry-dev] RFC: MCP-standalone Release Process In-Reply-To: References: Message-ID: On Thu, Oct 26, 2017 at 9:43 AM, Phil Brookes wrote: > Hey Matthias, > > Now, the (three) dependent APBs of the MCP also need to be released. This >> requires a bit of manual steps, as described here: >> https://github.com/matzew/mcp-standalone/blob/Release_Proces >> s/docs/Release.md#mcp-included-apbs >> >> 1) manual modify the openshift template (which is included in the >> dependent APBs) >> 2) creating image tags and pushing all to dockerhub (-> make apbs ) >> > > If the APBs that are currently included in the mcp-standalone repo were in > their own separate repos (just like keycloak, 3scale, etc are currently) > would that remove the requirement for these manual steps? > no - these three guys (android, ios, cordova) are special ABPs :-) They are MCPs, and they need the updated template. With a separated repo, they would each need a PR to get the updated version. > ? I think it would be superior if we could have a standard workflow that > all APBs follow, rather than some APBs working one way and some working > another and requiring developers to remember which is which. > So yeah, I think these three are a bit special :) BTW. yesterday on IRC Craig suggested at our F2F in a couple of weeks we all sit down and discuss a good approach for this. He mentione kubernetes, where different things are in their own repos, but sync'd to the main one (no damn gitsubmodules) > > > Regards, > > Phil.? > > > > > On Wed, Oct 25, 2017 at 7:20 PM, Matthias Wessendorf > wrote: > >> Hi, >> >> as a follow up on [1], here are some thoughts on the MCP release itself. >> >> The raw process is described here: >> https://github.com/matzew/mcp-standalone/blob/Release_Proces >> s/docs/Release.md#mcp-release >> >> The first part is trivial (but not complete), we simply create a TAGGED >> (versioned) image, and push it to docker. Afterwards the mcp-standalone in >> dockerhub is updated. >> >> What's missing here is creation of a canonical TAG in git, more later; >> >> Now, the (three) dependent APBs of the MCP also need to be released. This >> requires a bit of manual steps, as described here: >> https://github.com/matzew/mcp-standalone/blob/Release_Proces >> s/docs/Release.md#mcp-included-apbs >> >> 1) manual modify the openshift template (which is included in the >> dependent APBs) >> 2) creating image tags and pushing all to dockerhub (-> make apbs ) >> >> >> In 2) we also modify code, by copying the template over, for that I've >> added a "release" commit in the Makefile target: >> https://github.com/matzew/mcp-standalone/commit/8d693cc6b2d5 >> 8d9a2d83e33ea6cf9e31ce8bcac5 >> >> But we still have a locally modified file on the disk (the original >> openshift template). This is bad. >> The changes to the template must be committed before we can actually move >> on. To enforce that, I've added the following to the "make apbs" target: >> https://github.com/feedhenry/mcp-standalone/commit/260fd8686 >> 8e7d12fb33197bf1ca9672a2f7d4b1a#commitcomment-25186889 >> >> if there are not committed files, the "make apbs" fails- this is inspired >> by the awesome ;-) Maven Release Plugin. >> >> As the last step, after the different pushes to dockerhub (mcp-standalone >> and its dependent APBs), we must create a release tag in git, and push it. >> >> Only with these "rules" (e.g. no locally modified files, and proper >> release tags, we end up having both in sync dockerhub images, and the >> matching TAG in git) >> >> I think these new rules help to get a more solid release, and with a bit >> of work can be applied by some "release script" >> >> But before hacking too much, I am generally interested in feedback on >> these already committed changes. >> >> Thanks! >> Matthias >> >> >> [1] https://www.redhat.com/archives/feedhenry-dev/2017-Octob >> er/msg00114.html >> >> >> -- >> Project lead AeroGear.org >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From cbrookes at redhat.com Thu Oct 26 07:56:21 2017 From: cbrookes at redhat.com (Craig Brookes) Date: Thu, 26 Oct 2017 08:56:21 +0100 Subject: [feedhenry-dev] feedhenry-dev Digest, Vol 16, Issue 60 In-Reply-To: References: Message-ID: I think what you have outlined is great for our development releases, Matthias. If we haven't already we should update the doc. On the single repo, yes no git submodules, but I am big fan of it being in a single repo allow visibility for everything mcp that it happening and then syncing to separate repos for releases but as mentioned this is something we can get together and discuss as the f2f On Thu, Oct 26, 2017 at 8:52 AM, wrote: > Send feedhenry-dev mailing list submissions to > feedhenry-dev at redhat.com > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.redhat.com/mailman/listinfo/feedhenry-dev > or, via email, send a message with subject or body 'help' to > feedhenry-dev-request at redhat.com > > You can reach the person managing the list at > feedhenry-dev-owner at redhat.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of feedhenry-dev digest..." > > > Today's Topics: > > 1. RFC: MCP-standalone Release Process (Matthias Wessendorf) > 2. Re: RFC: MCP-standalone Release Process (Phil Brookes) > 3. Re: RFC: MCP-standalone Release Process (Matthias Wessendorf) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 25 Oct 2017 20:20:30 +0200 > From: Matthias Wessendorf > To: feedhenry-dev at redhat.com > Subject: [feedhenry-dev] RFC: MCP-standalone Release Process > Message-ID: > gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi, > > as a follow up on [1], here are some thoughts on the MCP release itself. > > The raw process is described here: > https://github.com/matzew/mcp-standalone/blob/Release_ > Process/docs/Release.md#mcp-release > > The first part is trivial (but not complete), we simply create a TAGGED > (versioned) image, and push it to docker. Afterwards the mcp-standalone in > dockerhub is updated. > > What's missing here is creation of a canonical TAG in git, more later; > > Now, the (three) dependent APBs of the MCP also need to be released. This > requires a bit of manual steps, as described here: > https://github.com/matzew/mcp-standalone/blob/Release_ > Process/docs/Release.md#mcp-included-apbs > > 1) manual modify the openshift template (which is included in the dependent > APBs) > 2) creating image tags and pushing all to dockerhub (-> make apbs ) > > > In 2) we also modify code, by copying the template over, for that I've > added a "release" commit in the Makefile target: > https://github.com/matzew/mcp-standalone/commit/ > 8d693cc6b2d58d9a2d83e33ea6cf9e31ce8bcac5 > > But we still have a locally modified file on the disk (the original > openshift template). This is bad. > The changes to the template must be committed before we can actually move > on. To enforce that, I've added the following to the "make apbs" target: > https://github.com/feedhenry/mcp-standalone/commit/ > 260fd86868e7d12fb33197bf1ca9672a2f7d4b1a#commitcomment-25186889 > > if there are not committed files, the "make apbs" fails- this is inspired > by the awesome ;-) Maven Release Plugin. > > As the last step, after the different pushes to dockerhub (mcp-standalone > and its dependent APBs), we must create a release tag in git, and push it. > > Only with these "rules" (e.g. no locally modified files, and proper release > tags, we end up having both in sync dockerhub images, and the matching TAG > in git) > > I think these new rules help to get a more solid release, and with a bit of > work can be applied by some "release script" > > But before hacking too much, I am generally interested in feedback on these > already committed changes. > > Thanks! > Matthias > > > [1] https://www.redhat.com/archives/feedhenry-dev/2017- > October/msg00114.html > > > -- > Project lead AeroGear.org > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: attachments/20171025/68d2a0d3/attachment.html> > > ------------------------------ > > Message: 2 > Date: Thu, 26 Oct 2017 08:43:13 +0100 > From: Phil Brookes > To: Matthias Wessendorf > Cc: feedhenry-dev at redhat.com > Subject: Re: [feedhenry-dev] RFC: MCP-standalone Release Process > Message-ID: > gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hey Matthias, > > Now, the (three) dependent APBs of the MCP also need to be released. This > > requires a bit of manual steps, as described here: > > https://github.com/matzew/mcp-standalone/blob/Release_ > > Process/docs/Release.md#mcp-included-apbs > > > > 1) manual modify the openshift template (which is included in the > > dependent APBs) > > 2) creating image tags and pushing all to dockerhub (-> make apbs ) > > > > If the APBs that are currently included in the mcp-standalone repo were in > their own separate repos (just like keycloak, 3scale, etc are currently) > would that remove the requirement for these manual steps? > ? I think it would be superior if we could have a standard workflow that > all APBs follow, rather than some APBs working one way and some working > another and requiring developers to remember which is which. > > > Regards, > > Phil.? > > > > > On Wed, Oct 25, 2017 at 7:20 PM, Matthias Wessendorf > wrote: > > > Hi, > > > > as a follow up on [1], here are some thoughts on the MCP release itself. > > > > The raw process is described here: > > https://github.com/matzew/mcp-standalone/blob/Release_ > > Process/docs/Release.md#mcp-release > > > > The first part is trivial (but not complete), we simply create a TAGGED > > (versioned) image, and push it to docker. Afterwards the mcp-standalone > in > > dockerhub is updated. > > > > What's missing here is creation of a canonical TAG in git, more later; > > > > Now, the (three) dependent APBs of the MCP also need to be released. This > > requires a bit of manual steps, as described here: > > https://github.com/matzew/mcp-standalone/blob/Release_ > > Process/docs/Release.md#mcp-included-apbs > > > > 1) manual modify the openshift template (which is included in the > > dependent APBs) > > 2) creating image tags and pushing all to dockerhub (-> make apbs ) > > > > > > In 2) we also modify code, by copying the template over, for that I've > > added a "release" commit in the Makefile target: > > https://github.com/matzew/mcp-standalone/commit/ > > 8d693cc6b2d58d9a2d83e33ea6cf9e31ce8bcac5 > > > > But we still have a locally modified file on the disk (the original > > openshift template). This is bad. > > The changes to the template must be committed before we can actually move > > on. To enforce that, I've added the following to the "make apbs" target: > > https://github.com/feedhenry/mcp-standalone/commit/ > > 260fd86868e7d12fb33197bf1ca9672a2f7d4b1a#commitcomment-25186889 > > > > if there are not committed files, the "make apbs" fails- this is inspired > > by the awesome ;-) Maven Release Plugin. > > > > As the last step, after the different pushes to dockerhub (mcp-standalone > > and its dependent APBs), we must create a release tag in git, and push > it. > > > > Only with these "rules" (e.g. no locally modified files, and proper > > release tags, we end up having both in sync dockerhub images, and the > > matching TAG in git) > > > > I think these new rules help to get a more solid release, and with a bit > > of work can be applied by some "release script" > > > > But before hacking too much, I am generally interested in feedback on > > these already committed changes. > > > > Thanks! > > Matthias > > > > > > [1] https://www.redhat.com/archives/feedhenry-dev/2017- > > October/msg00114.html > > > > > > -- > > 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: attachments/20171026/6dfa87dc/attachment.html> > > ------------------------------ > > Message: 3 > Date: Thu, 26 Oct 2017 09:52:05 +0200 > From: Matthias Wessendorf > To: Phil Brookes > Cc: feedhenry-dev at redhat.com > Subject: Re: [feedhenry-dev] RFC: MCP-standalone Release Process > Message-ID: > mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > On Thu, Oct 26, 2017 at 9:43 AM, Phil Brookes wrote: > > > Hey Matthias, > > > > Now, the (three) dependent APBs of the MCP also need to be released. This > >> requires a bit of manual steps, as described here: > >> https://github.com/matzew/mcp-standalone/blob/Release_Proces > >> s/docs/Release.md#mcp-included-apbs > >> > >> 1) manual modify the openshift template (which is included in the > >> dependent APBs) > >> 2) creating image tags and pushing all to dockerhub (-> make apbs ) > >> > > > > If the APBs that are currently included in the mcp-standalone repo were > in > > their own separate repos (just like keycloak, 3scale, etc are currently) > > would that remove the requirement for these manual steps? > > > > no - these three guys (android, ios, cordova) are special ABPs :-) They are > MCPs, and they need the updated template. > With a separated repo, they would each need a PR to get the updated > version. > > > > > ? I think it would be superior if we could have a standard workflow that > > all APBs follow, rather than some APBs working one way and some working > > another and requiring developers to remember which is which. > > > > So yeah, I think these three are a bit special :) > > BTW. yesterday on IRC Craig suggested at our F2F in a couple of weeks we > all sit down and discuss a good approach for this. He mentione kubernetes, > where different things are in their own repos, but sync'd to the main one > (no damn gitsubmodules) > > > > > > > > > Regards, > > > > Phil.? > > > > > > > > > > On Wed, Oct 25, 2017 at 7:20 PM, Matthias Wessendorf < > mwessend at redhat.com> > > wrote: > > > >> Hi, > >> > >> as a follow up on [1], here are some thoughts on the MCP release itself. > >> > >> The raw process is described here: > >> https://github.com/matzew/mcp-standalone/blob/Release_Proces > >> s/docs/Release.md#mcp-release > >> > >> The first part is trivial (but not complete), we simply create a TAGGED > >> (versioned) image, and push it to docker. Afterwards the mcp-standalone > in > >> dockerhub is updated. > >> > >> What's missing here is creation of a canonical TAG in git, more later; > >> > >> Now, the (three) dependent APBs of the MCP also need to be released. > This > >> requires a bit of manual steps, as described here: > >> https://github.com/matzew/mcp-standalone/blob/Release_Proces > >> s/docs/Release.md#mcp-included-apbs > >> > >> 1) manual modify the openshift template (which is included in the > >> dependent APBs) > >> 2) creating image tags and pushing all to dockerhub (-> make apbs ) > >> > >> > >> In 2) we also modify code, by copying the template over, for that I've > >> added a "release" commit in the Makefile target: > >> https://github.com/matzew/mcp-standalone/commit/8d693cc6b2d5 > >> 8d9a2d83e33ea6cf9e31ce8bcac5 > >> > >> But we still have a locally modified file on the disk (the original > >> openshift template). This is bad. > >> The changes to the template must be committed before we can actually > move > >> on. To enforce that, I've added the following to the "make apbs" target: > >> https://github.com/feedhenry/mcp-standalone/commit/260fd8686 > >> 8e7d12fb33197bf1ca9672a2f7d4b1a#commitcomment-25186889 > >> > >> if there are not committed files, the "make apbs" fails- this is > inspired > >> by the awesome ;-) Maven Release Plugin. > >> > >> As the last step, after the different pushes to dockerhub > (mcp-standalone > >> and its dependent APBs), we must create a release tag in git, and push > it. > >> > >> Only with these "rules" (e.g. no locally modified files, and proper > >> release tags, we end up having both in sync dockerhub images, and the > >> matching TAG in git) > >> > >> I think these new rules help to get a more solid release, and with a bit > >> of work can be applied by some "release script" > >> > >> But before hacking too much, I am generally interested in feedback on > >> these already committed changes. > >> > >> Thanks! > >> Matthias > >> > >> > >> [1] https://www.redhat.com/archives/feedhenry-dev/2017-Octob > >> er/msg00114.html > >> > >> > >> -- > >> Project lead AeroGear.org > >> > >> _______________________________________________ > >> feedhenry-dev mailing list > >> feedhenry-dev at redhat.com > >> https://www.redhat.com/mailman/listinfo/feedhenry-dev > >> > >> > > > > > -- > Project lead AeroGear.org > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: attachments/20171026/37a80476/attachment.html> > > ------------------------------ > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > > End of feedhenry-dev Digest, Vol 16, Issue 60 > ********************************************* > -- Craig Brookes RHMAP @maleck13 Github -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Thu Oct 26 08:18:43 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Thu, 26 Oct 2017 10:18:43 +0200 Subject: [feedhenry-dev] feedhenry-dev Digest, Vol 16, Issue 60 In-Reply-To: References: Message-ID: On Thu, Oct 26, 2017 at 9:56 AM, Craig Brookes wrote: > I think what you have outlined is great for our development releases, > Matthias. If we haven't already we should update the doc. > Ok, cool - I will weave that into the doc(s), and send PRs > > On the single repo, yes no git submodules, but I am big fan of it being in > a single repo allow visibility for everything mcp that it happening and > then syncing to separate repos for releases but as mentioned this is > something we can get together and discuss as the f2f > > On Thu, Oct 26, 2017 at 8:52 AM, wrote: > >> Send feedhenry-dev mailing list submissions to >> feedhenry-dev at redhat.com >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> or, via email, send a message with subject or body 'help' to >> feedhenry-dev-request at redhat.com >> >> You can reach the person managing the list at >> feedhenry-dev-owner at redhat.com >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of feedhenry-dev digest..." >> >> >> Today's Topics: >> >> 1. RFC: MCP-standalone Release Process (Matthias Wessendorf) >> 2. Re: RFC: MCP-standalone Release Process (Phil Brookes) >> 3. Re: RFC: MCP-standalone Release Process (Matthias Wessendorf) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Wed, 25 Oct 2017 20:20:30 +0200 >> From: Matthias Wessendorf >> To: feedhenry-dev at redhat.com >> Subject: [feedhenry-dev] RFC: MCP-standalone Release Process >> Message-ID: >> > ail.com> >> Content-Type: text/plain; charset="utf-8" >> >> Hi, >> >> as a follow up on [1], here are some thoughts on the MCP release itself. >> >> The raw process is described here: >> https://github.com/matzew/mcp-standalone/blob/Release_Proces >> s/docs/Release.md#mcp-release >> >> The first part is trivial (but not complete), we simply create a TAGGED >> (versioned) image, and push it to docker. Afterwards the mcp-standalone in >> dockerhub is updated. >> >> What's missing here is creation of a canonical TAG in git, more later; >> >> Now, the (three) dependent APBs of the MCP also need to be released. This >> requires a bit of manual steps, as described here: >> https://github.com/matzew/mcp-standalone/blob/Release_Proces >> s/docs/Release.md#mcp-included-apbs >> >> 1) manual modify the openshift template (which is included in the >> dependent >> APBs) >> 2) creating image tags and pushing all to dockerhub (-> make apbs ) >> >> >> In 2) we also modify code, by copying the template over, for that I've >> added a "release" commit in the Makefile target: >> https://github.com/matzew/mcp-standalone/commit/8d693cc6b2d5 >> 8d9a2d83e33ea6cf9e31ce8bcac5 >> >> But we still have a locally modified file on the disk (the original >> openshift template). This is bad. >> The changes to the template must be committed before we can actually move >> on. To enforce that, I've added the following to the "make apbs" target: >> https://github.com/feedhenry/mcp-standalone/commit/260fd8686 >> 8e7d12fb33197bf1ca9672a2f7d4b1a#commitcomment-25186889 >> >> if there are not committed files, the "make apbs" fails- this is inspired >> by the awesome ;-) Maven Release Plugin. >> >> As the last step, after the different pushes to dockerhub (mcp-standalone >> and its dependent APBs), we must create a release tag in git, and push it. >> >> Only with these "rules" (e.g. no locally modified files, and proper >> release >> tags, we end up having both in sync dockerhub images, and the matching TAG >> in git) >> >> I think these new rules help to get a more solid release, and with a bit >> of >> work can be applied by some "release script" >> >> But before hacking too much, I am generally interested in feedback on >> these >> already committed changes. >> >> Thanks! >> Matthias >> >> >> [1] https://www.redhat.com/archives/feedhenry-dev/2017-October/ >> msg00114.html >> >> >> -- >> Project lead AeroGear.org >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: > 20171025/68d2a0d3/attachment.html> >> >> ------------------------------ >> >> Message: 2 >> Date: Thu, 26 Oct 2017 08:43:13 +0100 >> From: Phil Brookes >> To: Matthias Wessendorf >> Cc: feedhenry-dev at redhat.com >> Subject: Re: [feedhenry-dev] RFC: MCP-standalone Release Process >> Message-ID: >> > ail.com> >> Content-Type: text/plain; charset="utf-8" >> >> Hey Matthias, >> >> Now, the (three) dependent APBs of the MCP also need to be released. This >> > requires a bit of manual steps, as described here: >> > https://github.com/matzew/mcp-standalone/blob/Release_ >> > Process/docs/Release.md#mcp-included-apbs >> > >> > 1) manual modify the openshift template (which is included in the >> > dependent APBs) >> > 2) creating image tags and pushing all to dockerhub (-> make apbs ) >> > >> >> If the APBs that are currently included in the mcp-standalone repo were in >> their own separate repos (just like keycloak, 3scale, etc are currently) >> would that remove the requirement for these manual steps? >> ? I think it would be superior if we could have a standard workflow that >> all APBs follow, rather than some APBs working one way and some working >> another and requiring developers to remember which is which. >> >> >> Regards, >> >> Phil.? >> >> >> >> >> On Wed, Oct 25, 2017 at 7:20 PM, Matthias Wessendorf > > >> wrote: >> >> > Hi, >> > >> > as a follow up on [1], here are some thoughts on the MCP release itself. >> > >> > The raw process is described here: >> > https://github.com/matzew/mcp-standalone/blob/Release_ >> > Process/docs/Release.md#mcp-release >> > >> > The first part is trivial (but not complete), we simply create a TAGGED >> > (versioned) image, and push it to docker. Afterwards the mcp-standalone >> in >> > dockerhub is updated. >> > >> > What's missing here is creation of a canonical TAG in git, more later; >> > >> > Now, the (three) dependent APBs of the MCP also need to be released. >> This >> > requires a bit of manual steps, as described here: >> > https://github.com/matzew/mcp-standalone/blob/Release_ >> > Process/docs/Release.md#mcp-included-apbs >> > >> > 1) manual modify the openshift template (which is included in the >> > dependent APBs) >> > 2) creating image tags and pushing all to dockerhub (-> make apbs ) >> > >> > >> > In 2) we also modify code, by copying the template over, for that I've >> > added a "release" commit in the Makefile target: >> > https://github.com/matzew/mcp-standalone/commit/ >> > 8d693cc6b2d58d9a2d83e33ea6cf9e31ce8bcac5 >> > >> > But we still have a locally modified file on the disk (the original >> > openshift template). This is bad. >> > The changes to the template must be committed before we can actually >> move >> > on. To enforce that, I've added the following to the "make apbs" target: >> > https://github.com/feedhenry/mcp-standalone/commit/ >> > 260fd86868e7d12fb33197bf1ca9672a2f7d4b1a#commitcomment-25186889 >> > >> > if there are not committed files, the "make apbs" fails- this is >> inspired >> > by the awesome ;-) Maven Release Plugin. >> > >> > As the last step, after the different pushes to dockerhub >> (mcp-standalone >> > and its dependent APBs), we must create a release tag in git, and push >> it. >> > >> > Only with these "rules" (e.g. no locally modified files, and proper >> > release tags, we end up having both in sync dockerhub images, and the >> > matching TAG in git) >> > >> > I think these new rules help to get a more solid release, and with a bit >> > of work can be applied by some "release script" >> > >> > But before hacking too much, I am generally interested in feedback on >> > these already committed changes. >> > >> > Thanks! >> > Matthias >> > >> > >> > [1] https://www.redhat.com/archives/feedhenry-dev/2017- >> > October/msg00114.html >> > >> > >> > -- >> > 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: > 20171026/6dfa87dc/attachment.html> >> >> ------------------------------ >> >> Message: 3 >> Date: Thu, 26 Oct 2017 09:52:05 +0200 >> From: Matthias Wessendorf >> To: Phil Brookes >> Cc: feedhenry-dev at redhat.com >> Subject: Re: [feedhenry-dev] RFC: MCP-standalone Release Process >> Message-ID: >> > gmail.com> >> Content-Type: text/plain; charset="utf-8" >> >> On Thu, Oct 26, 2017 at 9:43 AM, Phil Brookes >> wrote: >> >> > Hey Matthias, >> > >> > Now, the (three) dependent APBs of the MCP also need to be released. >> This >> >> requires a bit of manual steps, as described here: >> >> https://github.com/matzew/mcp-standalone/blob/Release_Proces >> >> s/docs/Release.md#mcp-included-apbs >> >> >> >> 1) manual modify the openshift template (which is included in the >> >> dependent APBs) >> >> 2) creating image tags and pushing all to dockerhub (-> make apbs ) >> >> >> > >> > If the APBs that are currently included in the mcp-standalone repo were >> in >> > their own separate repos (just like keycloak, 3scale, etc are currently) >> > would that remove the requirement for these manual steps? >> > >> >> no - these three guys (android, ios, cordova) are special ABPs :-) They >> are >> MCPs, and they need the updated template. >> With a separated repo, they would each need a PR to get the updated >> version. >> >> >> >> > ? I think it would be superior if we could have a standard workflow that >> > all APBs follow, rather than some APBs working one way and some working >> > another and requiring developers to remember which is which. >> > >> >> So yeah, I think these three are a bit special :) >> >> BTW. yesterday on IRC Craig suggested at our F2F in a couple of weeks we >> all sit down and discuss a good approach for this. He mentione kubernetes, >> where different things are in their own repos, but sync'd to the main one >> (no damn gitsubmodules) >> >> >> >> > >> > >> > Regards, >> > >> > Phil.? >> > >> > >> > >> > >> > On Wed, Oct 25, 2017 at 7:20 PM, Matthias Wessendorf < >> mwessend at redhat.com> >> > wrote: >> > >> >> Hi, >> >> >> >> as a follow up on [1], here are some thoughts on the MCP release >> itself. >> >> >> >> The raw process is described here: >> >> https://github.com/matzew/mcp-standalone/blob/Release_Proces >> >> s/docs/Release.md#mcp-release >> >> >> >> The first part is trivial (but not complete), we simply create a TAGGED >> >> (versioned) image, and push it to docker. Afterwards the >> mcp-standalone in >> >> dockerhub is updated. >> >> >> >> What's missing here is creation of a canonical TAG in git, more later; >> >> >> >> Now, the (three) dependent APBs of the MCP also need to be released. >> This >> >> requires a bit of manual steps, as described here: >> >> https://github.com/matzew/mcp-standalone/blob/Release_Proces >> >> s/docs/Release.md#mcp-included-apbs >> >> >> >> 1) manual modify the openshift template (which is included in the >> >> dependent APBs) >> >> 2) creating image tags and pushing all to dockerhub (-> make apbs ) >> >> >> >> >> >> In 2) we also modify code, by copying the template over, for that I've >> >> added a "release" commit in the Makefile target: >> >> https://github.com/matzew/mcp-standalone/commit/8d693cc6b2d5 >> >> 8d9a2d83e33ea6cf9e31ce8bcac5 >> >> >> >> But we still have a locally modified file on the disk (the original >> >> openshift template). This is bad. >> >> The changes to the template must be committed before we can actually >> move >> >> on. To enforce that, I've added the following to the "make apbs" >> target: >> >> https://github.com/feedhenry/mcp-standalone/commit/260fd8686 >> >> 8e7d12fb33197bf1ca9672a2f7d4b1a#commitcomment-25186889 >> >> >> >> if there are not committed files, the "make apbs" fails- this is >> inspired >> >> by the awesome ;-) Maven Release Plugin. >> >> >> >> As the last step, after the different pushes to dockerhub >> (mcp-standalone >> >> and its dependent APBs), we must create a release tag in git, and push >> it. >> >> >> >> Only with these "rules" (e.g. no locally modified files, and proper >> >> release tags, we end up having both in sync dockerhub images, and the >> >> matching TAG in git) >> >> >> >> I think these new rules help to get a more solid release, and with a >> bit >> >> of work can be applied by some "release script" >> >> >> >> But before hacking too much, I am generally interested in feedback on >> >> these already committed changes. >> >> >> >> Thanks! >> >> Matthias >> >> >> >> >> >> [1] https://www.redhat.com/archives/feedhenry-dev/2017-Octob >> >> er/msg00114.html >> >> >> >> >> >> -- >> >> Project lead AeroGear.org >> >> >> >> _______________________________________________ >> >> feedhenry-dev mailing list >> >> feedhenry-dev at redhat.com >> >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> >> >> >> > >> >> >> -- >> Project lead AeroGear.org >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: > 20171026/37a80476/attachment.html> >> >> ------------------------------ >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> >> End of feedhenry-dev Digest, Vol 16, Issue 60 >> ********************************************* >> > > > > -- > Craig Brookes > RHMAP > @maleck13 Github > > _______________________________________________ > 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 Thu Oct 26 10:23:05 2017 From: davmarti at redhat.com (David Martin) Date: Thu, 26 Oct 2017 11:23:05 +0100 Subject: [feedhenry-dev] RFC: MCP-standalone Release Process In-Reply-To: References: Message-ID: Those release steps sound logical to me. It allows getting all apbs and the mcp version locked down so it can be tested and shared. As its mostly scripted already, it's setting us up nicely for automating the entire upstream release process. Having the various git repos tagged too is important to allow for downstream productisation, and identifying when changes or bugs get introduced On 26 October 2017 at 08:52, Matthias Wessendorf wrote: > > > On Thu, Oct 26, 2017 at 9:43 AM, Phil Brookes wrote: > >> Hey Matthias, >> >> Now, the (three) dependent APBs of the MCP also need to be released. This >>> requires a bit of manual steps, as described here: >>> https://github.com/matzew/mcp-standalone/blob/Release_Proces >>> s/docs/Release.md#mcp-included-apbs >>> >>> 1) manual modify the openshift template (which is included in the >>> dependent APBs) >>> 2) creating image tags and pushing all to dockerhub (-> make apbs ) >>> >> >> If the APBs that are currently included in the mcp-standalone repo were >> in their own separate repos (just like keycloak, 3scale, etc are currently) >> would that remove the requirement for these manual steps? >> > > no - these three guys (android, ios, cordova) are special ABPs :-) They > are MCPs, and they need the updated template. > With a separated repo, they would each need a PR to get the updated > version. > > > >> ? I think it would be superior if we could have a standard workflow that >> all APBs follow, rather than some APBs working one way and some working >> another and requiring developers to remember which is which. >> > > So yeah, I think these three are a bit special :) > > BTW. yesterday on IRC Craig suggested at our F2F in a couple of weeks we > all sit down and discuss a good approach for this. He mentione kubernetes, > where different things are in their own repos, but sync'd to the main one > (no damn gitsubmodules) > > > >> >> >> Regards, >> >> Phil.? >> >> >> >> >> On Wed, Oct 25, 2017 at 7:20 PM, Matthias Wessendorf > > wrote: >> >>> Hi, >>> >>> as a follow up on [1], here are some thoughts on the MCP release itself. >>> >>> The raw process is described here: >>> https://github.com/matzew/mcp-standalone/blob/Release_Proces >>> s/docs/Release.md#mcp-release >>> >>> The first part is trivial (but not complete), we simply create a TAGGED >>> (versioned) image, and push it to docker. Afterwards the mcp-standalone in >>> dockerhub is updated. >>> >>> What's missing here is creation of a canonical TAG in git, more later; >>> >>> Now, the (three) dependent APBs of the MCP also need to be released. >>> This requires a bit of manual steps, as described here: >>> https://github.com/matzew/mcp-standalone/blob/Release_Proces >>> s/docs/Release.md#mcp-included-apbs >>> >>> 1) manual modify the openshift template (which is included in the >>> dependent APBs) >>> 2) creating image tags and pushing all to dockerhub (-> make apbs ) >>> >>> >>> In 2) we also modify code, by copying the template over, for that I've >>> added a "release" commit in the Makefile target: >>> https://github.com/matzew/mcp-standalone/commit/8d693cc6b2d5 >>> 8d9a2d83e33ea6cf9e31ce8bcac5 >>> >>> But we still have a locally modified file on the disk (the original >>> openshift template). This is bad. >>> The changes to the template must be committed before we can actually >>> move on. To enforce that, I've added the following to the "make apbs" >>> target: >>> https://github.com/feedhenry/mcp-standalone/commit/260fd8686 >>> 8e7d12fb33197bf1ca9672a2f7d4b1a#commitcomment-25186889 >>> >>> if there are not committed files, the "make apbs" fails- this is >>> inspired by the awesome ;-) Maven Release Plugin. >>> >>> As the last step, after the different pushes to dockerhub >>> (mcp-standalone and its dependent APBs), we must create a release tag in >>> git, and push it. >>> >>> Only with these "rules" (e.g. no locally modified files, and proper >>> release tags, we end up having both in sync dockerhub images, and the >>> matching TAG in git) >>> >>> I think these new rules help to get a more solid release, and with a bit >>> of work can be applied by some "release script" >>> >>> But before hacking too much, I am generally interested in feedback on >>> these already committed changes. >>> >>> Thanks! >>> Matthias >>> >>> >>> [1] https://www.redhat.com/archives/feedhenry-dev/2017-Octob >>> er/msg00114.html >>> >>> >>> -- >>> Project lead AeroGear.org >>> >>> _______________________________________________ >>> feedhenry-dev mailing list >>> feedhenry-dev at redhat.com >>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>> >>> >> > > > -- > Project lead AeroGear.org > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsutter at redhat.com Thu Oct 26 14:05:31 2017 From: bsutter at redhat.com (Burr Sutter) Date: 26 Oct 2017 10:05:31 -0400 Subject: [feedhenry-dev] Upcoming Red Hat DevNation Live Tech Talk: Continuous Deployment at Scale Message-ID: Read the online version . "Red Hat" Hi RedHat, Join the Red Hat DevNation for an upcoming live session on November?2, 2017, as James Rawlings?presents Continuous Deployment at Scale. How do you manage continuous integration / continuous delivery (CI/CD) across hundreds of projects simultaneously? Join this webinar to learn about an actual cloud-hosted Software-as-a-Service (SaaS) implementation that?s based on hundreds of independent microservices and using CI/CD and DevOps for a continuous flow to production. Register Now For more information and to view the schedule, click here . We hope you join us! Regards, Burr Sutter The Red Hat Developer Program __________________________________________________________________ [f1]Contact our sales team [f2]Manage your newsletter preferences [f3]Read our privacy policy [f4]Unsubscribe from all Red Hat email "Red Hat" and the "Shadowman" logo are trademarks or registered trademarks of Red Hat, Inc. Linux is a registered trademark of Linus Torvalds. ? 2016 Red Hat, Inc. All rights reserved. 100 East Davie Street Raleigh, NC 27601 [f5][twitter.png] [f6][facebook.png] [f7][redhat.png] References f1. http://www.redhat.com/apps/webform.html?event_type=contact_sales&eid=21 f2. https://www.redhat.com/wapps/ugc/email-subscriptions.html?elqc=241&elq=e4e3dfa78bfb4bd39275ddd0b4186a55 f3. http://www.redhat.com/legal/privacy_statement.html f4. https://www.redhat.com/wapps/ugc/master-unsubscribe.html?elqc=241&elq=e4e3dfa78bfb4bd39275ddd0b4186a55 f5. http://www.twitter.com/redhatnews f6. http://www.facebook.com/pages/Red-Hat/11218770329 f7. http://www.redhat.com/community/?sc_cid=70160000000I9TnAAK -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Thu Oct 26 14:16:57 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Thu, 26 Oct 2017 16:16:57 +0200 Subject: [feedhenry-dev] RFC: Release process for the Ansible Playbook Bundles (APBs) In-Reply-To: References: Message-ID: folks, I've issued a first version of the release target: https://github.com/feedhenry/3scale-apb/pull/15 On Wed, Oct 25, 2017 at 11:48 AM, Matthias Wessendorf wrote: > >> For automation, we could use a little script like: >> >> ```bash >> version="0.0.7-rc" >> >> latest_commit="$(git rev-parse HEAD)" | git tag -a ${version} >> ${latest_commit=} -m "signing tag" && git push origin ${version} >> ``` >> > > > One more thought/comment. The "origin" does not ultimately fly - since > folks could have renamed it to upstream etc. So, IMO that should be also a > variable. > > More advanced tools, like the awesome maven-release-plugin, leverages that > information from some SCM metadata in the pom.xml file: > https://github.com/aerogear/aerogear-unifiedpush-server/ > blob/master/pom.xml#L35-L40 > > But that's perhaps a bit of overhead here ;-) So my initial vote would > be make the name of the origin also configurable > > Thoughts ? > -M > > > > -- > Project lead AeroGear.org > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From lgriffin at redhat.com Thu Oct 26 14:18:15 2017 From: lgriffin at redhat.com (Leigh Griffin) Date: Thu, 26 Oct 2017 15:18:15 +0100 Subject: [feedhenry-dev] RFC: MCP-standalone Release Process In-Reply-To: References: Message-ID: Just want to throw it out there that the XML Licenser is going to be a requirement here. It's not a painful step in the above that you described but it's a step nonetheless. So if our code is anything outside of Java (maven based) or Node.js we might need to consider building a tool to create the licensing information or reach out wider to find a team already in flight on it. On Thu, Oct 26, 2017 at 11:23 AM, David Martin wrote: > Those release steps sound logical to me. > > It allows getting all apbs and the mcp version locked down so it can be > tested and shared. > > As its mostly scripted already, it's setting us up nicely for automating > the entire upstream release process. > > Having the various git repos tagged too is important to allow for > downstream productisation, and identifying when changes or bugs get > introduced > > > > On 26 October 2017 at 08:52, Matthias Wessendorf > wrote: > >> >> >> On Thu, Oct 26, 2017 at 9:43 AM, Phil Brookes >> wrote: >> >>> Hey Matthias, >>> >>> Now, the (three) dependent APBs of the MCP also need to be released. >>>> This requires a bit of manual steps, as described here: >>>> https://github.com/matzew/mcp-standalone/blob/Release_Proces >>>> s/docs/Release.md#mcp-included-apbs >>>> >>>> 1) manual modify the openshift template (which is included in the >>>> dependent APBs) >>>> 2) creating image tags and pushing all to dockerhub (-> make apbs ) >>>> >>> >>> If the APBs that are currently included in the mcp-standalone repo were >>> in their own separate repos (just like keycloak, 3scale, etc are currently) >>> would that remove the requirement for these manual steps? >>> >> >> no - these three guys (android, ios, cordova) are special ABPs :-) They >> are MCPs, and they need the updated template. >> With a separated repo, they would each need a PR to get the updated >> version. >> >> >> >>> ? I think it would be superior if we could have a standard workflow >>> that all APBs follow, rather than some APBs working one way and some >>> working another and requiring developers to remember which is which. >>> >> >> So yeah, I think these three are a bit special :) >> >> BTW. yesterday on IRC Craig suggested at our F2F in a couple of weeks we >> all sit down and discuss a good approach for this. He mentione kubernetes, >> where different things are in their own repos, but sync'd to the main one >> (no damn gitsubmodules) >> >> >> >>> >>> >>> Regards, >>> >>> Phil.? >>> >>> >>> >>> >>> On Wed, Oct 25, 2017 at 7:20 PM, Matthias Wessendorf < >>> mwessend at redhat.com> wrote: >>> >>>> Hi, >>>> >>>> as a follow up on [1], here are some thoughts on the MCP release itself. >>>> >>>> The raw process is described here: >>>> https://github.com/matzew/mcp-standalone/blob/Release_Proces >>>> s/docs/Release.md#mcp-release >>>> >>>> The first part is trivial (but not complete), we simply create a TAGGED >>>> (versioned) image, and push it to docker. Afterwards the mcp-standalone in >>>> dockerhub is updated. >>>> >>>> What's missing here is creation of a canonical TAG in git, more later; >>>> >>>> Now, the (three) dependent APBs of the MCP also need to be released. >>>> This requires a bit of manual steps, as described here: >>>> https://github.com/matzew/mcp-standalone/blob/Release_Proces >>>> s/docs/Release.md#mcp-included-apbs >>>> >>>> 1) manual modify the openshift template (which is included in the >>>> dependent APBs) >>>> 2) creating image tags and pushing all to dockerhub (-> make apbs ) >>>> >>>> >>>> In 2) we also modify code, by copying the template over, for that I've >>>> added a "release" commit in the Makefile target: >>>> https://github.com/matzew/mcp-standalone/commit/8d693cc6b2d5 >>>> 8d9a2d83e33ea6cf9e31ce8bcac5 >>>> >>>> But we still have a locally modified file on the disk (the original >>>> openshift template). This is bad. >>>> The changes to the template must be committed before we can actually >>>> move on. To enforce that, I've added the following to the "make apbs" >>>> target: >>>> https://github.com/feedhenry/mcp-standalone/commit/260fd8686 >>>> 8e7d12fb33197bf1ca9672a2f7d4b1a#commitcomment-25186889 >>>> >>>> if there are not committed files, the "make apbs" fails- this is >>>> inspired by the awesome ;-) Maven Release Plugin. >>>> >>>> As the last step, after the different pushes to dockerhub >>>> (mcp-standalone and its dependent APBs), we must create a release tag in >>>> git, and push it. >>>> >>>> Only with these "rules" (e.g. no locally modified files, and proper >>>> release tags, we end up having both in sync dockerhub images, and the >>>> matching TAG in git) >>>> >>>> I think these new rules help to get a more solid release, and with a >>>> bit of work can be applied by some "release script" >>>> >>>> But before hacking too much, I am generally interested in feedback on >>>> these already committed changes. >>>> >>>> Thanks! >>>> Matthias >>>> >>>> >>>> [1] https://www.redhat.com/archives/feedhenry-dev/2017-Octob >>>> er/msg00114.html >>>> >>>> >>>> -- >>>> Project lead AeroGear.org >>>> >>>> _______________________________________________ >>>> feedhenry-dev mailing list >>>> feedhenry-dev at redhat.com >>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>> >>>> >>> >> >> >> -- >> Project lead AeroGear.org >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > > -- > David Martin > Red Hat Mobile > Twitter: @irldavem > IRC: @irldavem (feedhenry, mobile-internal) > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- LEIGH GRIFFIN ENGINEERING MANAGER, MOBILE Red Hat Ireland Communications House, Cork Road Waterford City, Ireland X91NY33 lgriffin at redhat.com M: +353877545162 IM: lgriffin TRIED. TESTED. TRUSTED. @redhatway @redhatinc @redhatsnaps -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Thu Oct 26 14:31:09 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Thu, 26 Oct 2017 16:31:09 +0200 Subject: [feedhenry-dev] RFC: MCP-standalone Release Process In-Reply-To: References: Message-ID: ok, that's good info, I guess for MCP standalone developing this tool is a bit complex, but than I dont know enough about "package mgmt" w/ Go On Thu, Oct 26, 2017 at 4:18 PM, Leigh Griffin wrote: > Just want to throw it out there that the XML Licenser is going to be a > requirement here. It's not a painful step in the above that you described > but it's a step nonetheless. So if our code is anything outside of Java > (maven based) or Node.js we might need to consider building a tool to > create the licensing information or reach out wider to find a team already > in flight on it. > > On Thu, Oct 26, 2017 at 11:23 AM, David Martin > wrote: > >> Those release steps sound logical to me. >> >> It allows getting all apbs and the mcp version locked down so it can be >> tested and shared. >> >> As its mostly scripted already, it's setting us up nicely for automating >> the entire upstream release process. >> >> Having the various git repos tagged too is important to allow for >> downstream productisation, and identifying when changes or bugs get >> introduced >> >> >> >> On 26 October 2017 at 08:52, Matthias Wessendorf >> wrote: >> >>> >>> >>> On Thu, Oct 26, 2017 at 9:43 AM, Phil Brookes >>> wrote: >>> >>>> Hey Matthias, >>>> >>>> Now, the (three) dependent APBs of the MCP also need to be released. >>>>> This requires a bit of manual steps, as described here: >>>>> https://github.com/matzew/mcp-standalone/blob/Release_Proces >>>>> s/docs/Release.md#mcp-included-apbs >>>>> >>>>> 1) manual modify the openshift template (which is included in the >>>>> dependent APBs) >>>>> 2) creating image tags and pushing all to dockerhub (-> make apbs ) >>>>> >>>> >>>> If the APBs that are currently included in the mcp-standalone repo were >>>> in their own separate repos (just like keycloak, 3scale, etc are currently) >>>> would that remove the requirement for these manual steps? >>>> >>> >>> no - these three guys (android, ios, cordova) are special ABPs :-) They >>> are MCPs, and they need the updated template. >>> With a separated repo, they would each need a PR to get the updated >>> version. >>> >>> >>> >>>> ? I think it would be superior if we could have a standard workflow >>>> that all APBs follow, rather than some APBs working one way and some >>>> working another and requiring developers to remember which is which. >>>> >>> >>> So yeah, I think these three are a bit special :) >>> >>> BTW. yesterday on IRC Craig suggested at our F2F in a couple of weeks we >>> all sit down and discuss a good approach for this. He mentione kubernetes, >>> where different things are in their own repos, but sync'd to the main one >>> (no damn gitsubmodules) >>> >>> >>> >>>> >>>> >>>> Regards, >>>> >>>> Phil.? >>>> >>>> >>>> >>>> >>>> On Wed, Oct 25, 2017 at 7:20 PM, Matthias Wessendorf < >>>> mwessend at redhat.com> wrote: >>>> >>>>> Hi, >>>>> >>>>> as a follow up on [1], here are some thoughts on the MCP release >>>>> itself. >>>>> >>>>> The raw process is described here: >>>>> https://github.com/matzew/mcp-standalone/blob/Release_Proces >>>>> s/docs/Release.md#mcp-release >>>>> >>>>> The first part is trivial (but not complete), we simply create a >>>>> TAGGED (versioned) image, and push it to docker. Afterwards the >>>>> mcp-standalone in dockerhub is updated. >>>>> >>>>> What's missing here is creation of a canonical TAG in git, more later; >>>>> >>>>> Now, the (three) dependent APBs of the MCP also need to be released. >>>>> This requires a bit of manual steps, as described here: >>>>> https://github.com/matzew/mcp-standalone/blob/Release_Proces >>>>> s/docs/Release.md#mcp-included-apbs >>>>> >>>>> 1) manual modify the openshift template (which is included in the >>>>> dependent APBs) >>>>> 2) creating image tags and pushing all to dockerhub (-> make apbs ) >>>>> >>>>> >>>>> In 2) we also modify code, by copying the template over, for that I've >>>>> added a "release" commit in the Makefile target: >>>>> https://github.com/matzew/mcp-standalone/commit/8d693cc6b2d5 >>>>> 8d9a2d83e33ea6cf9e31ce8bcac5 >>>>> >>>>> But we still have a locally modified file on the disk (the original >>>>> openshift template). This is bad. >>>>> The changes to the template must be committed before we can actually >>>>> move on. To enforce that, I've added the following to the "make apbs" >>>>> target: >>>>> https://github.com/feedhenry/mcp-standalone/commit/260fd8686 >>>>> 8e7d12fb33197bf1ca9672a2f7d4b1a#commitcomment-25186889 >>>>> >>>>> if there are not committed files, the "make apbs" fails- this is >>>>> inspired by the awesome ;-) Maven Release Plugin. >>>>> >>>>> As the last step, after the different pushes to dockerhub >>>>> (mcp-standalone and its dependent APBs), we must create a release tag in >>>>> git, and push it. >>>>> >>>>> Only with these "rules" (e.g. no locally modified files, and proper >>>>> release tags, we end up having both in sync dockerhub images, and the >>>>> matching TAG in git) >>>>> >>>>> I think these new rules help to get a more solid release, and with a >>>>> bit of work can be applied by some "release script" >>>>> >>>>> But before hacking too much, I am generally interested in feedback on >>>>> these already committed changes. >>>>> >>>>> Thanks! >>>>> Matthias >>>>> >>>>> >>>>> [1] https://www.redhat.com/archives/feedhenry-dev/2017-Octob >>>>> er/msg00114.html >>>>> >>>>> >>>>> -- >>>>> Project lead AeroGear.org >>>>> >>>>> _______________________________________________ >>>>> feedhenry-dev mailing list >>>>> feedhenry-dev at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>>> >>>>> >>>> >>> >>> >>> -- >>> Project lead AeroGear.org >>> >>> _______________________________________________ >>> feedhenry-dev mailing list >>> feedhenry-dev at redhat.com >>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>> >>> >> >> >> -- >> David Martin >> Red Hat Mobile >> Twitter: @irldavem >> IRC: @irldavem (feedhenry, mobile-internal) >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > > -- > > LEIGH GRIFFIN > > ENGINEERING MANAGER, MOBILE > > Red Hat Ireland > > Communications House, Cork Road > > Waterford City, Ireland X91NY33 > > lgriffin at redhat.com M: +353877545162 IM: lgriffin > > TRIED. TESTED. TRUSTED. > > @redhatway @redhatinc > @redhatsnaps > > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Thu Oct 26 14:31:27 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Thu, 26 Oct 2017 16:31:27 +0200 Subject: [feedhenry-dev] RFC: MCP-standalone Release Process In-Reply-To: References: Message-ID: on the APBs, that's likely simpler :) On Thu, Oct 26, 2017 at 4:31 PM, Matthias Wessendorf wrote: > ok, > > that's good info, I guess for MCP standalone developing this tool is a bit > complex, but than I dont know enough about "package mgmt" w/ Go > > > > > > > On Thu, Oct 26, 2017 at 4:18 PM, Leigh Griffin > wrote: > >> Just want to throw it out there that the XML Licenser is going to be a >> requirement here. It's not a painful step in the above that you described >> but it's a step nonetheless. So if our code is anything outside of Java >> (maven based) or Node.js we might need to consider building a tool to >> create the licensing information or reach out wider to find a team already >> in flight on it. >> >> On Thu, Oct 26, 2017 at 11:23 AM, David Martin >> wrote: >> >>> Those release steps sound logical to me. >>> >>> It allows getting all apbs and the mcp version locked down so it can be >>> tested and shared. >>> >>> As its mostly scripted already, it's setting us up nicely for automating >>> the entire upstream release process. >>> >>> Having the various git repos tagged too is important to allow for >>> downstream productisation, and identifying when changes or bugs get >>> introduced >>> >>> >>> >>> On 26 October 2017 at 08:52, Matthias Wessendorf >>> wrote: >>> >>>> >>>> >>>> On Thu, Oct 26, 2017 at 9:43 AM, Phil Brookes >>>> wrote: >>>> >>>>> Hey Matthias, >>>>> >>>>> Now, the (three) dependent APBs of the MCP also need to be released. >>>>>> This requires a bit of manual steps, as described here: >>>>>> https://github.com/matzew/mcp-standalone/blob/Release_Proces >>>>>> s/docs/Release.md#mcp-included-apbs >>>>>> >>>>>> 1) manual modify the openshift template (which is included in the >>>>>> dependent APBs) >>>>>> 2) creating image tags and pushing all to dockerhub (-> make apbs ) >>>>>> >>>>> >>>>> If the APBs that are currently included in the mcp-standalone repo >>>>> were in their own separate repos (just like keycloak, 3scale, etc are >>>>> currently) would that remove the requirement for these manual steps? >>>>> >>>> >>>> no - these three guys (android, ios, cordova) are special ABPs :-) They >>>> are MCPs, and they need the updated template. >>>> With a separated repo, they would each need a PR to get the updated >>>> version. >>>> >>>> >>>> >>>>> ? I think it would be superior if we could have a standard workflow >>>>> that all APBs follow, rather than some APBs working one way and some >>>>> working another and requiring developers to remember which is which. >>>>> >>>> >>>> So yeah, I think these three are a bit special :) >>>> >>>> BTW. yesterday on IRC Craig suggested at our F2F in a couple of weeks >>>> we all sit down and discuss a good approach for this. He mentione >>>> kubernetes, where different things are in their own repos, but sync'd to >>>> the main one (no damn gitsubmodules) >>>> >>>> >>>> >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Phil.? >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Oct 25, 2017 at 7:20 PM, Matthias Wessendorf < >>>>> mwessend at redhat.com> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> as a follow up on [1], here are some thoughts on the MCP release >>>>>> itself. >>>>>> >>>>>> The raw process is described here: >>>>>> https://github.com/matzew/mcp-standalone/blob/Release_Proces >>>>>> s/docs/Release.md#mcp-release >>>>>> >>>>>> The first part is trivial (but not complete), we simply create a >>>>>> TAGGED (versioned) image, and push it to docker. Afterwards the >>>>>> mcp-standalone in dockerhub is updated. >>>>>> >>>>>> What's missing here is creation of a canonical TAG in git, more later; >>>>>> >>>>>> Now, the (three) dependent APBs of the MCP also need to be released. >>>>>> This requires a bit of manual steps, as described here: >>>>>> https://github.com/matzew/mcp-standalone/blob/Release_Proces >>>>>> s/docs/Release.md#mcp-included-apbs >>>>>> >>>>>> 1) manual modify the openshift template (which is included in the >>>>>> dependent APBs) >>>>>> 2) creating image tags and pushing all to dockerhub (-> make apbs ) >>>>>> >>>>>> >>>>>> In 2) we also modify code, by copying the template over, for that >>>>>> I've added a "release" commit in the Makefile target: >>>>>> https://github.com/matzew/mcp-standalone/commit/8d693cc6b2d5 >>>>>> 8d9a2d83e33ea6cf9e31ce8bcac5 >>>>>> >>>>>> But we still have a locally modified file on the disk (the original >>>>>> openshift template). This is bad. >>>>>> The changes to the template must be committed before we can actually >>>>>> move on. To enforce that, I've added the following to the "make apbs" >>>>>> target: >>>>>> https://github.com/feedhenry/mcp-standalone/commit/260fd8686 >>>>>> 8e7d12fb33197bf1ca9672a2f7d4b1a#commitcomment-25186889 >>>>>> >>>>>> if there are not committed files, the "make apbs" fails- this is >>>>>> inspired by the awesome ;-) Maven Release Plugin. >>>>>> >>>>>> As the last step, after the different pushes to dockerhub >>>>>> (mcp-standalone and its dependent APBs), we must create a release tag in >>>>>> git, and push it. >>>>>> >>>>>> Only with these "rules" (e.g. no locally modified files, and proper >>>>>> release tags, we end up having both in sync dockerhub images, and the >>>>>> matching TAG in git) >>>>>> >>>>>> I think these new rules help to get a more solid release, and with a >>>>>> bit of work can be applied by some "release script" >>>>>> >>>>>> But before hacking too much, I am generally interested in feedback on >>>>>> these already committed changes. >>>>>> >>>>>> Thanks! >>>>>> Matthias >>>>>> >>>>>> >>>>>> [1] https://www.redhat.com/archives/feedhenry-dev/2017-Octob >>>>>> er/msg00114.html >>>>>> >>>>>> >>>>>> -- >>>>>> Project lead AeroGear.org >>>>>> >>>>>> _______________________________________________ >>>>>> feedhenry-dev mailing list >>>>>> feedhenry-dev at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Project lead AeroGear.org >>>> >>>> _______________________________________________ >>>> feedhenry-dev mailing list >>>> feedhenry-dev at redhat.com >>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>> >>>> >>> >>> >>> -- >>> David Martin >>> Red Hat Mobile >>> Twitter: @irldavem >>> IRC: @irldavem (feedhenry, mobile-internal) >>> >>> _______________________________________________ >>> feedhenry-dev mailing list >>> feedhenry-dev at redhat.com >>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>> >>> >> >> >> -- >> >> LEIGH GRIFFIN >> >> ENGINEERING MANAGER, MOBILE >> >> Red Hat Ireland >> >> Communications House, Cork Road >> >> Waterford City, Ireland X91NY33 >> >> lgriffin at redhat.com M: +353877545162 IM: lgriffin >> >> TRIED. TESTED. TRUSTED. >> >> @redhatway @redhatinc >> @redhatsnaps >> >> > > > > -- > Project lead AeroGear.org > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Fri Oct 27 06:45:11 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Fri, 27 Oct 2017 08:45:11 +0200 Subject: [feedhenry-dev] size of openshift ? Message-ID: Hi, I had like 15 GB of data in here: /var/lib/origin/openshift.local.pv/registry/docker/registry/v2/blobs/sha256 wondering.... if that is never cleaned up, or does one run a scipt ? -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From gryan at redhat.com Fri Oct 27 07:35:13 2017 From: gryan at redhat.com (Gerard Ryan) Date: Fri, 27 Oct 2017 09:35:13 +0200 Subject: [feedhenry-dev] RFC: MCP-standalone Release Process In-Reply-To: (Leigh Griffin's message of "Thu, 26 Oct 2017 15:18:15 +0100") References: Message-ID: <878tfxf3gu.fsf@thinkpad.grdryn.redhat> Leigh Griffin writes: > Just want to throw it out there that the XML Licenser is going to be a > requirement here. It's not a painful step in the above that you described > but it's a step nonetheless. So if our code is anything outside of Java > (maven based) or Node.js we might need to consider building a tool to > create the licensing information or reach out wider to find a team already > in flight on it. Would that just be needed for the eventual Red Hat productization of it, or is it also needed for the open source releases here? In any case, I'd expect that other projects that Red Hat productizes downstream, that are also Go projects, would also have this requirement, right (e.g. OpenShift)? Whatever they're using, would ideally be reused here, rather than each of us creating our own way of doing it. From mwessend at redhat.com Fri Oct 27 08:40:07 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Fri, 27 Oct 2017 10:40:07 +0200 Subject: [feedhenry-dev] RFC: MCP-standalone Release Process In-Reply-To: <878tfxf3gu.fsf@thinkpad.grdryn.redhat> References: <878tfxf3gu.fsf@thinkpad.grdryn.redhat> Message-ID: On Fri, Oct 27, 2017 at 9:35 AM, Gerard Ryan wrote: > Leigh Griffin writes: > > > Just want to throw it out there that the XML Licenser is going to be a > > requirement here. It's not a painful step in the above that you described > > but it's a step nonetheless. So if our code is anything outside of Java > > (maven based) or Node.js we might need to consider building a tool to > > create the licensing information or reach out wider to find a team > already > > in flight on it. > > Would that just be needed for the eventual Red Hat productization of it, > or is it also needed for the open source releases here? > OpenSource communities do that too, here a few examples of our own: * https://github.com/keycloak/keycloak/pull/4491 * https://github.com/aerogear/aerogear-unifiedpush-server/pull/937 the second example is inspired by the release process of the ASF, requiring "LICENSE", "DEPENDENCIES" and "NOTICE" file as part of the (binary) artifact. and a first step into what EAP does (for product) > > In any case, I'd expect that other projects that Red Hat productizes > downstream, that are also Go projects, would also have this requirement, > right (e.g. OpenShift)? yep, I was wondering that too, what they have > Whatever they're using, would ideally be reused > here, rather than each of us creating our own way of doing it. > +1000 I started a little thread on the apb repo: https://github.com/ansibleplaybookbundle/ansible-playbook-bundle/issues/154 > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From davmarti at redhat.com Fri Oct 27 08:59:41 2017 From: davmarti at redhat.com (David Martin) Date: Fri, 27 Oct 2017 09:59:41 +0100 Subject: [feedhenry-dev] size of openshift ? In-Reply-To: References: Message-ID: I'm not aware of anything in 'oc cluster' that cleans up the pvs. For the mcp local setup, the directory is different so that the clean script can clean up those dirs. It's $MCP_DIR/ui/openshift-pvs https://github.com/feedhenry/mcp-standalone/blob/master/ui/clean.sh#L12-L16 On 27 October 2017 at 07:45, Matthias Wessendorf wrote: > Hi, > > I had like 15 GB of data in here: > /var/lib/origin/openshift.local.pv/registry/docker/ > registry/v2/blobs/sha256 > > wondering.... if that is never cleaned up, or does one run a scipt ? > > -- > Project lead AeroGear.org > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From gryan at redhat.com Fri Oct 27 09:18:00 2017 From: gryan at redhat.com (Gerard Ryan) Date: Fri, 27 Oct 2017 11:18:00 +0200 Subject: [feedhenry-dev] size of openshift ? In-Reply-To: (Matthias Wessendorf's message of "Fri, 27 Oct 2017 08:45:11 +0200") References: Message-ID: <87a80ddk53.fsf@thinkpad.grdryn.redhat> Matthias Wessendorf writes: > Hi, > > I had like 15 GB of data in here: > /var/lib/origin/openshift.local.pv/registry/docker/registry/v2/blobs/sha256 > > wondering.... if that is never cleaned up, or does one run a scipt ? Any idea why the space grows so large? This might not be relevant, but if it's accumulating image/container layers for builds from BuildConfigs over time, there are new properties you can add to the BuildConfigSpec to limit the number of builds that will be kept, namely 'successfulBuildsHistoryLimit' and 'failedBuildsHistoryLimit'. E.g. like we do here: https://github.com/feedhenry/fh-pipeline-library/blob/eb60354b4d9fb06db4134ef3cd9cb87fc5f74a7f/vars/buildWithDockerStrategy.groovy#L20..L21 From mwessend at redhat.com Fri Oct 27 09:57:22 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Fri, 27 Oct 2017 11:57:22 +0200 Subject: [feedhenry-dev] size of openshift ? In-Reply-To: <87a80ddk53.fsf@thinkpad.grdryn.redhat> References: <87a80ddk53.fsf@thinkpad.grdryn.redhat> Message-ID: On Fri, Oct 27, 2017 at 11:18 AM, Gerard Ryan wrote: > Matthias Wessendorf writes: > > > Hi, > > > > I had like 15 GB of data in here: > > /var/lib/origin/openshift.local.pv/registry/docker/ > registry/v2/blobs/sha256 > > > > wondering.... if that is never cleaned up, or does one run a scipt ? > > Any idea why the space grows so large? > Big data! ;-) > > This might not be relevant, but if it's accumulating image/container > layers for builds from BuildConfigs over time, there are new properties > you can add to the BuildConfigSpec to limit the number of builds that > will be kept, namely 'successfulBuildsHistoryLimit' and > 'failedBuildsHistoryLimit'. > > E.g. like we do here: > https://github.com/feedhenry/fh-pipeline-library/blob/ > eb60354b4d9fb06db4134ef3cd9cb87fc5f74a7f/vars/buildWithDockerStrategy. > groovy#L20..L21 ah, that could be handy - thanks -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Fri Oct 27 18:16:17 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Fri, 27 Oct 2017 20:16:17 +0200 Subject: [feedhenry-dev] [MCP] Openshift Origin 3.7.0-rc.0 Message-ID: Hola, more as a FYI, but I just saw that there is a new release for Openshift Origin: https://github.com/openshift/origin/releases/tag/v3.7.0-rc.0 -M -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From cbrookes at redhat.com Tue Oct 31 15:43:47 2017 From: cbrookes at redhat.com (Craig Brookes) Date: Tue, 31 Oct 2017 15:43:47 +0000 Subject: [feedhenry-dev] topics for mcp team discussions at f2f Message-ID: Two main things I would like to discuss at the f2f. Wondering if there are others: - Discuss release process further, plus build process (expanding on usage of travis for e2e tests etc) - Discuss moving all mcp related materials into single repo and syncing to other apb repos (similar to how k8 is handled) Some other points for discussion: - Targeting Kubernetes for the upstream. Advantages and disadvantages (we have some pieces that are OpenShift dependent: builds, build-configs) but not a huge amount. -- Craig Brookes RHMAP @maleck13 Github -------------- next part -------------- An HTML attachment was scrubbed... URL: