[feedhenry-dev] feedhenry-dev Digest, Vol 16, Issue 44

Mon Oct 16 10:50:58 UTC 2017

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 <cbrookes at redhat.com> 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, <feedhenry-dev-request at redhat.com>
> 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 <wtrocki at redhat.com>
>> To: John Frizelle <jfrizell at redhat.com>
>> 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:
>>         <CAO0+n+qPHtihDGut-cRqigT9b8zaeemLu1r-wCB5q+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 <jfrizell at redhat.com>
>> 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 <//+353872901644>*
>> > twitter:* @johnfriz*
>> > skype: *john_frizelle*
>> > mail: *jfrizell at redhat.com <jfrizell at redhat.com>*
>> >
>> >
>> >
>> >
>> > On 16 October 2017 at 09:57, David Martin <davmarti at redhat.com> 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 <wtrocki at redhat.com>
>> wrote:
>> >>
>> >>> Hi lads
>> >>>
>> >>> I'm representing RainCatcher team.  <http://raincatcher.feedhenry.io/
>> >
>> >>> 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 <https://www.redhat.com/>
>>
>> IM: wtrocki
>> <https://red.ht/sig>
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <https://www.redhat.com/archives/feedhenry-dev/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: <https://www.redhat.com/archives/feedhenry-dev/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
>
> _______________________________________________
> feedhenry-dev mailing list
> feedhenry-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/feedhenry-dev
>
>

-- 

WOJCIECH TROCKI

Red Hat Mobile <https://www.redhat.com/>

IM: wtrocki
<https://red.ht/sig>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/feedhenry-dev/attachments/20171016/bc257c37/attachment.htm>