Re: Reducing Barriers to Entry for New Contributors WAS [ Re: GSoC 2018: Fineract CN SMS & Email Notifications]

[Ed Cable]

Aleks,

Could you givean update to everybody on where we stand with this and if
you're blocked, what assistance you need to get unblocked. This demo server
infrastructure is critical for several of our interns and the work they're
doing so the sooner we can have it in place, the better.

Thanks for all your efforts on this,

Ed

On Mon, May 21, 2018 at 7:37 AM Aleksandar Vidakovic <
chee...@monkeysintown.com> wrote:

> Ok, will keep you posted
>
> On Mon, May 21, 2018 at 4:19 PM Ed Cable  wrote:
>
> > Aleks,
> >
> > The VM is now up as you probably saw from the ticket in on Infra. Chris
> > provided this link for getting sudo access:
> > https://reference.apache.org/committer/opie
> >
> > Please update community on your progress as a number of interns are eager
> > to have this available in order to test out the work they're undertaking.
> >
> > Ed
> >
> > On Tue, May 8, 2018 at 2:54 AM Aleksandar Vidakovic <
> > chee...@monkeysintown.com> wrote:
> >
> > > Thanks Isaac... I'll have a look at it tonight
> > >
> > > On Mon, May 7, 2018, 1:02 PM Isaac Kamga 
> wrote:
> > >
> > > > Hi Alexsandar Vikakovic,
> > > >
> > > > Kindly take a look at this request for the Apache Fineract CN Ubuntu
> VM
> > > > <
> > >
> >
> https://cwiki.apache.org/confluence/display/FINERACT/Requesting+An+Ubuntu+VM+For+Apache+Fineract+CN
> > >
> > > so
> > > > you polish it to provide more concrete specifications to the Apache
> > > > Infrastructure team as required
> > > > .
> > > >
> > > > Myrle and/or Ed can give you the right karma for collaboration on
> > > > confluence.
> > > >
> > > > At Your Service,
> > > > Isaac Kamga.
> > > >
> > > >
> > > >
> > > > On Fri, Apr 6, 2018 at 8:11 AM, Courage Angeh <
> couragean...@gmail.com>
> > > > wrote:
> > > >
> > > >> Ok. Thanks Myrle. I will look into those links
> > > >>
> > > >> On Thu, Apr 5, 2018, 1:48 PM Myrle Krantz  wrote:
> > > >>
> > > >> > Hi Courage,
> > > >> >
> > > >> > On Thu, Mar 29, 2018 at 4:11 PM, Courage Angeh <
> > > couragean...@gmail.com>
> > > >> > wrote:
> > > >> > > The domain microservices rely on Lang microservice to generate
> RSA
> > > >> keys.
> > > >> > > Lang microservice serves a library like Cassandra and Async
> > > >> > microservices.
> > > >> > > I understand why relying on another program to start is not good
> > but
> > > >> > that's
> > > >> > > not the only dependency here.
> > > >> > >
> > > >> > > Nevertheless my proposal is we update each microservice not to
> > > >> generate
> > > >> > an
> > > >> > > RSA key but to get it from the Lang microservice
> > > >> >
> > > >> > Lang is not a microservice, it's a library.  There is no single
> > > >> > instance of it running.  Instead, it is included in all the
> > > >> > microservices.  Each microservice instance (and therefore each
> lang
> > > >> > instance) will see only it's own data.  Lang does not have global
> > > >> > data, it only has service local data.  If we were to create global
> > > >> > data that each instance of lang accesses, we would risk making
> > > >> > downtime-free upgrades impossible in the future.
> > > >> >
> > > >> > For an understanding of how keys are exchanged and used, this
> > > >> > documentation may help:
> > > >> >
> > > >> >
> > > >>
> > >
> >
> https://cwiki.apache.org/confluence/display/FINERACT/Fineract+CN+demo-server
> > > >> >
> > > >> > If you want to understand how we design for downtime-free
> upgrades,
> > > >> > this documentation may help:
> > > >> >
> > > >> >
> > > >>
> > >
> >
> https://cwiki.apache.org/confluence/display/FINERACT/Composing+a+Release+out+of+Microservices
> > > >> >
> > > >> > Best Regards,
> > > >> > Myrle
> > > >> >
> > > >>
> > > >
> > > >
> > >
> >
> >
> > --
> > *Ed Cable*
> > President/CEO, Mifos Initiative
> > edca...@mifos.org | Skype: edcable | Mobile: +1.484.477.8649
> > <+1%20484-477-8649>
> >
> > *Collectively Creating a World of 3 Billion Maries | *http://mifos.org
> >   
> >
>


-- 
*Ed Cable*
President/CEO, Mifos Initiative
edca...@mifos.org | Skype: edcable | Mobile: +1.484.477.8649

*Collectively Creating a World of 3 Billion Maries | *http://mifos.org
  

Re: Reducing Barriers to Entry for New Contributors WAS [ Re: GSoC 2018: Fineract CN SMS & Email Notifications]

[Aleksandar Vidakovic]

Ok, will keep you posted

On Mon, May 21, 2018 at 4:19 PM Ed Cable  wrote:

> Aleks,
>
> The VM is now up as you probably saw from the ticket in on Infra. Chris
> provided this link for getting sudo access:
> https://reference.apache.org/committer/opie
>
> Please update community on your progress as a number of interns are eager
> to have this available in order to test out the work they're undertaking.
>
> Ed
>
> On Tue, May 8, 2018 at 2:54 AM Aleksandar Vidakovic <
> chee...@monkeysintown.com> wrote:
>
> > Thanks Isaac... I'll have a look at it tonight
> >
> > On Mon, May 7, 2018, 1:02 PM Isaac Kamga  wrote:
> >
> > > Hi Alexsandar Vikakovic,
> > >
> > > Kindly take a look at this request for the Apache Fineract CN Ubuntu VM
> > > <
> >
> https://cwiki.apache.org/confluence/display/FINERACT/Requesting+An+Ubuntu+VM+For+Apache+Fineract+CN
> >
> > so
> > > you polish it to provide more concrete specifications to the Apache
> > > Infrastructure team as required
> > > .
> > >
> > > Myrle and/or Ed can give you the right karma for collaboration on
> > > confluence.
> > >
> > > At Your Service,
> > > Isaac Kamga.
> > >
> > >
> > >
> > > On Fri, Apr 6, 2018 at 8:11 AM, Courage Angeh 
> > > wrote:
> > >
> > >> Ok. Thanks Myrle. I will look into those links
> > >>
> > >> On Thu, Apr 5, 2018, 1:48 PM Myrle Krantz  wrote:
> > >>
> > >> > Hi Courage,
> > >> >
> > >> > On Thu, Mar 29, 2018 at 4:11 PM, Courage Angeh <
> > couragean...@gmail.com>
> > >> > wrote:
> > >> > > The domain microservices rely on Lang microservice to generate RSA
> > >> keys.
> > >> > > Lang microservice serves a library like Cassandra and Async
> > >> > microservices.
> > >> > > I understand why relying on another program to start is not good
> but
> > >> > that's
> > >> > > not the only dependency here.
> > >> > >
> > >> > > Nevertheless my proposal is we update each microservice not to
> > >> generate
> > >> > an
> > >> > > RSA key but to get it from the Lang microservice
> > >> >
> > >> > Lang is not a microservice, it's a library.  There is no single
> > >> > instance of it running.  Instead, it is included in all the
> > >> > microservices.  Each microservice instance (and therefore each lang
> > >> > instance) will see only it's own data.  Lang does not have global
> > >> > data, it only has service local data.  If we were to create global
> > >> > data that each instance of lang accesses, we would risk making
> > >> > downtime-free upgrades impossible in the future.
> > >> >
> > >> > For an understanding of how keys are exchanged and used, this
> > >> > documentation may help:
> > >> >
> > >> >
> > >>
> >
> https://cwiki.apache.org/confluence/display/FINERACT/Fineract+CN+demo-server
> > >> >
> > >> > If you want to understand how we design for downtime-free upgrades,
> > >> > this documentation may help:
> > >> >
> > >> >
> > >>
> >
> https://cwiki.apache.org/confluence/display/FINERACT/Composing+a+Release+out+of+Microservices
> > >> >
> > >> > Best Regards,
> > >> > Myrle
> > >> >
> > >>
> > >
> > >
> >
>
>
> --
> *Ed Cable*
> President/CEO, Mifos Initiative
> edca...@mifos.org | Skype: edcable | Mobile: +1.484.477.8649
> <+1%20484-477-8649>
>
> *Collectively Creating a World of 3 Billion Maries | *http://mifos.org
>   
>

Re: Reducing Barriers to Entry for New Contributors WAS [ Re: GSoC 2018: Fineract CN SMS & Email Notifications]

[Ed Cable]

Aleks,

The VM is now up as you probably saw from the ticket in on Infra. Chris
provided this link for getting sudo access:
https://reference.apache.org/committer/opie

Please update community on your progress as a number of interns are eager
to have this available in order to test out the work they're undertaking.

Ed

On Tue, May 8, 2018 at 2:54 AM Aleksandar Vidakovic <
chee...@monkeysintown.com> wrote:

> Thanks Isaac... I'll have a look at it tonight
>
> On Mon, May 7, 2018, 1:02 PM Isaac Kamga  wrote:
>
> > Hi Alexsandar Vikakovic,
> >
> > Kindly take a look at this request for the Apache Fineract CN Ubuntu VM
> > <
> https://cwiki.apache.org/confluence/display/FINERACT/Requesting+An+Ubuntu+VM+For+Apache+Fineract+CN>
> so
> > you polish it to provide more concrete specifications to the Apache
> > Infrastructure team as required
> > .
> >
> > Myrle and/or Ed can give you the right karma for collaboration on
> > confluence.
> >
> > At Your Service,
> > Isaac Kamga.
> >
> >
> >
> > On Fri, Apr 6, 2018 at 8:11 AM, Courage Angeh 
> > wrote:
> >
> >> Ok. Thanks Myrle. I will look into those links
> >>
> >> On Thu, Apr 5, 2018, 1:48 PM Myrle Krantz  wrote:
> >>
> >> > Hi Courage,
> >> >
> >> > On Thu, Mar 29, 2018 at 4:11 PM, Courage Angeh <
> couragean...@gmail.com>
> >> > wrote:
> >> > > The domain microservices rely on Lang microservice to generate RSA
> >> keys.
> >> > > Lang microservice serves a library like Cassandra and Async
> >> > microservices.
> >> > > I understand why relying on another program to start is not good but
> >> > that's
> >> > > not the only dependency here.
> >> > >
> >> > > Nevertheless my proposal is we update each microservice not to
> >> generate
> >> > an
> >> > > RSA key but to get it from the Lang microservice
> >> >
> >> > Lang is not a microservice, it's a library.  There is no single
> >> > instance of it running.  Instead, it is included in all the
> >> > microservices.  Each microservice instance (and therefore each lang
> >> > instance) will see only it's own data.  Lang does not have global
> >> > data, it only has service local data.  If we were to create global
> >> > data that each instance of lang accesses, we would risk making
> >> > downtime-free upgrades impossible in the future.
> >> >
> >> > For an understanding of how keys are exchanged and used, this
> >> > documentation may help:
> >> >
> >> >
> >>
> https://cwiki.apache.org/confluence/display/FINERACT/Fineract+CN+demo-server
> >> >
> >> > If you want to understand how we design for downtime-free upgrades,
> >> > this documentation may help:
> >> >
> >> >
> >>
> https://cwiki.apache.org/confluence/display/FINERACT/Composing+a+Release+out+of+Microservices
> >> >
> >> > Best Regards,
> >> > Myrle
> >> >
> >>
> >
> >
>


-- 
*Ed Cable*
President/CEO, Mifos Initiative
edca...@mifos.org | Skype: edcable | Mobile: +1.484.477.8649

*Collectively Creating a World of 3 Billion Maries | *http://mifos.org
  

Re: Reducing Barriers to Entry for New Contributors WAS [ Re: GSoC 2018: Fineract CN SMS & Email Notifications]

[Aleksandar Vidakovic]

Thanks Isaac... I'll have a look at it tonight

On Mon, May 7, 2018, 1:02 PM Isaac Kamga  wrote:

> Hi Alexsandar Vikakovic,
>
> Kindly take a look at this request for the Apache Fineract CN Ubuntu VM
> 
>  so
> you polish it to provide more concrete specifications to the Apache
> Infrastructure team as required
> .
>
> Myrle and/or Ed can give you the right karma for collaboration on
> confluence.
>
> At Your Service,
> Isaac Kamga.
>
>
>
> On Fri, Apr 6, 2018 at 8:11 AM, Courage Angeh 
> wrote:
>
>> Ok. Thanks Myrle. I will look into those links
>>
>> On Thu, Apr 5, 2018, 1:48 PM Myrle Krantz  wrote:
>>
>> > Hi Courage,
>> >
>> > On Thu, Mar 29, 2018 at 4:11 PM, Courage Angeh 
>> > wrote:
>> > > The domain microservices rely on Lang microservice to generate RSA
>> keys.
>> > > Lang microservice serves a library like Cassandra and Async
>> > microservices.
>> > > I understand why relying on another program to start is not good but
>> > that's
>> > > not the only dependency here.
>> > >
>> > > Nevertheless my proposal is we update each microservice not to
>> generate
>> > an
>> > > RSA key but to get it from the Lang microservice
>> >
>> > Lang is not a microservice, it's a library.  There is no single
>> > instance of it running.  Instead, it is included in all the
>> > microservices.  Each microservice instance (and therefore each lang
>> > instance) will see only it's own data.  Lang does not have global
>> > data, it only has service local data.  If we were to create global
>> > data that each instance of lang accesses, we would risk making
>> > downtime-free upgrades impossible in the future.
>> >
>> > For an understanding of how keys are exchanged and used, this
>> > documentation may help:
>> >
>> >
>> https://cwiki.apache.org/confluence/display/FINERACT/Fineract+CN+demo-server
>> >
>> > If you want to understand how we design for downtime-free upgrades,
>> > this documentation may help:
>> >
>> >
>> https://cwiki.apache.org/confluence/display/FINERACT/Composing+a+Release+out+of+Microservices
>> >
>> > Best Regards,
>> > Myrle
>> >
>>
>
>

Re: Reducing Barriers to Entry for New Contributors WAS [ Re: GSoC 2018: Fineract CN SMS & Email Notifications]

[Isaac Kamga]

Hi Alexsandar Vikakovic,

Kindly take a look at this request for the Apache Fineract CN Ubuntu VM

so
you polish it to provide more concrete specifications to the Apache
Infrastructure team as required
.

Myrle and/or Ed can give you the right karma for collaboration on
confluence.

At Your Service,
Isaac Kamga.



On Fri, Apr 6, 2018 at 8:11 AM, Courage Angeh 
wrote:

> Ok. Thanks Myrle. I will look into those links
>
> On Thu, Apr 5, 2018, 1:48 PM Myrle Krantz  wrote:
>
> > Hi Courage,
> >
> > On Thu, Mar 29, 2018 at 4:11 PM, Courage Angeh 
> > wrote:
> > > The domain microservices rely on Lang microservice to generate RSA
> keys.
> > > Lang microservice serves a library like Cassandra and Async
> > microservices.
> > > I understand why relying on another program to start is not good but
> > that's
> > > not the only dependency here.
> > >
> > > Nevertheless my proposal is we update each microservice not to generate
> > an
> > > RSA key but to get it from the Lang microservice
> >
> > Lang is not a microservice, it's a library.  There is no single
> > instance of it running.  Instead, it is included in all the
> > microservices.  Each microservice instance (and therefore each lang
> > instance) will see only it's own data.  Lang does not have global
> > data, it only has service local data.  If we were to create global
> > data that each instance of lang accesses, we would risk making
> > downtime-free upgrades impossible in the future.
> >
> > For an understanding of how keys are exchanged and used, this
> > documentation may help:
> >
> > https://cwiki.apache.org/confluence/display/FINERACT/
> Fineract+CN+demo-server
> >
> > If you want to understand how we design for downtime-free upgrades,
> > this documentation may help:
> >
> > https://cwiki.apache.org/confluence/display/FINERACT/
> Composing+a+Release+out+of+Microservices
> >
> > Best Regards,
> > Myrle
> >
>

Re: Reducing Barriers to Entry for New Contributors WAS [ Re: GSoC 2018: Fineract CN SMS & Email Notifications]

[Courage Angeh]

Ok. Thanks Myrle. I will look into those links

On Thu, Apr 5, 2018, 1:48 PM Myrle Krantz  wrote:

> Hi Courage,
>
> On Thu, Mar 29, 2018 at 4:11 PM, Courage Angeh 
> wrote:
> > The domain microservices rely on Lang microservice to generate RSA keys.
> > Lang microservice serves a library like Cassandra and Async
> microservices.
> > I understand why relying on another program to start is not good but
> that's
> > not the only dependency here.
> >
> > Nevertheless my proposal is we update each microservice not to generate
> an
> > RSA key but to get it from the Lang microservice
>
> Lang is not a microservice, it's a library.  There is no single
> instance of it running.  Instead, it is included in all the
> microservices.  Each microservice instance (and therefore each lang
> instance) will see only it's own data.  Lang does not have global
> data, it only has service local data.  If we were to create global
> data that each instance of lang accesses, we would risk making
> downtime-free upgrades impossible in the future.
>
> For an understanding of how keys are exchanged and used, this
> documentation may help:
>
> https://cwiki.apache.org/confluence/display/FINERACT/Fineract+CN+demo-server
>
> If you want to understand how we design for downtime-free upgrades,
> this documentation may help:
>
> https://cwiki.apache.org/confluence/display/FINERACT/Composing+a+Release+out+of+Microservices
>
> Best Regards,
> Myrle
>

Re: Reducing Barriers to Entry for New Contributors WAS [ Re: GSoC 2018: Fineract CN SMS & Email Notifications]

[Myrle Krantz]

Hi Courage,

On Thu, Mar 29, 2018 at 4:11 PM, Courage Angeh  wrote:
> The domain microservices rely on Lang microservice to generate RSA keys.
> Lang microservice serves a library like Cassandra and Async microservices.
> I understand why relying on another program to start is not good but that's
> not the only dependency here.
>
> Nevertheless my proposal is we update each microservice not to generate an
> RSA key but to get it from the Lang microservice

Lang is not a microservice, it's a library.  There is no single
instance of it running.  Instead, it is included in all the
microservices.  Each microservice instance (and therefore each lang
instance) will see only it's own data.  Lang does not have global
data, it only has service local data.  If we were to create global
data that each instance of lang accesses, we would risk making
downtime-free upgrades impossible in the future.

For an understanding of how keys are exchanged and used, this
documentation may help:
https://cwiki.apache.org/confluence/display/FINERACT/Fineract+CN+demo-server

If you want to understand how we design for downtime-free upgrades,
this documentation may help:
https://cwiki.apache.org/confluence/display/FINERACT/Composing+a+Release+out+of+Microservices

Best Regards,
Myrle

Re: Reducing Barriers to Entry for New Contributors WAS [ Re: GSoC 2018: Fineract CN SMS & Email Notifications]

[Courage Angeh]

Hi Viswa,

The domain microservices rely on Lang microservice to generate RSA keys.
Lang microservice serves a library like Cassandra and Async microservices.
I understand why relying on another program to start is not good but that's
not the only dependency here.

Nevertheless my proposal is we update each microservice not to generate an
RSA key but to get it from the Lang microservice

Thanks,
Courage

On Tue, Mar 27, 2018 at 10:23 AM, Viswa Ramamoorthy <
viswaramamoor...@yahoo.com> wrote:

> Hi,
>
> Spring boot applications should be starting by itself with configurations.
> Relying on another program to start is not good.
>
> My proposal to add RSA key creation from within services is pretty simple;
> we will reuse existing utility 'RsaKeyPairFactory' to create keys. It will
> not be intrusive and it can be done quickly. New changes that I propose can
> be made optional with a Spring configuration that can enable it.
>
> It helps with development in laptop/desktop as well. For example, with
> changes for RSA included in fineract-cn-provisioner, I could start
> infrastructures (ActiveMQ, Eureka, Cassandra and MariaDB) as Docker
> containers using my earlier PR and start fineract-cn-provisioner as a
> Spring boot app and work on it, debug it, start it using an IDE like Spring
> STS etc
>
> Regards
> Viswa
>
> On ‎Monday‎, ‎March‎ ‎26‎, ‎2018‎ ‎08‎:‎49‎:‎43‎ ‎AM‎ ‎EDT, Courage Angeh <
> couragean...@gmail.com> wrote:
>
>
> Hi Viswa,
>
> I agree with you about Demo Server being largely oriented towards a quick
> use but it has a lot of useful data. I have gone through demo server too
> and I see they introduce RSA keys through external properties so I was
> thinking changing all the microservices will be a little more stressful, we
> could pass external properties to it when running the different jar files.
> True talk about Eureka, I am trying to work on that too.
> But I was thinking we don't need that much scripts and we don't have to
> change too much.
> I wrote a proposal about this for a GSOC project,
> https://docs.google.com/document/d/1zp6CeYP6ox51tGSu1fE9cBAWpaQnq
> jeBBVIa-n0evso/edit?usp=sharing
> , could you check it out? I will be delighted to get you point of view and
> comments about this doc :)
>
> Thanks Courage
>
> On Sat, Mar 24, 2018 at 1:06 PM, Viswa Ramamoorthy <
> viswaramamoor...@yahoo.com.invalid> wrote:
>
> >  Hello,
> > I think services need more work to get to deployable state. Demo server
> is
> > largely oriented towards a quick use in laptops/desktops but using Junit
> to
> > bootsrap services may result in inconsistencies.
> > I have been reviewing for sometime now. Based on my review, below are the
> > changes needed to get to deployment in a VM
> > 1. Currently services need RSA key to bootstrap. That is fine. But there
> > is no self acquire mode to get them deployed to environments like demo
> > envs.  a) Ideally a spring configured (say demo config) can be
> > introduced to self acquire RSA keys to continue with service start.
> > b) With this change, we could just start services using spring boot jar
> > with a configuration property at the time of service start up  c) I
> > have tried this change in my laptop for fineract-cn-provisioner. I can
> > raise a PR. Needs to be propagated to other services
> > 2. Eureka registration and renewal is bit flaky. Needs work on self
> > registration front as well as health indicator front. Spring has tooling
> on
> > this front. We just need to add and configure.
> > 3. Develop scripts to start services. Simple shell scripts good enough at
> > this point.a) One use case is to build/deploy for use in VMb)
> > Another use case is to facilitate selective service launch approach that
> > was alluding to a while back. For example, if some one needs to work on
> > 'accounting' services and depends on 'customer' services, they could
> bring
> > up 'customer' along with infrastructures using shell scripts (to be
> > developed) and continue with development in accounting.
> > 4. Deploy basic infrastructure needed for services - Eureka, ActiveMQ,
> > Cassandra and MariaDB. These can be Dockers and I already sent PR on this
> > front.
> > Proposal is to create a new repo to have build/deployment scripts stored
> > to get this used in VM and support laptop use cases to help with
> > development.
> > I can help/guide as needed.
> >
> > RegardsViswa Ramamoorthy
> >On ‎Friday‎, ‎March‎ ‎23‎, ‎2018‎ ‎06‎:‎52‎:‎27‎ ‎AM‎ ‎EDT, Isaac
> > Kamga  wrote:
> >
> >  Hi Ed,
> >
> > I am willing to assist in configuring the VM requested for Apache
> Fineract
> > CN.
> >
> > I don't have all the required skills but with commitment and some
> > mentorship, this up and running within a few weeks.
> >
> > At Your Service,
> > Isaac Kamga.
> >
> >
> >
> >
> >
> > On Thu, Mar 22, 2018 at 10:17 PM, Ed Cable  wrote:
> >
> > > Committers,
> > >
> > > We need a committer who can assist in configuring the VM we've
> requested
> > > for a public de

Re: Reducing Barriers to Entry for New Contributors WAS [ Re: GSoC 2018: Fineract CN SMS & Email Notifications]

[Courage Angeh]

Okay.

Thanks

On Wed, Mar 28, 2018 at 7:59 PM, Ed Cable  wrote:

> Thanks Courage for sharing that proposal. We'll keep you posted as GSOC
> proposals get evaluated.
>
> Ed
>
> On Mon, Mar 26, 2018 at 3:27 AM, Courage Angeh 
> wrote:
>
> > Hi Viswa,
> >
> > I agree with you about Demo Server being largely oriented towards a quick
> > use but it has a lot of useful data. I have gone through demo server too
> > and I see they introduce RSA keys through external properties so I was
> > thinking changing all the microservices will be a little more stressful,
> we
> > could pass external properties to it when running the different jar
> files.
> > True talk about Eureka, I am trying to work on that too.
> > But I was thinking we don't need that much scripts and we don't have to
> > change too much.
> > I wrote a proposal about this for a GSOC project,
> > https://docs.google.com/document/d/1zp6CeYP6ox51tGSu1fE9cBAWpaQnq
> > jeBBVIa-n0evso/edit?usp=sharing
> > , could you check it out? I will be delighted to get you point of view
> and
> > comments about this doc :)
> >
> > Thanks Courage
> >
> > On Sat, Mar 24, 2018 at 1:06 PM, Viswa Ramamoorthy <
> > viswaramamoor...@yahoo.com.invalid> wrote:
> >
> > >  Hello,
> > > I think services need more work to get to deployable state. Demo server
> > is
> > > largely oriented towards a quick use in laptops/desktops but using
> Junit
> > to
> > > bootsrap services may result in inconsistencies.
> > > I have been reviewing for sometime now. Based on my review, below are
> the
> > > changes needed to get to deployment in a VM
> > > 1. Currently services need RSA key to bootstrap. That is fine. But
> there
> > > is no self acquire mode to get them deployed to environments like demo
> > > envs.   a) Ideally a spring configured (say demo config) can be
> > > introduced to self acquire RSA keys to continue with service start.
> > > b) With this change, we could just start services using spring boot jar
> > > with a configuration property at the time of service start up   c)
> I
> > > have tried this change in my laptop for fineract-cn-provisioner. I can
> > > raise a PR. Needs to be propagated to other services
> > > 2. Eureka registration and renewal is bit flaky. Needs work on self
> > > registration front as well as health indicator front. Spring has
> tooling
> > on
> > > this front. We just need to add and configure.
> > > 3. Develop scripts to start services. Simple shell scripts good enough
> at
> > > this point. a) One use case is to build/deploy for use in VM b)
> > > Another use case is to facilitate selective service launch approach
> that
> > > was alluding to a while back. For example, if some one needs to work on
> > > 'accounting' services and depends on 'customer' services, they could
> > bring
> > > up 'customer' along with infrastructures using shell scripts (to be
> > > developed) and continue with development in accounting.
> > > 4. Deploy basic infrastructure needed for services - Eureka, ActiveMQ,
> > > Cassandra and MariaDB. These can be Dockers and I already sent PR on
> this
> > > front.
> > > Proposal is to create a new repo to have build/deployment scripts
> stored
> > > to get this used in VM and support laptop use cases to help with
> > > development.
> > > I can help/guide as needed.
> > >
> > > RegardsViswa Ramamoorthy
> > > On ‎Friday‎, ‎March‎ ‎23‎, ‎2018‎ ‎06‎:‎52‎:‎27‎ ‎AM‎ ‎EDT, Isaac
> > > Kamga  wrote:
> > >
> > >  Hi Ed,
> > >
> > > I am willing to assist in configuring the VM requested for Apache
> > Fineract
> > > CN.
> > >
> > > I don't have all the required skills but with commitment and some
> > > mentorship, this up and running within a few weeks.
> > >
> > > At Your Service,
> > > Isaac Kamga.
> > >
> > >
> > >
> > >
> > >
> > > On Thu, Mar 22, 2018 at 10:17 PM, Ed Cable  wrote:
> > >
> > > > Committers,
> > > >
> > > > We need a committer who can assist in configuring the VM we've
> > requested
> > > > for a public demo server for Apache Fineract CN.  The massive
> hardware
> > > > requirements to build locally have made this a huge barrier to
> > > prospective
> > > > GSOC applicants. We were trying to get this infrastructure set up but
> > > don't
> > > > have anybody with committer status who've raised their hands to
> > configure
> > > > the VM that Apache infrastructure is providing us.
> > > >
> > > > If you're able to, please respond to this thread and jump on to
> comment
> > > > thread on the Apache Infrastructure ticket at
> > > > https://issues.apache.org/jira/browse/INFRA-16203
> > > >
> > > > Thanks,
> > > >
> > > > Ed
> > > >
> > > > On Thu, Mar 22, 2018 at 1:54 PM, Ed Cable  wrote:
> > > >
> > > > > Aleks,
> > > > >
> > > > > Apache IDs are only available to committers. The guide to becoming
> a
> > > > > committer is at https://cwiki.apache.org/
> > confluence/display/FINERACT/
> > > > Beco
> > > > > ming+a+Committer
> > > > >
> > > > > I know that the major body of your work related to Finerac

Re: Reducing Barriers to Entry for New Contributors WAS [ Re: GSoC 2018: Fineract CN SMS & Email Notifications]

[Viswa Ramamoorthy]

 I was commenting on a bare minimum spec that Ed was alluding to. With minimum 
spec (4/16/100), current services (looks like about 12) and 4 infrastructure 
can be deployed. Typically service start up contributes to higher cpu use. 
After that really usage and data flow drives cpu usage/memory.
I agree that having a 8 core/32 GB/250 GB hard drive would be comfortable and 
will help if more new services added.

On ‎Thursday‎, ‎March‎ ‎29‎, ‎2018‎ ‎01‎:‎35‎:‎32‎ ‎AM‎ ‎EDT, Awasum 
Yannick  wrote:  
 
 Hello All,

Isaac and Viswa, I agree with all what you say.

I use an i7 Processor with 32 GB RAM and 250 GB SSD for testing. Given we
might be running ActiveMQ, Cassandra and MySQL/Mariadb.
Nginx will likely be running fims-web-app. And given there will be
instances when demo server is running along with the containerization tests
which might run over the next 6 months, I think the above specs might just
work for us.  What do you think?


Thanks.


On Thu, Mar 29, 2018 at 4:52 AM, Isaac Kamga  wrote:

> Hello Ed,
>
> On Thu, Mar 29, 2018 at 12:27 AM Viswa Ramamoorthy <
> viswaramamoor...@yahoo.com> wrote:
>
> > For the services currently available (as started by demo server), I
> > estimate 4 core/16 GB/100 GB would be minimum needed.
> >
>
> Viswa, I agree with most of these specifications but I think 4 Cores won't
> run demo-server without unnecessary timeouts. I think we need at least 8
> processors there. What do you think ?
>
>
> >
> > On ‎Wednesday‎, ‎March‎ ‎28‎, ‎2018‎ ‎03‎:‎05‎:‎12‎ ‎PM‎ ‎EDT, Ed Cable <
> > edca...@mifos.org> wrote:
> >
> >
> > As we discussed earlier, the work to set up and configure the demo server
> > on the Apache infrastructure needs to be carried out by committers.
> >
> > Fortunately, Nikhil, Rajan, and Isaac, all committers, have graciously
> > volunteered their time to assist. Can you all please provide your Apache
> > IDs on the issue at https://issues.apache.org/jira/browse/INFRA-16203 so
> > you can get the necessary access.
> >
>
> I have just commented on the issue about my ID.
>
>
> >
> > We will then discuss on this thread the needed steps to proceed forward.
> > However, before that, we need to answer some of the questions from Chris
> > about what base packages would need to be installed:
> https://goo.gl/iixSGX
> >
>
> I started compiling a document  on specifications
> for the VM. We could supplement it before continuing our request to the
> Apache Infra team.
>
>
> >
> >
> > Myrle, Viswa,
> >
> > Can we please solidify on the base packages, minimum specs this VM needs
> > for deployment of the Fineract CN demo server?
> >
> > Once we have established that, those individuals with the needed
> expertise
> > can assist the committers above who have volunteered to assist with this.
> >
> > Ed
> >
> > On Mon, Mar 26, 2018 at 3:27 AM, Courage Angeh 
> > wrote:
> >
> > > Hi Viswa,
> > >
> > > I agree with you about Demo Server being largely oriented towards a
> quick
> > > use but it has a lot of useful data. I have gone through demo server
> too
> > > and I see they introduce RSA keys through external properties so I was
> > > thinking changing all the microservices will be a little more
> stressful,
> > we
> > > could pass external properties to it when running the different jar
> > files.
> > > True talk about Eureka, I am trying to work on that too.
> > > But I was thinking we don't need that much scripts and we don't have to
> > > change too much.
> > > I wrote a proposal about this for a GSOC project,
> > > https://docs.google.com/document/d/1zp6CeYP6ox51tGSu1fE9cBAWpaQnq
> > > jeBBVIa-n0evso/edit?usp=sharing
> > > , could you check it out? I will be delighted to get you point of view
> > and
> > > comments about this doc :)
> > >
> > > Thanks Courage
> > >
> > > On Sat, Mar 24, 2018 at 1:06 PM, Viswa Ramamoorthy <
> > > viswaramamoor...@yahoo.com.invalid> wrote:
> > >
> > > >  Hello,
> > > > I think services need more work to get to deployable state. Demo
> server
> > > is
> > > > largely oriented towards a quick use in laptops/desktops but using
> > Junit
> > > to
> > > > bootsrap services may result in inconsistencies.
> > > > I have been reviewing for sometime now. Based on my review, below are
> > the
> > > > changes needed to get to deployment in a VM
> > > > 1. Currently services need RSA key to bootstrap. That is fine. But
> > there
> > > > is no self acquire mode to get them deployed to environments like
> demo
> > > > envs.      a) Ideally a spring configured (say demo config) can be
> > > > introduced to self acquire RSA keys to continue with service start.
> > > > b) With this change, we could just start services using spring boot
> jar
> > > > with a configuration property at the time of service start up
> c) I
> > > > have tried this change in my laptop for fineract-cn-provisioner. I
> can
> > > > raise a PR. Needs to be propagated to other services
> > > > 2. Eureka registration and renewal is bit flaky. Needs work on sel

Re: Reducing Barriers to Entry for New Contributors WAS [ Re: GSoC 2018: Fineract CN SMS & Email Notifications]

[Isaac Kamga]

Anyone interested in updating the Request to ASF

can sign into confluence and use the edit button on the top right hand
corner. Am I right about this Myrle ?

On Thu, Mar 29, 2018 at 8:12 AM, Isaac Kamga  wrote:

> Thanks for the reminder Myrle. I just moved the content to confluence here
> 
> .
>
> On Thu, Mar 29, 2018 at 7:59 AM, Myrle Krantz  wrote:
>
>> Hey Isaac,
>>
>> Can you move that content into confluence please?  That's our place
>> for documentation collaboration.  If you need additional guidance,
>> just ask.
>>
>> Best Regards,
>> Myrle
>>
>> On Thu, Mar 29, 2018 at 7:38 AM, Awasum Yannick 
>> wrote:
>> > Hey Isaac,
>> >
>> > I don't have permission to comment on your Fineract Infra doc above.
>> >
>> >
>> >
>> > On Thu, Mar 29, 2018 at 6:35 AM, Awasum Yannick 
>> wrote:
>> >
>> >> Hello All,
>> >>
>> >> Isaac and Viswa, I agree with all what you say.
>> >>
>> >> I use an i7 Processor with 32 GB RAM and 250 GB SSD for testing. Given
>> we
>> >> might be running ActiveMQ, Cassandra and MySQL/Mariadb.
>> >> Nginx will likely be running fims-web-app. And given there will be
>> >> instances when demo server is running along with the containerization
>> tests
>> >> which might run over the next 6 months, I think the above specs might
>> just
>> >> work for us.  What do you think?
>> >>
>> >>
>> >> Thanks.
>> >>
>> >>
>> >> On Thu, Mar 29, 2018 at 4:52 AM, Isaac Kamga 
>> >> wrote:
>> >>
>> >>> Hello Ed,
>> >>>
>> >>> On Thu, Mar 29, 2018 at 12:27 AM Viswa Ramamoorthy <
>> >>> viswaramamoor...@yahoo.com> wrote:
>> >>>
>> >>> > For the services currently available (as started by demo server), I
>> >>> > estimate 4 core/16 GB/100 GB would be minimum needed.
>> >>> >
>> >>>
>> >>> Viswa, I agree with most of these specifications but I think 4 Cores
>> won't
>> >>> run demo-server without unnecessary timeouts. I think we need at
>> least 8
>> >>> processors there. What do you think ?
>> >>>
>> >>>
>> >>> >
>> >>> > On ‎Wednesday‎, ‎March‎ ‎28‎, ‎2018‎ ‎03‎:‎05‎:‎12‎ ‎PM‎ ‎EDT, Ed
>> Cable
>> >>> <
>> >>> > edca...@mifos.org> wrote:
>> >>> >
>> >>> >
>> >>> > As we discussed earlier, the work to set up and configure the demo
>> >>> server
>> >>> > on the Apache infrastructure needs to be carried out by committers.
>> >>> >
>> >>> > Fortunately, Nikhil, Rajan, and Isaac, all committers, have
>> graciously
>> >>> > volunteered their time to assist. Can you all please provide your
>> Apache
>> >>> > IDs on the issue at https://issues.apache.org/jira
>> /browse/INFRA-16203
>> >>> so
>> >>> > you can get the necessary access.
>> >>> >
>> >>>
>> >>> I have just commented on the issue about my ID.
>> >>>
>> >>>
>> >>> >
>> >>> > We will then discuss on this thread the needed steps to proceed
>> forward.
>> >>> > However, before that, we need to answer some of the questions from
>> Chris
>> >>> > about what base packages would need to be installed:
>> >>> https://goo.gl/iixSGX
>> >>> >
>> >>>
>> >>> I started compiling a document  on
>> specifications
>> >>> for the VM. We could supplement it before continuing our request to
>> the
>> >>> Apache Infra team.
>> >>>
>> >>>
>> >>> >
>> >>> >
>> >>> > Myrle, Viswa,
>> >>> >
>> >>> > Can we please solidify on the base packages, minimum specs this VM
>> needs
>> >>> > for deployment of the Fineract CN demo server?
>> >>> >
>> >>> > Once we have established that, those individuals with the needed
>> >>> expertise
>> >>> > can assist the committers above who have volunteered to assist with
>> >>> this.
>> >>> >
>> >>> > Ed
>> >>> >
>> >>> > On Mon, Mar 26, 2018 at 3:27 AM, Courage Angeh <
>> couragean...@gmail.com>
>> >>> > wrote:
>> >>> >
>> >>> > > Hi Viswa,
>> >>> > >
>> >>> > > I agree with you about Demo Server being largely oriented towards
>> a
>> >>> quick
>> >>> > > use but it has a lot of useful data. I have gone through demo
>> server
>> >>> too
>> >>> > > and I see they introduce RSA keys through external properties so
>> I was
>> >>> > > thinking changing all the microservices will be a little more
>> >>> stressful,
>> >>> > we
>> >>> > > could pass external properties to it when running the different
>> jar
>> >>> > files.
>> >>> > > True talk about Eureka, I am trying to work on that too.
>> >>> > > But I was thinking we don't need that much scripts and we don't
>> have
>> >>> to
>> >>> > > change too much.
>> >>> > > I wrote a proposal about this for a GSOC project,
>> >>> > > https://docs.google.com/document/d/1zp6CeYP6ox51tGSu1fE9cBAWpaQnq
>> >>> > > jeBBVIa-n0evso/edit?usp=sharing
>> >>> > > , could you check it out? I will be delighted to get you point of
>> view
>> >>> > and
>> >>> > > comments about this doc :)
>> >>> > >
>> >>> > > Thanks Courage
>> >>> > >
>> >>> > > On Sat, Mar 24, 2018 at 1:06 PM, Viswa Ramamoorthy <
>> >

Re: Reducing Barriers to Entry for New Contributors WAS [ Re: GSoC 2018: Fineract CN SMS & Email Notifications]

[Isaac Kamga]

Thanks for the reminder Myrle. I just moved the content to confluence here

.

On Thu, Mar 29, 2018 at 7:59 AM, Myrle Krantz  wrote:

> Hey Isaac,
>
> Can you move that content into confluence please?  That's our place
> for documentation collaboration.  If you need additional guidance,
> just ask.
>
> Best Regards,
> Myrle
>
> On Thu, Mar 29, 2018 at 7:38 AM, Awasum Yannick  wrote:
> > Hey Isaac,
> >
> > I don't have permission to comment on your Fineract Infra doc above.
> >
> >
> >
> > On Thu, Mar 29, 2018 at 6:35 AM, Awasum Yannick 
> wrote:
> >
> >> Hello All,
> >>
> >> Isaac and Viswa, I agree with all what you say.
> >>
> >> I use an i7 Processor with 32 GB RAM and 250 GB SSD for testing. Given
> we
> >> might be running ActiveMQ, Cassandra and MySQL/Mariadb.
> >> Nginx will likely be running fims-web-app. And given there will be
> >> instances when demo server is running along with the containerization
> tests
> >> which might run over the next 6 months, I think the above specs might
> just
> >> work for us.  What do you think?
> >>
> >>
> >> Thanks.
> >>
> >>
> >> On Thu, Mar 29, 2018 at 4:52 AM, Isaac Kamga 
> >> wrote:
> >>
> >>> Hello Ed,
> >>>
> >>> On Thu, Mar 29, 2018 at 12:27 AM Viswa Ramamoorthy <
> >>> viswaramamoor...@yahoo.com> wrote:
> >>>
> >>> > For the services currently available (as started by demo server), I
> >>> > estimate 4 core/16 GB/100 GB would be minimum needed.
> >>> >
> >>>
> >>> Viswa, I agree with most of these specifications but I think 4 Cores
> won't
> >>> run demo-server without unnecessary timeouts. I think we need at least
> 8
> >>> processors there. What do you think ?
> >>>
> >>>
> >>> >
> >>> > On ‎Wednesday‎, ‎March‎ ‎28‎, ‎2018‎ ‎03‎:‎05‎:‎12‎ ‎PM‎ ‎EDT, Ed
> Cable
> >>> <
> >>> > edca...@mifos.org> wrote:
> >>> >
> >>> >
> >>> > As we discussed earlier, the work to set up and configure the demo
> >>> server
> >>> > on the Apache infrastructure needs to be carried out by committers.
> >>> >
> >>> > Fortunately, Nikhil, Rajan, and Isaac, all committers, have
> graciously
> >>> > volunteered their time to assist. Can you all please provide your
> Apache
> >>> > IDs on the issue at https://issues.apache.org/
> jira/browse/INFRA-16203
> >>> so
> >>> > you can get the necessary access.
> >>> >
> >>>
> >>> I have just commented on the issue about my ID.
> >>>
> >>>
> >>> >
> >>> > We will then discuss on this thread the needed steps to proceed
> forward.
> >>> > However, before that, we need to answer some of the questions from
> Chris
> >>> > about what base packages would need to be installed:
> >>> https://goo.gl/iixSGX
> >>> >
> >>>
> >>> I started compiling a document  on
> specifications
> >>> for the VM. We could supplement it before continuing our request to the
> >>> Apache Infra team.
> >>>
> >>>
> >>> >
> >>> >
> >>> > Myrle, Viswa,
> >>> >
> >>> > Can we please solidify on the base packages, minimum specs this VM
> needs
> >>> > for deployment of the Fineract CN demo server?
> >>> >
> >>> > Once we have established that, those individuals with the needed
> >>> expertise
> >>> > can assist the committers above who have volunteered to assist with
> >>> this.
> >>> >
> >>> > Ed
> >>> >
> >>> > On Mon, Mar 26, 2018 at 3:27 AM, Courage Angeh <
> couragean...@gmail.com>
> >>> > wrote:
> >>> >
> >>> > > Hi Viswa,
> >>> > >
> >>> > > I agree with you about Demo Server being largely oriented towards a
> >>> quick
> >>> > > use but it has a lot of useful data. I have gone through demo
> server
> >>> too
> >>> > > and I see they introduce RSA keys through external properties so I
> was
> >>> > > thinking changing all the microservices will be a little more
> >>> stressful,
> >>> > we
> >>> > > could pass external properties to it when running the different jar
> >>> > files.
> >>> > > True talk about Eureka, I am trying to work on that too.
> >>> > > But I was thinking we don't need that much scripts and we don't
> have
> >>> to
> >>> > > change too much.
> >>> > > I wrote a proposal about this for a GSOC project,
> >>> > > https://docs.google.com/document/d/1zp6CeYP6ox51tGSu1fE9cBAWpaQnq
> >>> > > jeBBVIa-n0evso/edit?usp=sharing
> >>> > > , could you check it out? I will be delighted to get you point of
> view
> >>> > and
> >>> > > comments about this doc :)
> >>> > >
> >>> > > Thanks Courage
> >>> > >
> >>> > > On Sat, Mar 24, 2018 at 1:06 PM, Viswa Ramamoorthy <
> >>> > > viswaramamoor...@yahoo.com.invalid> wrote:
> >>> > >
> >>> > > >  Hello,
> >>> > > > I think services need more work to get to deployable state. Demo
> >>> server
> >>> > > is
> >>> > > > largely oriented towards a quick use in laptops/desktops but
> using
> >>> > Junit
> >>> > > to
> >>> > > > bootsrap services may result in inconsistencies.
> >>> > > > I have been reviewing for sometime now. Based on my review, below
> >>> are
> >>> > the
> >>> > > > changes needed to 

Re: Reducing Barriers to Entry for New Contributors WAS [ Re: GSoC 2018: Fineract CN SMS & Email Notifications]

[Myrle Krantz]

Hey Isaac,

Can you move that content into confluence please?  That's our place
for documentation collaboration.  If you need additional guidance,
just ask.

Best Regards,
Myrle

On Thu, Mar 29, 2018 at 7:38 AM, Awasum Yannick  wrote:
> Hey Isaac,
>
> I don't have permission to comment on your Fineract Infra doc above.
>
>
>
> On Thu, Mar 29, 2018 at 6:35 AM, Awasum Yannick  wrote:
>
>> Hello All,
>>
>> Isaac and Viswa, I agree with all what you say.
>>
>> I use an i7 Processor with 32 GB RAM and 250 GB SSD for testing. Given we
>> might be running ActiveMQ, Cassandra and MySQL/Mariadb.
>> Nginx will likely be running fims-web-app. And given there will be
>> instances when demo server is running along with the containerization tests
>> which might run over the next 6 months, I think the above specs might just
>> work for us.  What do you think?
>>
>>
>> Thanks.
>>
>>
>> On Thu, Mar 29, 2018 at 4:52 AM, Isaac Kamga 
>> wrote:
>>
>>> Hello Ed,
>>>
>>> On Thu, Mar 29, 2018 at 12:27 AM Viswa Ramamoorthy <
>>> viswaramamoor...@yahoo.com> wrote:
>>>
>>> > For the services currently available (as started by demo server), I
>>> > estimate 4 core/16 GB/100 GB would be minimum needed.
>>> >
>>>
>>> Viswa, I agree with most of these specifications but I think 4 Cores won't
>>> run demo-server without unnecessary timeouts. I think we need at least 8
>>> processors there. What do you think ?
>>>
>>>
>>> >
>>> > On ‎Wednesday‎, ‎March‎ ‎28‎, ‎2018‎ ‎03‎:‎05‎:‎12‎ ‎PM‎ ‎EDT, Ed Cable
>>> <
>>> > edca...@mifos.org> wrote:
>>> >
>>> >
>>> > As we discussed earlier, the work to set up and configure the demo
>>> server
>>> > on the Apache infrastructure needs to be carried out by committers.
>>> >
>>> > Fortunately, Nikhil, Rajan, and Isaac, all committers, have graciously
>>> > volunteered their time to assist. Can you all please provide your Apache
>>> > IDs on the issue at https://issues.apache.org/jira/browse/INFRA-16203
>>> so
>>> > you can get the necessary access.
>>> >
>>>
>>> I have just commented on the issue about my ID.
>>>
>>>
>>> >
>>> > We will then discuss on this thread the needed steps to proceed forward.
>>> > However, before that, we need to answer some of the questions from Chris
>>> > about what base packages would need to be installed:
>>> https://goo.gl/iixSGX
>>> >
>>>
>>> I started compiling a document  on specifications
>>> for the VM. We could supplement it before continuing our request to the
>>> Apache Infra team.
>>>
>>>
>>> >
>>> >
>>> > Myrle, Viswa,
>>> >
>>> > Can we please solidify on the base packages, minimum specs this VM needs
>>> > for deployment of the Fineract CN demo server?
>>> >
>>> > Once we have established that, those individuals with the needed
>>> expertise
>>> > can assist the committers above who have volunteered to assist with
>>> this.
>>> >
>>> > Ed
>>> >
>>> > On Mon, Mar 26, 2018 at 3:27 AM, Courage Angeh 
>>> > wrote:
>>> >
>>> > > Hi Viswa,
>>> > >
>>> > > I agree with you about Demo Server being largely oriented towards a
>>> quick
>>> > > use but it has a lot of useful data. I have gone through demo server
>>> too
>>> > > and I see they introduce RSA keys through external properties so I was
>>> > > thinking changing all the microservices will be a little more
>>> stressful,
>>> > we
>>> > > could pass external properties to it when running the different jar
>>> > files.
>>> > > True talk about Eureka, I am trying to work on that too.
>>> > > But I was thinking we don't need that much scripts and we don't have
>>> to
>>> > > change too much.
>>> > > I wrote a proposal about this for a GSOC project,
>>> > > https://docs.google.com/document/d/1zp6CeYP6ox51tGSu1fE9cBAWpaQnq
>>> > > jeBBVIa-n0evso/edit?usp=sharing
>>> > > , could you check it out? I will be delighted to get you point of view
>>> > and
>>> > > comments about this doc :)
>>> > >
>>> > > Thanks Courage
>>> > >
>>> > > On Sat, Mar 24, 2018 at 1:06 PM, Viswa Ramamoorthy <
>>> > > viswaramamoor...@yahoo.com.invalid> wrote:
>>> > >
>>> > > >  Hello,
>>> > > > I think services need more work to get to deployable state. Demo
>>> server
>>> > > is
>>> > > > largely oriented towards a quick use in laptops/desktops but using
>>> > Junit
>>> > > to
>>> > > > bootsrap services may result in inconsistencies.
>>> > > > I have been reviewing for sometime now. Based on my review, below
>>> are
>>> > the
>>> > > > changes needed to get to deployment in a VM
>>> > > > 1. Currently services need RSA key to bootstrap. That is fine. But
>>> > there
>>> > > > is no self acquire mode to get them deployed to environments like
>>> demo
>>> > > > envs.  a) Ideally a spring configured (say demo config) can be
>>> > > > introduced to self acquire RSA keys to continue with service start.
>>> > > > b) With this change, we could just start services using spring boot
>>> jar
>>> > > > with a configuration property at the time of service start up
>>> c) I
>>> > > > have tried this change in my laptop for fine

Re: Reducing Barriers to Entry for New Contributors WAS [ Re: GSoC 2018: Fineract CN SMS & Email Notifications]

[Awasum Yannick]

Hey Isaac,

I don't have permission to comment on your Fineract Infra doc above.



On Thu, Mar 29, 2018 at 6:35 AM, Awasum Yannick  wrote:

> Hello All,
>
> Isaac and Viswa, I agree with all what you say.
>
> I use an i7 Processor with 32 GB RAM and 250 GB SSD for testing. Given we
> might be running ActiveMQ, Cassandra and MySQL/Mariadb.
> Nginx will likely be running fims-web-app. And given there will be
> instances when demo server is running along with the containerization tests
> which might run over the next 6 months, I think the above specs might just
> work for us.  What do you think?
>
>
> Thanks.
>
>
> On Thu, Mar 29, 2018 at 4:52 AM, Isaac Kamga 
> wrote:
>
>> Hello Ed,
>>
>> On Thu, Mar 29, 2018 at 12:27 AM Viswa Ramamoorthy <
>> viswaramamoor...@yahoo.com> wrote:
>>
>> > For the services currently available (as started by demo server), I
>> > estimate 4 core/16 GB/100 GB would be minimum needed.
>> >
>>
>> Viswa, I agree with most of these specifications but I think 4 Cores won't
>> run demo-server without unnecessary timeouts. I think we need at least 8
>> processors there. What do you think ?
>>
>>
>> >
>> > On ‎Wednesday‎, ‎March‎ ‎28‎, ‎2018‎ ‎03‎:‎05‎:‎12‎ ‎PM‎ ‎EDT, Ed Cable
>> <
>> > edca...@mifos.org> wrote:
>> >
>> >
>> > As we discussed earlier, the work to set up and configure the demo
>> server
>> > on the Apache infrastructure needs to be carried out by committers.
>> >
>> > Fortunately, Nikhil, Rajan, and Isaac, all committers, have graciously
>> > volunteered their time to assist. Can you all please provide your Apache
>> > IDs on the issue at https://issues.apache.org/jira/browse/INFRA-16203
>> so
>> > you can get the necessary access.
>> >
>>
>> I have just commented on the issue about my ID.
>>
>>
>> >
>> > We will then discuss on this thread the needed steps to proceed forward.
>> > However, before that, we need to answer some of the questions from Chris
>> > about what base packages would need to be installed:
>> https://goo.gl/iixSGX
>> >
>>
>> I started compiling a document  on specifications
>> for the VM. We could supplement it before continuing our request to the
>> Apache Infra team.
>>
>>
>> >
>> >
>> > Myrle, Viswa,
>> >
>> > Can we please solidify on the base packages, minimum specs this VM needs
>> > for deployment of the Fineract CN demo server?
>> >
>> > Once we have established that, those individuals with the needed
>> expertise
>> > can assist the committers above who have volunteered to assist with
>> this.
>> >
>> > Ed
>> >
>> > On Mon, Mar 26, 2018 at 3:27 AM, Courage Angeh 
>> > wrote:
>> >
>> > > Hi Viswa,
>> > >
>> > > I agree with you about Demo Server being largely oriented towards a
>> quick
>> > > use but it has a lot of useful data. I have gone through demo server
>> too
>> > > and I see they introduce RSA keys through external properties so I was
>> > > thinking changing all the microservices will be a little more
>> stressful,
>> > we
>> > > could pass external properties to it when running the different jar
>> > files.
>> > > True talk about Eureka, I am trying to work on that too.
>> > > But I was thinking we don't need that much scripts and we don't have
>> to
>> > > change too much.
>> > > I wrote a proposal about this for a GSOC project,
>> > > https://docs.google.com/document/d/1zp6CeYP6ox51tGSu1fE9cBAWpaQnq
>> > > jeBBVIa-n0evso/edit?usp=sharing
>> > > , could you check it out? I will be delighted to get you point of view
>> > and
>> > > comments about this doc :)
>> > >
>> > > Thanks Courage
>> > >
>> > > On Sat, Mar 24, 2018 at 1:06 PM, Viswa Ramamoorthy <
>> > > viswaramamoor...@yahoo.com.invalid> wrote:
>> > >
>> > > >  Hello,
>> > > > I think services need more work to get to deployable state. Demo
>> server
>> > > is
>> > > > largely oriented towards a quick use in laptops/desktops but using
>> > Junit
>> > > to
>> > > > bootsrap services may result in inconsistencies.
>> > > > I have been reviewing for sometime now. Based on my review, below
>> are
>> > the
>> > > > changes needed to get to deployment in a VM
>> > > > 1. Currently services need RSA key to bootstrap. That is fine. But
>> > there
>> > > > is no self acquire mode to get them deployed to environments like
>> demo
>> > > > envs.  a) Ideally a spring configured (say demo config) can be
>> > > > introduced to self acquire RSA keys to continue with service start.
>> > > > b) With this change, we could just start services using spring boot
>> jar
>> > > > with a configuration property at the time of service start up
>> c) I
>> > > > have tried this change in my laptop for fineract-cn-provisioner. I
>> can
>> > > > raise a PR. Needs to be propagated to other services
>> > > > 2. Eureka registration and renewal is bit flaky. Needs work on self
>> > > > registration front as well as health indicator front. Spring has
>> > tooling
>> > > on
>> > > > this front. We just need to add and configure.
>> > > > 3. Develop scripts to start services. Simple sh

Re: Reducing Barriers to Entry for New Contributors WAS [ Re: GSoC 2018: Fineract CN SMS & Email Notifications]

[Awasum Yannick]

Hello All,

Isaac and Viswa, I agree with all what you say.

I use an i7 Processor with 32 GB RAM and 250 GB SSD for testing. Given we
might be running ActiveMQ, Cassandra and MySQL/Mariadb.
Nginx will likely be running fims-web-app. And given there will be
instances when demo server is running along with the containerization tests
which might run over the next 6 months, I think the above specs might just
work for us.  What do you think?


Thanks.


On Thu, Mar 29, 2018 at 4:52 AM, Isaac Kamga  wrote:

> Hello Ed,
>
> On Thu, Mar 29, 2018 at 12:27 AM Viswa Ramamoorthy <
> viswaramamoor...@yahoo.com> wrote:
>
> > For the services currently available (as started by demo server), I
> > estimate 4 core/16 GB/100 GB would be minimum needed.
> >
>
> Viswa, I agree with most of these specifications but I think 4 Cores won't
> run demo-server without unnecessary timeouts. I think we need at least 8
> processors there. What do you think ?
>
>
> >
> > On ‎Wednesday‎, ‎March‎ ‎28‎, ‎2018‎ ‎03‎:‎05‎:‎12‎ ‎PM‎ ‎EDT, Ed Cable <
> > edca...@mifos.org> wrote:
> >
> >
> > As we discussed earlier, the work to set up and configure the demo server
> > on the Apache infrastructure needs to be carried out by committers.
> >
> > Fortunately, Nikhil, Rajan, and Isaac, all committers, have graciously
> > volunteered their time to assist. Can you all please provide your Apache
> > IDs on the issue at https://issues.apache.org/jira/browse/INFRA-16203 so
> > you can get the necessary access.
> >
>
> I have just commented on the issue about my ID.
>
>
> >
> > We will then discuss on this thread the needed steps to proceed forward.
> > However, before that, we need to answer some of the questions from Chris
> > about what base packages would need to be installed:
> https://goo.gl/iixSGX
> >
>
> I started compiling a document  on specifications
> for the VM. We could supplement it before continuing our request to the
> Apache Infra team.
>
>
> >
> >
> > Myrle, Viswa,
> >
> > Can we please solidify on the base packages, minimum specs this VM needs
> > for deployment of the Fineract CN demo server?
> >
> > Once we have established that, those individuals with the needed
> expertise
> > can assist the committers above who have volunteered to assist with this.
> >
> > Ed
> >
> > On Mon, Mar 26, 2018 at 3:27 AM, Courage Angeh 
> > wrote:
> >
> > > Hi Viswa,
> > >
> > > I agree with you about Demo Server being largely oriented towards a
> quick
> > > use but it has a lot of useful data. I have gone through demo server
> too
> > > and I see they introduce RSA keys through external properties so I was
> > > thinking changing all the microservices will be a little more
> stressful,
> > we
> > > could pass external properties to it when running the different jar
> > files.
> > > True talk about Eureka, I am trying to work on that too.
> > > But I was thinking we don't need that much scripts and we don't have to
> > > change too much.
> > > I wrote a proposal about this for a GSOC project,
> > > https://docs.google.com/document/d/1zp6CeYP6ox51tGSu1fE9cBAWpaQnq
> > > jeBBVIa-n0evso/edit?usp=sharing
> > > , could you check it out? I will be delighted to get you point of view
> > and
> > > comments about this doc :)
> > >
> > > Thanks Courage
> > >
> > > On Sat, Mar 24, 2018 at 1:06 PM, Viswa Ramamoorthy <
> > > viswaramamoor...@yahoo.com.invalid> wrote:
> > >
> > > >  Hello,
> > > > I think services need more work to get to deployable state. Demo
> server
> > > is
> > > > largely oriented towards a quick use in laptops/desktops but using
> > Junit
> > > to
> > > > bootsrap services may result in inconsistencies.
> > > > I have been reviewing for sometime now. Based on my review, below are
> > the
> > > > changes needed to get to deployment in a VM
> > > > 1. Currently services need RSA key to bootstrap. That is fine. But
> > there
> > > > is no self acquire mode to get them deployed to environments like
> demo
> > > > envs.  a) Ideally a spring configured (say demo config) can be
> > > > introduced to self acquire RSA keys to continue with service start.
> > > > b) With this change, we could just start services using spring boot
> jar
> > > > with a configuration property at the time of service start up
> c) I
> > > > have tried this change in my laptop for fineract-cn-provisioner. I
> can
> > > > raise a PR. Needs to be propagated to other services
> > > > 2. Eureka registration and renewal is bit flaky. Needs work on self
> > > > registration front as well as health indicator front. Spring has
> > tooling
> > > on
> > > > this front. We just need to add and configure.
> > > > 3. Develop scripts to start services. Simple shell scripts good
> enough
> > at
> > > > this point.a) One use case is to build/deploy for use in VMb)
> > > > Another use case is to facilitate selective service launch approach
> > that
> > > > was alluding to a while back. For example, if some one needs to work
> on
> > > > 'accounting' servi

Re: Reducing Barriers to Entry for New Contributors WAS [ Re: GSoC 2018: Fineract CN SMS & Email Notifications]

[Isaac Kamga]

Hello Ed,

On Thu, Mar 29, 2018 at 12:27 AM Viswa Ramamoorthy <
viswaramamoor...@yahoo.com> wrote:

> For the services currently available (as started by demo server), I
> estimate 4 core/16 GB/100 GB would be minimum needed.
>

Viswa, I agree with most of these specifications but I think 4 Cores won't
run demo-server without unnecessary timeouts. I think we need at least 8
processors there. What do you think ?


>
> On ‎Wednesday‎, ‎March‎ ‎28‎, ‎2018‎ ‎03‎:‎05‎:‎12‎ ‎PM‎ ‎EDT, Ed Cable <
> edca...@mifos.org> wrote:
>
>
> As we discussed earlier, the work to set up and configure the demo server
> on the Apache infrastructure needs to be carried out by committers.
>
> Fortunately, Nikhil, Rajan, and Isaac, all committers, have graciously
> volunteered their time to assist. Can you all please provide your Apache
> IDs on the issue at https://issues.apache.org/jira/browse/INFRA-16203 so
> you can get the necessary access.
>

I have just commented on the issue about my ID.


>
> We will then discuss on this thread the needed steps to proceed forward.
> However, before that, we need to answer some of the questions from Chris
> about what base packages would need to be installed: https://goo.gl/iixSGX
>

I started compiling a document  on specifications
for the VM. We could supplement it before continuing our request to the
Apache Infra team.


>
>
> Myrle, Viswa,
>
> Can we please solidify on the base packages, minimum specs this VM needs
> for deployment of the Fineract CN demo server?
>
> Once we have established that, those individuals with the needed expertise
> can assist the committers above who have volunteered to assist with this.
>
> Ed
>
> On Mon, Mar 26, 2018 at 3:27 AM, Courage Angeh 
> wrote:
>
> > Hi Viswa,
> >
> > I agree with you about Demo Server being largely oriented towards a quick
> > use but it has a lot of useful data. I have gone through demo server too
> > and I see they introduce RSA keys through external properties so I was
> > thinking changing all the microservices will be a little more stressful,
> we
> > could pass external properties to it when running the different jar
> files.
> > True talk about Eureka, I am trying to work on that too.
> > But I was thinking we don't need that much scripts and we don't have to
> > change too much.
> > I wrote a proposal about this for a GSOC project,
> > https://docs.google.com/document/d/1zp6CeYP6ox51tGSu1fE9cBAWpaQnq
> > jeBBVIa-n0evso/edit?usp=sharing
> > , could you check it out? I will be delighted to get you point of view
> and
> > comments about this doc :)
> >
> > Thanks Courage
> >
> > On Sat, Mar 24, 2018 at 1:06 PM, Viswa Ramamoorthy <
> > viswaramamoor...@yahoo.com.invalid> wrote:
> >
> > >  Hello,
> > > I think services need more work to get to deployable state. Demo server
> > is
> > > largely oriented towards a quick use in laptops/desktops but using
> Junit
> > to
> > > bootsrap services may result in inconsistencies.
> > > I have been reviewing for sometime now. Based on my review, below are
> the
> > > changes needed to get to deployment in a VM
> > > 1. Currently services need RSA key to bootstrap. That is fine. But
> there
> > > is no self acquire mode to get them deployed to environments like demo
> > > envs.  a) Ideally a spring configured (say demo config) can be
> > > introduced to self acquire RSA keys to continue with service start.
> > > b) With this change, we could just start services using spring boot jar
> > > with a configuration property at the time of service start up  c) I
> > > have tried this change in my laptop for fineract-cn-provisioner. I can
> > > raise a PR. Needs to be propagated to other services
> > > 2. Eureka registration and renewal is bit flaky. Needs work on self
> > > registration front as well as health indicator front. Spring has
> tooling
> > on
> > > this front. We just need to add and configure.
> > > 3. Develop scripts to start services. Simple shell scripts good enough
> at
> > > this point.a) One use case is to build/deploy for use in VMb)
> > > Another use case is to facilitate selective service launch approach
> that
> > > was alluding to a while back. For example, if some one needs to work on
> > > 'accounting' services and depends on 'customer' services, they could
> > bring
> > > up 'customer' along with infrastructures using shell scripts (to be
> > > developed) and continue with development in accounting.
> > > 4. Deploy basic infrastructure needed for services - Eureka, ActiveMQ,
> > > Cassandra and MariaDB. These can be Dockers and I already sent PR on
> this
> > > front.
> > > Proposal is to create a new repo to have build/deployment scripts
> stored
> > > to get this used in VM and support laptop use cases to help with
> > > development.
> > > I can help/guide as needed.
> > >
> > > RegardsViswa Ramamoorthy
> > >On ‎Friday‎, ‎March‎ ‎23‎, ‎2018‎ ‎06‎:‎52‎:‎27‎ ‎AM‎ ‎EDT, Isaac
> > > Kamga  wrote:
> > >
> > >  Hi Ed,
> > >
> > > I 

Re: Reducing Barriers to Entry for New Contributors WAS [ Re: GSoC 2018: Fineract CN SMS & Email Notifications]

[Viswa Ramamoorthy]

 For the services currently available (as started by demo server), I estimate 4 
core/16 GB/100 GB would be minimum needed.

On ‎Wednesday‎, ‎March‎ ‎28‎, ‎2018‎ ‎03‎:‎05‎:‎12‎ ‎PM‎ ‎EDT, Ed Cable 
 wrote:  
 
 As we discussed earlier, the work to set up and configure the demo server
on the Apache infrastructure needs to be carried out by committers.

Fortunately, Nikhil, Rajan, and Isaac, all committers, have graciously
volunteered their time to assist. Can you all please provide your Apache
IDs on the issue at https://issues.apache.org/jira/browse/INFRA-16203 so
you can get the necessary access.

We will then discuss on this thread the needed steps to proceed forward.
However, before that, we need to answer some of the questions from Chris
about what base packages would need to be installed: https://goo.gl/iixSGX

Myrle, Viswa,

Can we please solidify on the base packages, minimum specs this VM needs
for deployment of the Fineract CN demo server?

Once we have established that, those individuals with the needed expertise
can assist the committers above who have volunteered to assist with this.

Ed

On Mon, Mar 26, 2018 at 3:27 AM, Courage Angeh 
wrote:

> Hi Viswa,
>
> I agree with you about Demo Server being largely oriented towards a quick
> use but it has a lot of useful data. I have gone through demo server too
> and I see they introduce RSA keys through external properties so I was
> thinking changing all the microservices will be a little more stressful, we
> could pass external properties to it when running the different jar files.
> True talk about Eureka, I am trying to work on that too.
> But I was thinking we don't need that much scripts and we don't have to
> change too much.
> I wrote a proposal about this for a GSOC project,
> https://docs.google.com/document/d/1zp6CeYP6ox51tGSu1fE9cBAWpaQnq
> jeBBVIa-n0evso/edit?usp=sharing
> , could you check it out? I will be delighted to get you point of view and
> comments about this doc :)
>
> Thanks Courage
>
> On Sat, Mar 24, 2018 at 1:06 PM, Viswa Ramamoorthy <
> viswaramamoor...@yahoo.com.invalid> wrote:
>
> >  Hello,
> > I think services need more work to get to deployable state. Demo server
> is
> > largely oriented towards a quick use in laptops/desktops but using Junit
> to
> > bootsrap services may result in inconsistencies.
> > I have been reviewing for sometime now. Based on my review, below are the
> > changes needed to get to deployment in a VM
> > 1. Currently services need RSA key to bootstrap. That is fine. But there
> > is no self acquire mode to get them deployed to environments like demo
> > envs.      a) Ideally a spring configured (say demo config) can be
> > introduced to self acquire RSA keys to continue with service start.
> > b) With this change, we could just start services using spring boot jar
> > with a configuration property at the time of service start up      c) I
> > have tried this change in my laptop for fineract-cn-provisioner. I can
> > raise a PR. Needs to be propagated to other services
> > 2. Eureka registration and renewal is bit flaky. Needs work on self
> > registration front as well as health indicator front. Spring has tooling
> on
> > this front. We just need to add and configure.
> > 3. Develop scripts to start services. Simple shell scripts good enough at
> > this point.    a) One use case is to build/deploy for use in VM    b)
> > Another use case is to facilitate selective service launch approach that
> > was alluding to a while back. For example, if some one needs to work on
> > 'accounting' services and depends on 'customer' services, they could
> bring
> > up 'customer' along with infrastructures using shell scripts (to be
> > developed) and continue with development in accounting.
> > 4. Deploy basic infrastructure needed for services - Eureka, ActiveMQ,
> > Cassandra and MariaDB. These can be Dockers and I already sent PR on this
> > front.
> > Proposal is to create a new repo to have build/deployment scripts stored
> > to get this used in VM and support laptop use cases to help with
> > development.
> > I can help/guide as needed.
> >
> > RegardsViswa Ramamoorthy
> >    On ‎Friday‎, ‎March‎ ‎23‎, ‎2018‎ ‎06‎:‎52‎:‎27‎ ‎AM‎ ‎EDT, Isaac
> > Kamga  wrote:
> >
> >  Hi Ed,
> >
> > I am willing to assist in configuring the VM requested for Apache
> Fineract
> > CN.
> >
> > I don't have all the required skills but with commitment and some
> > mentorship, this up and running within a few weeks.
> >
> > At Your Service,
> > Isaac Kamga.
> >
> >
> >
> >
> >
> > On Thu, Mar 22, 2018 at 10:17 PM, Ed Cable  wrote:
> >
> > > Committers,
> > >
> > > We need a committer who can assist in configuring the VM we've
> requested
> > > for a public demo server for Apache Fineract CN.  The massive hardware
> > > requirements to build locally have made this a huge barrier to
> > prospective
> > > GSOC applicants. We were trying to get this infrastructure set up but
> > don't
> > > have anybody with committer status 

Re: Reducing Barriers to Entry for New Contributors WAS [ Re: GSoC 2018: Fineract CN SMS & Email Notifications]

[Ed Cable]

As we discussed earlier, the work to set up and configure the demo server
on the Apache infrastructure needs to be carried out by committers.

Fortunately, Nikhil, Rajan, and Isaac, all committers, have graciously
volunteered their time to assist. Can you all please provide your Apache
IDs on the issue at https://issues.apache.org/jira/browse/INFRA-16203 so
you can get the necessary access.

We will then discuss on this thread the needed steps to proceed forward.
However, before that, we need to answer some of the questions from Chris
about what base packages would need to be installed: https://goo.gl/iixSGX

Myrle, Viswa,

Can we please solidify on the base packages, minimum specs this VM needs
for deployment of the Fineract CN demo server?

Once we have established that, those individuals with the needed expertise
can assist the committers above who have volunteered to assist with this.

Ed

On Mon, Mar 26, 2018 at 3:27 AM, Courage Angeh 
wrote:

> Hi Viswa,
>
> I agree with you about Demo Server being largely oriented towards a quick
> use but it has a lot of useful data. I have gone through demo server too
> and I see they introduce RSA keys through external properties so I was
> thinking changing all the microservices will be a little more stressful, we
> could pass external properties to it when running the different jar files.
> True talk about Eureka, I am trying to work on that too.
> But I was thinking we don't need that much scripts and we don't have to
> change too much.
> I wrote a proposal about this for a GSOC project,
> https://docs.google.com/document/d/1zp6CeYP6ox51tGSu1fE9cBAWpaQnq
> jeBBVIa-n0evso/edit?usp=sharing
> , could you check it out? I will be delighted to get you point of view and
> comments about this doc :)
>
> Thanks Courage
>
> On Sat, Mar 24, 2018 at 1:06 PM, Viswa Ramamoorthy <
> viswaramamoor...@yahoo.com.invalid> wrote:
>
> >  Hello,
> > I think services need more work to get to deployable state. Demo server
> is
> > largely oriented towards a quick use in laptops/desktops but using Junit
> to
> > bootsrap services may result in inconsistencies.
> > I have been reviewing for sometime now. Based on my review, below are the
> > changes needed to get to deployment in a VM
> > 1. Currently services need RSA key to bootstrap. That is fine. But there
> > is no self acquire mode to get them deployed to environments like demo
> > envs.   a) Ideally a spring configured (say demo config) can be
> > introduced to self acquire RSA keys to continue with service start.
> > b) With this change, we could just start services using spring boot jar
> > with a configuration property at the time of service start up   c) I
> > have tried this change in my laptop for fineract-cn-provisioner. I can
> > raise a PR. Needs to be propagated to other services
> > 2. Eureka registration and renewal is bit flaky. Needs work on self
> > registration front as well as health indicator front. Spring has tooling
> on
> > this front. We just need to add and configure.
> > 3. Develop scripts to start services. Simple shell scripts good enough at
> > this point. a) One use case is to build/deploy for use in VM b)
> > Another use case is to facilitate selective service launch approach that
> > was alluding to a while back. For example, if some one needs to work on
> > 'accounting' services and depends on 'customer' services, they could
> bring
> > up 'customer' along with infrastructures using shell scripts (to be
> > developed) and continue with development in accounting.
> > 4. Deploy basic infrastructure needed for services - Eureka, ActiveMQ,
> > Cassandra and MariaDB. These can be Dockers and I already sent PR on this
> > front.
> > Proposal is to create a new repo to have build/deployment scripts stored
> > to get this used in VM and support laptop use cases to help with
> > development.
> > I can help/guide as needed.
> >
> > RegardsViswa Ramamoorthy
> > On ‎Friday‎, ‎March‎ ‎23‎, ‎2018‎ ‎06‎:‎52‎:‎27‎ ‎AM‎ ‎EDT, Isaac
> > Kamga  wrote:
> >
> >  Hi Ed,
> >
> > I am willing to assist in configuring the VM requested for Apache
> Fineract
> > CN.
> >
> > I don't have all the required skills but with commitment and some
> > mentorship, this up and running within a few weeks.
> >
> > At Your Service,
> > Isaac Kamga.
> >
> >
> >
> >
> >
> > On Thu, Mar 22, 2018 at 10:17 PM, Ed Cable  wrote:
> >
> > > Committers,
> > >
> > > We need a committer who can assist in configuring the VM we've
> requested
> > > for a public demo server for Apache Fineract CN.  The massive hardware
> > > requirements to build locally have made this a huge barrier to
> > prospective
> > > GSOC applicants. We were trying to get this infrastructure set up but
> > don't
> > > have anybody with committer status who've raised their hands to
> configure
> > > the VM that Apache infrastructure is providing us.
> > >
> > > If you're able to, please respond to this thread and jump on to comment
> > > thread on the Apache I

Re: Reducing Barriers to Entry for New Contributors WAS [ Re: GSoC 2018: Fineract CN SMS & Email Notifications]

[Ed Cable]

Thanks Courage for sharing that proposal. We'll keep you posted as GSOC
proposals get evaluated.

Ed

On Mon, Mar 26, 2018 at 3:27 AM, Courage Angeh 
wrote:

> Hi Viswa,
>
> I agree with you about Demo Server being largely oriented towards a quick
> use but it has a lot of useful data. I have gone through demo server too
> and I see they introduce RSA keys through external properties so I was
> thinking changing all the microservices will be a little more stressful, we
> could pass external properties to it when running the different jar files.
> True talk about Eureka, I am trying to work on that too.
> But I was thinking we don't need that much scripts and we don't have to
> change too much.
> I wrote a proposal about this for a GSOC project,
> https://docs.google.com/document/d/1zp6CeYP6ox51tGSu1fE9cBAWpaQnq
> jeBBVIa-n0evso/edit?usp=sharing
> , could you check it out? I will be delighted to get you point of view and
> comments about this doc :)
>
> Thanks Courage
>
> On Sat, Mar 24, 2018 at 1:06 PM, Viswa Ramamoorthy <
> viswaramamoor...@yahoo.com.invalid> wrote:
>
> >  Hello,
> > I think services need more work to get to deployable state. Demo server
> is
> > largely oriented towards a quick use in laptops/desktops but using Junit
> to
> > bootsrap services may result in inconsistencies.
> > I have been reviewing for sometime now. Based on my review, below are the
> > changes needed to get to deployment in a VM
> > 1. Currently services need RSA key to bootstrap. That is fine. But there
> > is no self acquire mode to get them deployed to environments like demo
> > envs.   a) Ideally a spring configured (say demo config) can be
> > introduced to self acquire RSA keys to continue with service start.
> > b) With this change, we could just start services using spring boot jar
> > with a configuration property at the time of service start up   c) I
> > have tried this change in my laptop for fineract-cn-provisioner. I can
> > raise a PR. Needs to be propagated to other services
> > 2. Eureka registration and renewal is bit flaky. Needs work on self
> > registration front as well as health indicator front. Spring has tooling
> on
> > this front. We just need to add and configure.
> > 3. Develop scripts to start services. Simple shell scripts good enough at
> > this point. a) One use case is to build/deploy for use in VM b)
> > Another use case is to facilitate selective service launch approach that
> > was alluding to a while back. For example, if some one needs to work on
> > 'accounting' services and depends on 'customer' services, they could
> bring
> > up 'customer' along with infrastructures using shell scripts (to be
> > developed) and continue with development in accounting.
> > 4. Deploy basic infrastructure needed for services - Eureka, ActiveMQ,
> > Cassandra and MariaDB. These can be Dockers and I already sent PR on this
> > front.
> > Proposal is to create a new repo to have build/deployment scripts stored
> > to get this used in VM and support laptop use cases to help with
> > development.
> > I can help/guide as needed.
> >
> > RegardsViswa Ramamoorthy
> > On ‎Friday‎, ‎March‎ ‎23‎, ‎2018‎ ‎06‎:‎52‎:‎27‎ ‎AM‎ ‎EDT, Isaac
> > Kamga  wrote:
> >
> >  Hi Ed,
> >
> > I am willing to assist in configuring the VM requested for Apache
> Fineract
> > CN.
> >
> > I don't have all the required skills but with commitment and some
> > mentorship, this up and running within a few weeks.
> >
> > At Your Service,
> > Isaac Kamga.
> >
> >
> >
> >
> >
> > On Thu, Mar 22, 2018 at 10:17 PM, Ed Cable  wrote:
> >
> > > Committers,
> > >
> > > We need a committer who can assist in configuring the VM we've
> requested
> > > for a public demo server for Apache Fineract CN.  The massive hardware
> > > requirements to build locally have made this a huge barrier to
> > prospective
> > > GSOC applicants. We were trying to get this infrastructure set up but
> > don't
> > > have anybody with committer status who've raised their hands to
> configure
> > > the VM that Apache infrastructure is providing us.
> > >
> > > If you're able to, please respond to this thread and jump on to comment
> > > thread on the Apache Infrastructure ticket at
> > > https://issues.apache.org/jira/browse/INFRA-16203
> > >
> > > Thanks,
> > >
> > > Ed
> > >
> > > On Thu, Mar 22, 2018 at 1:54 PM, Ed Cable  wrote:
> > >
> > > > Aleks,
> > > >
> > > > Apache IDs are only available to committers. The guide to becoming a
> > > > committer is at https://cwiki.apache.org/
> confluence/display/FINERACT/
> > > Beco
> > > > ming+a+Committer
> > > >
> > > > I know that the major body of your work related to Fineract isn't yet
> > > > something the customer was willing to contribute back yet so you've
> > been
> > > > trying to build your public contributions in other ways. I was hoping
> > > that
> > > > this task could be a great way to do that but unfortunately you won't
> > be
> > > > able to do the actual configuration and setup on the

Re: Reducing Barriers to Entry for New Contributors WAS [ Re: GSoC 2018: Fineract CN SMS & Email Notifications]

[Viswa Ramamoorthy]

 Hi,
Spring boot applications should be starting by itself with configurations. 
Relying on another program to start is not good. 
My proposal to add RSA key creation from within services is pretty simple; we 
will reuse existing utility 'RsaKeyPairFactory' to create keys. It will not be 
intrusive and it can be done quickly. New changes that I propose can be made 
optional with a Spring configuration that can enable it. 
It helps with development in laptop/desktop as well. For example, with changes 
for RSA included in fineract-cn-provisioner, I could start infrastructures 
(ActiveMQ, Eureka, Cassandra and MariaDB) as Docker containers using my earlier 
PR and start fineract-cn-provisioner as a Spring boot app and work on it, debug 
it, start it using an IDE like Spring STS etc
RegardsViswa

On ‎Monday‎, ‎March‎ ‎26‎, ‎2018‎ ‎08‎:‎49‎:‎43‎ ‎AM‎ ‎EDT, Courage Angeh 
 wrote:  
 
 Hi Viswa,

I agree with you about Demo Server being largely oriented towards a quick
use but it has a lot of useful data. I have gone through demo server too
and I see they introduce RSA keys through external properties so I was
thinking changing all the microservices will be a little more stressful, we
could pass external properties to it when running the different jar files.
True talk about Eureka, I am trying to work on that too.
But I was thinking we don't need that much scripts and we don't have to
change too much.
I wrote a proposal about this for a GSOC project,
https://docs.google.com/document/d/1zp6CeYP6ox51tGSu1fE9cBAWpaQnqjeBBVIa-n0evso/edit?usp=sharing
, could you check it out? I will be delighted to get you point of view and
comments about this doc :)

Thanks Courage

On Sat, Mar 24, 2018 at 1:06 PM, Viswa Ramamoorthy <
viswaramamoor...@yahoo.com.invalid> wrote:

>  Hello,
> I think services need more work to get to deployable state. Demo server is
> largely oriented towards a quick use in laptops/desktops but using Junit to
> bootsrap services may result in inconsistencies.
> I have been reviewing for sometime now. Based on my review, below are the
> changes needed to get to deployment in a VM
> 1. Currently services need RSA key to bootstrap. That is fine. But there
> is no self acquire mode to get them deployed to environments like demo
> envs.      a) Ideally a spring configured (say demo config) can be
> introduced to self acquire RSA keys to continue with service start.
> b) With this change, we could just start services using spring boot jar
> with a configuration property at the time of service start up      c) I
> have tried this change in my laptop for fineract-cn-provisioner. I can
> raise a PR. Needs to be propagated to other services
> 2. Eureka registration and renewal is bit flaky. Needs work on self
> registration front as well as health indicator front. Spring has tooling on
> this front. We just need to add and configure.
> 3. Develop scripts to start services. Simple shell scripts good enough at
> this point.    a) One use case is to build/deploy for use in VM    b)
> Another use case is to facilitate selective service launch approach that
> was alluding to a while back. For example, if some one needs to work on
> 'accounting' services and depends on 'customer' services, they could bring
> up 'customer' along with infrastructures using shell scripts (to be
> developed) and continue with development in accounting.
> 4. Deploy basic infrastructure needed for services - Eureka, ActiveMQ,
> Cassandra and MariaDB. These can be Dockers and I already sent PR on this
> front.
> Proposal is to create a new repo to have build/deployment scripts stored
> to get this used in VM and support laptop use cases to help with
> development.
> I can help/guide as needed.
>
> RegardsViswa Ramamoorthy
>    On ‎Friday‎, ‎March‎ ‎23‎, ‎2018‎ ‎06‎:‎52‎:‎27‎ ‎AM‎ ‎EDT, Isaac
> Kamga  wrote:
>
>  Hi Ed,
>
> I am willing to assist in configuring the VM requested for Apache Fineract
> CN.
>
> I don't have all the required skills but with commitment and some
> mentorship, this up and running within a few weeks.
>
> At Your Service,
> Isaac Kamga.
>
>
>
>
>
> On Thu, Mar 22, 2018 at 10:17 PM, Ed Cable  wrote:
>
> > Committers,
> >
> > We need a committer who can assist in configuring the VM we've requested
> > for a public demo server for Apache Fineract CN.  The massive hardware
> > requirements to build locally have made this a huge barrier to
> prospective
> > GSOC applicants. We were trying to get this infrastructure set up but
> don't
> > have anybody with committer status who've raised their hands to configure
> > the VM that Apache infrastructure is providing us.
> >
> > If you're able to, please respond to this thread and jump on to comment
> > thread on the Apache Infrastructure ticket at
> > https://issues.apache.org/jira/browse/INFRA-16203
> >
> > Thanks,
> >
> > Ed
> >
> > On Thu, Mar 22, 2018 at 1:54 PM, Ed Cable  wrote:
> >
> > > Aleks,
> > >
> > > Apache IDs are only available to committers. The guide to becomin

Re: Reducing Barriers to Entry for New Contributors WAS [ Re: GSoC 2018: Fineract CN SMS & Email Notifications]

[Courage Angeh]

Hi Viswa,

I agree with you about Demo Server being largely oriented towards a quick
use but it has a lot of useful data. I have gone through demo server too
and I see they introduce RSA keys through external properties so I was
thinking changing all the microservices will be a little more stressful, we
could pass external properties to it when running the different jar files.
True talk about Eureka, I am trying to work on that too.
But I was thinking we don't need that much scripts and we don't have to
change too much.
I wrote a proposal about this for a GSOC project,
https://docs.google.com/document/d/1zp6CeYP6ox51tGSu1fE9cBAWpaQnqjeBBVIa-n0evso/edit?usp=sharing
, could you check it out? I will be delighted to get you point of view and
comments about this doc :)

Thanks Courage

On Sat, Mar 24, 2018 at 1:06 PM, Viswa Ramamoorthy <
viswaramamoor...@yahoo.com.invalid> wrote:

>  Hello,
> I think services need more work to get to deployable state. Demo server is
> largely oriented towards a quick use in laptops/desktops but using Junit to
> bootsrap services may result in inconsistencies.
> I have been reviewing for sometime now. Based on my review, below are the
> changes needed to get to deployment in a VM
> 1. Currently services need RSA key to bootstrap. That is fine. But there
> is no self acquire mode to get them deployed to environments like demo
> envs.   a) Ideally a spring configured (say demo config) can be
> introduced to self acquire RSA keys to continue with service start.
> b) With this change, we could just start services using spring boot jar
> with a configuration property at the time of service start up   c) I
> have tried this change in my laptop for fineract-cn-provisioner. I can
> raise a PR. Needs to be propagated to other services
> 2. Eureka registration and renewal is bit flaky. Needs work on self
> registration front as well as health indicator front. Spring has tooling on
> this front. We just need to add and configure.
> 3. Develop scripts to start services. Simple shell scripts good enough at
> this point. a) One use case is to build/deploy for use in VM b)
> Another use case is to facilitate selective service launch approach that
> was alluding to a while back. For example, if some one needs to work on
> 'accounting' services and depends on 'customer' services, they could bring
> up 'customer' along with infrastructures using shell scripts (to be
> developed) and continue with development in accounting.
> 4. Deploy basic infrastructure needed for services - Eureka, ActiveMQ,
> Cassandra and MariaDB. These can be Dockers and I already sent PR on this
> front.
> Proposal is to create a new repo to have build/deployment scripts stored
> to get this used in VM and support laptop use cases to help with
> development.
> I can help/guide as needed.
>
> RegardsViswa Ramamoorthy
> On ‎Friday‎, ‎March‎ ‎23‎, ‎2018‎ ‎06‎:‎52‎:‎27‎ ‎AM‎ ‎EDT, Isaac
> Kamga  wrote:
>
>  Hi Ed,
>
> I am willing to assist in configuring the VM requested for Apache Fineract
> CN.
>
> I don't have all the required skills but with commitment and some
> mentorship, this up and running within a few weeks.
>
> At Your Service,
> Isaac Kamga.
>
>
>
>
>
> On Thu, Mar 22, 2018 at 10:17 PM, Ed Cable  wrote:
>
> > Committers,
> >
> > We need a committer who can assist in configuring the VM we've requested
> > for a public demo server for Apache Fineract CN.  The massive hardware
> > requirements to build locally have made this a huge barrier to
> prospective
> > GSOC applicants. We were trying to get this infrastructure set up but
> don't
> > have anybody with committer status who've raised their hands to configure
> > the VM that Apache infrastructure is providing us.
> >
> > If you're able to, please respond to this thread and jump on to comment
> > thread on the Apache Infrastructure ticket at
> > https://issues.apache.org/jira/browse/INFRA-16203
> >
> > Thanks,
> >
> > Ed
> >
> > On Thu, Mar 22, 2018 at 1:54 PM, Ed Cable  wrote:
> >
> > > Aleks,
> > >
> > > Apache IDs are only available to committers. The guide to becoming a
> > > committer is at https://cwiki.apache.org/confluence/display/FINERACT/
> > Beco
> > > ming+a+Committer
> > >
> > > I know that the major body of your work related to Fineract isn't yet
> > > something the customer was willing to contribute back yet so you've
> been
> > > trying to build your public contributions in other ways. I was hoping
> > that
> > > this task could be a great way to do that but unfortunately you won't
> be
> > > able to do the actual configuration and setup on the VMs until you have
> > > achieved committer status.
> > >
> > > Nonetheless though a great contribution you could make right now is
> > giving
> > > your input on how the VM could be be configured and responded to some
> of
> > > the feedback from Viswa. Your inputs here would be exceptionally
> valuable
> > > to whoever from our group of committers steps up with enough free time
> to
> >

Re: Reducing Barriers to Entry for New Contributors WAS [ Re: GSoC 2018: Fineract CN SMS & Email Notifications]

[Viswa Ramamoorthy]

 Hello,
I think services need more work to get to deployable state. Demo server is 
largely oriented towards a quick use in laptops/desktops but using Junit to 
bootsrap services may result in inconsistencies.
I have been reviewing for sometime now. Based on my review, below are the 
changes needed to get to deployment in a VM
1. Currently services need RSA key to bootstrap. That is fine. But there is no 
self acquire mode to get them deployed to environments like demo envs.       a) 
Ideally a spring configured (say demo config) can be introduced to self acquire 
RSA keys to continue with service start.       b) With this change, we could 
just start services using spring boot jar with a configuration property at the 
time of service start up       c) I have tried this change in my laptop for 
fineract-cn-provisioner. I can raise a PR. Needs to be propagated to other 
services
2. Eureka registration and renewal is bit flaky. Needs work on self 
registration front as well as health indicator front. Spring has tooling on 
this front. We just need to add and configure.
3. Develop scripts to start services. Simple shell scripts good enough at this 
point.     a) One use case is to build/deploy for use in VM     b) Another use 
case is to facilitate selective service launch approach that was alluding to a 
while back. For example, if some one needs to work on 'accounting' services and 
depends on 'customer' services, they could bring up 'customer' along with 
infrastructures using shell scripts (to be developed) and continue with 
development in accounting. 
4. Deploy basic infrastructure needed for services - Eureka, ActiveMQ, 
Cassandra and MariaDB. These can be Dockers and I already sent PR on this 
front. 
Proposal is to create a new repo to have build/deployment scripts stored to get 
this used in VM and support laptop use cases to help with development. 
I can help/guide as needed.

RegardsViswa Ramamoorthy
On ‎Friday‎, ‎March‎ ‎23‎, ‎2018‎ ‎06‎:‎52‎:‎27‎ ‎AM‎ ‎EDT, Isaac Kamga 
 wrote:  
 
 Hi Ed,

I am willing to assist in configuring the VM requested for Apache Fineract
CN.

I don't have all the required skills but with commitment and some
mentorship, this up and running within a few weeks.

At Your Service,
Isaac Kamga.





On Thu, Mar 22, 2018 at 10:17 PM, Ed Cable  wrote:

> Committers,
>
> We need a committer who can assist in configuring the VM we've requested
> for a public demo server for Apache Fineract CN.  The massive hardware
> requirements to build locally have made this a huge barrier to prospective
> GSOC applicants. We were trying to get this infrastructure set up but don't
> have anybody with committer status who've raised their hands to configure
> the VM that Apache infrastructure is providing us.
>
> If you're able to, please respond to this thread and jump on to comment
> thread on the Apache Infrastructure ticket at
> https://issues.apache.org/jira/browse/INFRA-16203
>
> Thanks,
>
> Ed
>
> On Thu, Mar 22, 2018 at 1:54 PM, Ed Cable  wrote:
>
> > Aleks,
> >
> > Apache IDs are only available to committers. The guide to becoming a
> > committer is at https://cwiki.apache.org/confluence/display/FINERACT/
> Beco
> > ming+a+Committer
> >
> > I know that the major body of your work related to Fineract isn't yet
> > something the customer was willing to contribute back yet so you've been
> > trying to build your public contributions in other ways. I was hoping
> that
> > this task could be a great way to do that but unfortunately you won't be
> > able to do the actual configuration and setup on the VMs until you have
> > achieved committer status.
> >
> > Nonetheless though a great contribution you could make right now is
> giving
> > your input on how the VM could be be configured and responded to some of
> > the feedback from Viswa. Your inputs here would be exceptionally valuable
> > to whoever from our group of committers steps up with enough free time to
> > be able to configure the VM.
> >
> > Robert/Aleks - could you please share any questions/feedback you have on
> > the VM setup on this thread?
> >
> > Thanks,
> >
> > Ed
> >
> > On Mon, Mar 19, 2018 at 8:51 AM, Aleksandar Vidakovic <
> > chee...@monkeysintown.com> wrote:
> >
> >> Hi Ed,
> >>
> >> ... how do I get one of those Apache IDs? Anything you need from me?
> >>
> >> Cheers,
> >>
> >> Aleks
> >>
> >> On Mon, Mar 19, 2018 at 3:50 PM Ed Cable  wrote:
> >>
> >>> Thanks Viswa. I will let Myrle and others reply to your input. Through
> >>> Apache for this demo infrastructure I think we only have access to one
> VM.
> >>>
> >>> Myrle, Robert, Aleks,
> >>>
> >>> Did you see Chris' comments on the Infra ticket? https://issues.apache
> .
> >>> org/jira/browse/INFRA-16203
> >>>
> >>> Permalink
> >>>  focusedCommentId=16403788&page=com.atlassian.jira.
> plugin.system.issuetabpanels:comment-tabpanel#comment-16403788>
> >>> [image: cml]Chris Lambertus
> >>> 

Re: Reducing Barriers to Entry for New Contributors WAS [ Re: GSoC 2018: Fineract CN SMS & Email Notifications]

[Isaac Kamga]

Hi Ed,

I am willing to assist in configuring the VM requested for Apache Fineract
CN.

I don't have all the required skills but with commitment and some
mentorship, this up and running within a few weeks.

At Your Service,
Isaac Kamga.





On Thu, Mar 22, 2018 at 10:17 PM, Ed Cable  wrote:

> Committers,
>
> We need a committer who can assist in configuring the VM we've requested
> for a public demo server for Apache Fineract CN.  The massive hardware
> requirements to build locally have made this a huge barrier to prospective
> GSOC applicants. We were trying to get this infrastructure set up but don't
> have anybody with committer status who've raised their hands to configure
> the VM that Apache infrastructure is providing us.
>
> If you're able to, please respond to this thread and jump on to comment
> thread on the Apache Infrastructure ticket at
> https://issues.apache.org/jira/browse/INFRA-16203
>
> Thanks,
>
> Ed
>
> On Thu, Mar 22, 2018 at 1:54 PM, Ed Cable  wrote:
>
> > Aleks,
> >
> > Apache IDs are only available to committers. The guide to becoming a
> > committer is at https://cwiki.apache.org/confluence/display/FINERACT/
> Beco
> > ming+a+Committer
> >
> > I know that the major body of your work related to Fineract isn't yet
> > something the customer was willing to contribute back yet so you've been
> > trying to build your public contributions in other ways. I was hoping
> that
> > this task could be a great way to do that but unfortunately you won't be
> > able to do the actual configuration and setup on the VMs until you have
> > achieved committer status.
> >
> > Nonetheless though a great contribution you could make right now is
> giving
> > your input on how the VM could be be configured and responded to some of
> > the feedback from Viswa. Your inputs here would be exceptionally valuable
> > to whoever from our group of committers steps up with enough free time to
> > be able to configure the VM.
> >
> > Robert/Aleks - could you please share any questions/feedback you have on
> > the VM setup on this thread?
> >
> > Thanks,
> >
> > Ed
> >
> > On Mon, Mar 19, 2018 at 8:51 AM, Aleksandar Vidakovic <
> > chee...@monkeysintown.com> wrote:
> >
> >> Hi Ed,
> >>
> >> ... how do I get one of those Apache IDs? Anything you need from me?
> >>
> >> Cheers,
> >>
> >> Aleks
> >>
> >> On Mon, Mar 19, 2018 at 3:50 PM Ed Cable  wrote:
> >>
> >>> Thanks Viswa. I will let Myrle and others reply to your input. Through
> >>> Apache for this demo infrastructure I think we only have access to one
> VM.
> >>>
> >>> Myrle, Robert, Aleks,
> >>>
> >>> Did you see Chris' comments on the Infra ticket? https://issues.apache
> .
> >>> org/jira/browse/INFRA-16203
> >>>
> >>> Permalink
> >>>  focusedCommentId=16403788&page=com.atlassian.jira.
> plugin.system.issuetabpanels:comment-tabpanel#comment-16403788>
> >>> [image: cml]Chris Lambertus
> >>> 
> added
> >>> a comment - 2 days ago
> >>> We'll need a list of apache IDs who will need access to the VM. We use
> >>> puppet to maintain configs, so we can set up some boilerplate config
> for
> >>> httpd with proxy entries and letsencrypt SSL certs if you wish (or you
> can
> >>> manage that entirely yourself.) We can also install a base set of
> packages
> >>> if you let us know what you need.
> >>>
> >>>
> >>> On Sun, Mar 18, 2018 at 3:51 AM, Viswa Ramamoorthy <
> >>> viswaramamoor...@yahoo.com> wrote:
> >>>
>  Hello,
> 
>  My 2 cents...
> 
>  Assuming
>  a) all of 30+ services (gtihub.com/apache/fineract-cn-*) to be
>  deployed as individual micro services
>  b) in a single VM (this is the quickest as more maturity needed for
>  multi VM deployments)
>  c) usage purpose is for integration environment for functional test &
>  demo
> 
>  I would say 8 core/24 GB/250 GB would be minimum spec.
> 
>  For future service additions, a second VM  can be added to make it a
>  cluster. To prepare towards support for deployments in multiple VMs,
>  deployment strategy like Docker needs to be matured. There are other
> ways
>  to deploy services across multiple VMs. In my opinion, Docker with
> swarm or
>  Kubernetes would be a very good candidate
> 
>  Regards
>  Viswa Ramamoorthy
> 
>  On ‎Saturday‎, ‎March‎ ‎17‎, ‎2018‎ ‎06‎:‎45‎:‎48‎ ‎PM‎ ‎EDT, Ed
> Cable <
>  edca...@mifos.org> wrote:
> 
>  I'm not sure the process as it's not well documented nor do I know the
>  virtual machine requirements for Fineract CN but I created the ticket
>  and
>  would appreciate others from PMC to put in comments the specifics
>  required
>  for the instance: https://issues.apache.org/jira/browse/INFRA-16203
> 
>  Thanks,
> 
>  Ed
> 
>  On Sat, Mar 17, 2018 at 9:01 AM, Myrle Krantz 
> wrote:
> 
>  > Hey Ed,
>  >
> >>

Re: Reducing Barriers to Entry for New Contributors WAS [ Re: GSoC 2018: Fineract CN SMS & Email Notifications]

[Ed Cable]

Committers,

We need a committer who can assist in configuring the VM we've requested
for a public demo server for Apache Fineract CN.  The massive hardware
requirements to build locally have made this a huge barrier to prospective
GSOC applicants. We were trying to get this infrastructure set up but don't
have anybody with committer status who've raised their hands to configure
the VM that Apache infrastructure is providing us.

If you're able to, please respond to this thread and jump on to comment
thread on the Apache Infrastructure ticket at
https://issues.apache.org/jira/browse/INFRA-16203

Thanks,

Ed

On Thu, Mar 22, 2018 at 1:54 PM, Ed Cable  wrote:

> Aleks,
>
> Apache IDs are only available to committers. The guide to becoming a
> committer is at https://cwiki.apache.org/confluence/display/FINERACT/Beco
> ming+a+Committer
>
> I know that the major body of your work related to Fineract isn't yet
> something the customer was willing to contribute back yet so you've been
> trying to build your public contributions in other ways. I was hoping that
> this task could be a great way to do that but unfortunately you won't be
> able to do the actual configuration and setup on the VMs until you have
> achieved committer status.
>
> Nonetheless though a great contribution you could make right now is giving
> your input on how the VM could be be configured and responded to some of
> the feedback from Viswa. Your inputs here would be exceptionally valuable
> to whoever from our group of committers steps up with enough free time to
> be able to configure the VM.
>
> Robert/Aleks - could you please share any questions/feedback you have on
> the VM setup on this thread?
>
> Thanks,
>
> Ed
>
> On Mon, Mar 19, 2018 at 8:51 AM, Aleksandar Vidakovic <
> chee...@monkeysintown.com> wrote:
>
>> Hi Ed,
>>
>> ... how do I get one of those Apache IDs? Anything you need from me?
>>
>> Cheers,
>>
>> Aleks
>>
>> On Mon, Mar 19, 2018 at 3:50 PM Ed Cable  wrote:
>>
>>> Thanks Viswa. I will let Myrle and others reply to your input. Through
>>> Apache for this demo infrastructure I think we only have access to one VM.
>>>
>>> Myrle, Robert, Aleks,
>>>
>>> Did you see Chris' comments on the Infra ticket? https://issues.apache.
>>> org/jira/browse/INFRA-16203
>>>
>>> Permalink
>>> 
>>> [image: cml]Chris Lambertus
>>>  added
>>> a comment - 2 days ago
>>> We'll need a list of apache IDs who will need access to the VM. We use
>>> puppet to maintain configs, so we can set up some boilerplate config for
>>> httpd with proxy entries and letsencrypt SSL certs if you wish (or you can
>>> manage that entirely yourself.) We can also install a base set of packages
>>> if you let us know what you need.
>>>
>>>
>>> On Sun, Mar 18, 2018 at 3:51 AM, Viswa Ramamoorthy <
>>> viswaramamoor...@yahoo.com> wrote:
>>>
 Hello,

 My 2 cents...

 Assuming
 a) all of 30+ services (gtihub.com/apache/fineract-cn-*) to be
 deployed as individual micro services
 b) in a single VM (this is the quickest as more maturity needed for
 multi VM deployments)
 c) usage purpose is for integration environment for functional test &
 demo

 I would say 8 core/24 GB/250 GB would be minimum spec.

 For future service additions, a second VM  can be added to make it a
 cluster. To prepare towards support for deployments in multiple VMs,
 deployment strategy like Docker needs to be matured. There are other ways
 to deploy services across multiple VMs. In my opinion, Docker with swarm or
 Kubernetes would be a very good candidate

 Regards
 Viswa Ramamoorthy

 On ‎Saturday‎, ‎March‎ ‎17‎, ‎2018‎ ‎06‎:‎45‎:‎48‎ ‎PM‎ ‎EDT, Ed Cable <
 edca...@mifos.org> wrote:

 I'm not sure the process as it's not well documented nor do I know the
 virtual machine requirements for Fineract CN but I created the ticket
 and
 would appreciate others from PMC to put in comments the specifics
 required
 for the instance: https://issues.apache.org/jira/browse/INFRA-16203

 Thanks,

 Ed

 On Sat, Mar 17, 2018 at 9:01 AM, Myrle Krantz  wrote:

 > Hey Ed,
 >
 > It’s just a matter of putting in an Infra ticket. Anyone on the PMC
 can do
 > it.
 >
 > Regards,
 > Myrle

>>>
 >
 > On Sat 17. Mar 2018 at 08:50 Ed Cable  wrote:
 >
 > > Myrle,
 > >
 > > I know you are still slammed but wanted to see if you had the
 chance to
 > > place this request or if it was something I could do as I wanted to
 get
 > > Aleks up and going as it's proving problematic for a number of our
 GSOC
 > > aspirants to not be able to fully grok the functionality of
 Fin

Re: Reducing Barriers to Entry for New Contributors WAS [ Re: GSoC 2018: Fineract CN SMS & Email Notifications]

[Ed Cable]

Aleks,

Apache IDs are only available to committers. The guide to becoming a
committer is at
https://cwiki.apache.org/confluence/display/FINERACT/Becoming+a+Committer

I know that the major body of your work related to Fineract isn't yet
something the customer was willing to contribute back yet so you've been
trying to build your public contributions in other ways. I was hoping that
this task could be a great way to do that but unfortunately you won't be
able to do the actual configuration and setup on the VMs until you have
achieved committer status.

Nonetheless though a great contribution you could make right now is giving
your input on how the VM could be be configured and responded to some of
the feedback from Viswa. Your inputs here would be exceptionally valuable
to whoever from our group of committers steps up with enough free time to
be able to configure the VM.

Robert/Aleks - could you please share any questions/feedback you have on
the VM setup on this thread?

Thanks,

Ed

On Mon, Mar 19, 2018 at 8:51 AM, Aleksandar Vidakovic <
chee...@monkeysintown.com> wrote:

> Hi Ed,
>
> ... how do I get one of those Apache IDs? Anything you need from me?
>
> Cheers,
>
> Aleks
>
> On Mon, Mar 19, 2018 at 3:50 PM Ed Cable  wrote:
>
>> Thanks Viswa. I will let Myrle and others reply to your input. Through
>> Apache for this demo infrastructure I think we only have access to one VM.
>>
>> Myrle, Robert, Aleks,
>>
>> Did you see Chris' comments on the Infra ticket? https://issues.apache.
>> org/jira/browse/INFRA-16203
>>
>> Permalink
>> 
>> [image: cml]Chris Lambertus
>>  added
>> a comment - 2 days ago
>> We'll need a list of apache IDs who will need access to the VM. We use
>> puppet to maintain configs, so we can set up some boilerplate config for
>> httpd with proxy entries and letsencrypt SSL certs if you wish (or you can
>> manage that entirely yourself.) We can also install a base set of packages
>> if you let us know what you need.
>>
>>
>> On Sun, Mar 18, 2018 at 3:51 AM, Viswa Ramamoorthy <
>> viswaramamoor...@yahoo.com> wrote:
>>
>>> Hello,
>>>
>>> My 2 cents...
>>>
>>> Assuming
>>> a) all of 30+ services (gtihub.com/apache/fineract-cn-*) to be deployed
>>> as individual micro services
>>> b) in a single VM (this is the quickest as more maturity needed for
>>> multi VM deployments)
>>> c) usage purpose is for integration environment for functional test &
>>> demo
>>>
>>> I would say 8 core/24 GB/250 GB would be minimum spec.
>>>
>>> For future service additions, a second VM  can be added to make it a
>>> cluster. To prepare towards support for deployments in multiple VMs,
>>> deployment strategy like Docker needs to be matured. There are other ways
>>> to deploy services across multiple VMs. In my opinion, Docker with swarm or
>>> Kubernetes would be a very good candidate
>>>
>>> Regards
>>> Viswa Ramamoorthy
>>>
>>> On ‎Saturday‎, ‎March‎ ‎17‎, ‎2018‎ ‎06‎:‎45‎:‎48‎ ‎PM‎ ‎EDT, Ed Cable <
>>> edca...@mifos.org> wrote:
>>>
>>> I'm not sure the process as it's not well documented nor do I know the
>>> virtual machine requirements for Fineract CN but I created the ticket and
>>> would appreciate others from PMC to put in comments the specifics
>>> required
>>> for the instance: https://issues.apache.org/jira/browse/INFRA-16203
>>>
>>> Thanks,
>>>
>>> Ed
>>>
>>> On Sat, Mar 17, 2018 at 9:01 AM, Myrle Krantz  wrote:
>>>
>>> > Hey Ed,
>>> >
>>> > It’s just a matter of putting in an Infra ticket. Anyone on the PMC
>>> can do
>>> > it.
>>> >
>>> > Regards,
>>> > Myrle
>>>
>>
>>> >
>>> > On Sat 17. Mar 2018 at 08:50 Ed Cable  wrote:
>>> >
>>> > > Myrle,
>>> > >
>>> > > I know you are still slammed but wanted to see if you had the chance
>>> to
>>> > > place this request or if it was something I could do as I wanted to
>>> get
>>> > > Aleks up and going as it's proving problematic for a number of our
>>> GSOC
>>> > > aspirants to not be able to fully grok the functionality of Fineract
>>> CN
>>> > > without having access to a web app. For many the high hardware
>>> > requirements
>>> > > is proving to be an insurmountable barrier. Applications are due by
>>> the
>>> > > 27th so I was hoping by early next week we might be able to get this
>>> > setup.
>>> > >
>>> > > Cheers,
>>> > >
>>> > > Ed
>>> > >
>>> > > On Mon, Mar 12, 2018 at 7:20 AM, Ed Cable  wrote:
>>> > >
>>> > > > Myrle,
>>> > > >
>>> > > > Robert Jakech and Aleksander Vidakovic have volunteered to assist.
>>> I'll
>>> > > > let you move forward with the process and let you provide them the
>>> > > > necessary information to allow them to get access to infrstructure
>>> and
>>> > > get
>>> > > > continuous build process going for the community to have access to
>>> a
>>> > > > publicly available instance of the demo server.

Re: Reducing Barriers to Entry for New Contributors WAS [ Re: GSoC 2018: Fineract CN SMS & Email Notifications]

[Aleksandar Vidakovic]

Hi Ed,

... how do I get one of those Apache IDs? Anything you need from me?

Cheers,

Aleks

On Mon, Mar 19, 2018 at 3:50 PM Ed Cable  wrote:

> Thanks Viswa. I will let Myrle and others reply to your input. Through
> Apache for this demo infrastructure I think we only have access to one VM.
>
> Myrle, Robert, Aleks,
>
> Did you see Chris' comments on the Infra ticket?
> https://issues.apache.org/jira/browse/INFRA-16203
>
> Permalink
> 
> [image: cml]Chris Lambertus
>  added a
> comment - 2 days ago
> We'll need a list of apache IDs who will need access to the VM. We use
> puppet to maintain configs, so we can set up some boilerplate config for
> httpd with proxy entries and letsencrypt SSL certs if you wish (or you can
> manage that entirely yourself.) We can also install a base set of packages
> if you let us know what you need.
>
>
> On Sun, Mar 18, 2018 at 3:51 AM, Viswa Ramamoorthy <
> viswaramamoor...@yahoo.com> wrote:
>
>> Hello,
>>
>> My 2 cents...
>>
>> Assuming
>> a) all of 30+ services (gtihub.com/apache/fineract-cn-*) to be deployed
>> as individual micro services
>> b) in a single VM (this is the quickest as more maturity needed for multi
>> VM deployments)
>> c) usage purpose is for integration environment for functional test & demo
>>
>> I would say 8 core/24 GB/250 GB would be minimum spec.
>>
>> For future service additions, a second VM  can be added to make it a
>> cluster. To prepare towards support for deployments in multiple VMs,
>> deployment strategy like Docker needs to be matured. There are other ways
>> to deploy services across multiple VMs. In my opinion, Docker with swarm or
>> Kubernetes would be a very good candidate
>>
>> Regards
>> Viswa Ramamoorthy
>>
>> On ‎Saturday‎, ‎March‎ ‎17‎, ‎2018‎ ‎06‎:‎45‎:‎48‎ ‎PM‎ ‎EDT, Ed Cable <
>> edca...@mifos.org> wrote:
>>
>> I'm not sure the process as it's not well documented nor do I know the
>> virtual machine requirements for Fineract CN but I created the ticket and
>> would appreciate others from PMC to put in comments the specifics required
>> for the instance: https://issues.apache.org/jira/browse/INFRA-16203
>>
>> Thanks,
>>
>> Ed
>>
>> On Sat, Mar 17, 2018 at 9:01 AM, Myrle Krantz  wrote:
>>
>> > Hey Ed,
>> >
>> > It’s just a matter of putting in an Infra ticket. Anyone on the PMC can
>> do
>> > it.
>> >
>> > Regards,
>> > Myrle
>>
>
>> >
>> > On Sat 17. Mar 2018 at 08:50 Ed Cable  wrote:
>> >
>> > > Myrle,
>> > >
>> > > I know you are still slammed but wanted to see if you had the chance
>> to
>> > > place this request or if it was something I could do as I wanted to
>> get
>> > > Aleks up and going as it's proving problematic for a number of our
>> GSOC
>> > > aspirants to not be able to fully grok the functionality of Fineract
>> CN
>> > > without having access to a web app. For many the high hardware
>> > requirements
>> > > is proving to be an insurmountable barrier. Applications are due by
>> the
>> > > 27th so I was hoping by early next week we might be able to get this
>> > setup.
>> > >
>> > > Cheers,
>> > >
>> > > Ed
>> > >
>> > > On Mon, Mar 12, 2018 at 7:20 AM, Ed Cable  wrote:
>> > >
>> > > > Myrle,
>> > > >
>> > > > Robert Jakech and Aleksander Vidakovic have volunteered to assist.
>> I'll
>> > > > let you move forward with the process and let you provide them the
>> > > > necessary information to allow them to get access to infrstructure
>> and
>> > > get
>> > > > continuous build process going for the community to have access to a
>> > > > publicly available instance of the demo server.
>> > > >
>> > > > Ed
>> > > >
>> > > > On Thu, Mar 8, 2018 at 6:26 AM, Myrle Krantz 
>> wrote:
>> > > >
>> > > >> On Wed, Mar 7, 2018 at 9:25 PM, Ed Cable 
>> wrote:
>> > > >> > Hi all, I wanted to give this thread a new subject line as it's a
>> > > >> valuable
>> > > >> > discussion that had gone beyond the original topic. I'm
>> especially
>> > > >> thinking
>> > > >> > about this in the context of new potential contributors that are
>> > > coming
>> > > >> > along for GSOC that won't have the proper hardware to build and
>> > > deploy.
>> > > >> >
>> > > >> > While you all are continuing the discussion around dockerization
>> of
>> > > >> > services, running from a single process, and running
>> microservices
>> > > >> > selectively, I wanted to raise the request that Myrle and I had
>> > > >> discussed
>> > > >> > around requesting a VM from the Apache infrastructure to use to
>> > > deploy a
>> > > >> > public demo server for the community. This would provide a tool
>> for
>> > > >> users
>> > > >> > and partners to quickly evaluate and keep progress of
>> functionality
>> > > but
>> > > >> > more importantly allow web and mobile devs to test their changes
>> > > without
>> > > >> > having to build 

Re: Reducing Barriers to Entry for New Contributors WAS [ Re: GSoC 2018: Fineract CN SMS & Email Notifications]

[Ed Cable]

Thanks Viswa. I will let Myrle and others reply to your input. Through
Apache for this demo infrastructure I think we only have access to one VM.

Myrle, Robert, Aleks,

Did you see Chris' comments on the Infra ticket?
https://issues.apache.org/jira/browse/INFRA-16203

Permalink

[image: cml]Chris Lambertus
 added a
comment - 2 days ago
We'll need a list of apache IDs who will need access to the VM. We use
puppet to maintain configs, so we can set up some boilerplate config for
httpd with proxy entries and letsencrypt SSL certs if you wish (or you can
manage that entirely yourself.) We can also install a base set of packages
if you let us know what you need.


On Sun, Mar 18, 2018 at 3:51 AM, Viswa Ramamoorthy <
viswaramamoor...@yahoo.com> wrote:

> Hello,
>
> My 2 cents...
>
> Assuming
> a) all of 30+ services (gtihub.com/apache/fineract-cn-*) to be deployed
> as individual micro services
> b) in a single VM (this is the quickest as more maturity needed for multi
> VM deployments)
> c) usage purpose is for integration environment for functional test & demo
>
> I would say 8 core/24 GB/250 GB would be minimum spec.
>
> For future service additions, a second VM  can be added to make it a
> cluster. To prepare towards support for deployments in multiple VMs,
> deployment strategy like Docker needs to be matured. There are other ways
> to deploy services across multiple VMs. In my opinion, Docker with swarm or
> Kubernetes would be a very good candidate
>
> Regards
> Viswa Ramamoorthy
>
> On ‎Saturday‎, ‎March‎ ‎17‎, ‎2018‎ ‎06‎:‎45‎:‎48‎ ‎PM‎ ‎EDT, Ed Cable <
> edca...@mifos.org> wrote:
>
> I'm not sure the process as it's not well documented nor do I know the
> virtual machine requirements for Fineract CN but I created the ticket and
> would appreciate others from PMC to put in comments the specifics required
> for the instance: https://issues.apache.org/jira/browse/INFRA-16203
>
> Thanks,
>
> Ed
>
> On Sat, Mar 17, 2018 at 9:01 AM, Myrle Krantz  wrote:
>
> > Hey Ed,
> >
> > It’s just a matter of putting in an Infra ticket. Anyone on the PMC can
> do
> > it.
> >
> > Regards,
> > Myrle
> >
> > On Sat 17. Mar 2018 at 08:50 Ed Cable  wrote:
> >
> > > Myrle,
> > >
> > > I know you are still slammed but wanted to see if you had the chance to
> > > place this request or if it was something I could do as I wanted to get
> > > Aleks up and going as it's proving problematic for a number of our GSOC
> > > aspirants to not be able to fully grok the functionality of Fineract CN
> > > without having access to a web app. For many the high hardware
> > requirements
> > > is proving to be an insurmountable barrier. Applications are due by the
> > > 27th so I was hoping by early next week we might be able to get this
> > setup.
> > >
> > > Cheers,
> > >
> > > Ed
> > >
> > > On Mon, Mar 12, 2018 at 7:20 AM, Ed Cable  wrote:
> > >
> > > > Myrle,
> > > >
> > > > Robert Jakech and Aleksander Vidakovic have volunteered to assist.
> I'll
> > > > let you move forward with the process and let you provide them the
> > > > necessary information to allow them to get access to infrstructure
> and
> > > get
> > > > continuous build process going for the community to have access to a
> > > > publicly available instance of the demo server.
> > > >
> > > > Ed
> > > >
> > > > On Thu, Mar 8, 2018 at 6:26 AM, Myrle Krantz 
> wrote:
> > > >
> > > >> On Wed, Mar 7, 2018 at 9:25 PM, Ed Cable  wrote:
> > > >> > Hi all, I wanted to give this thread a new subject line as it's a
> > > >> valuable
> > > >> > discussion that had gone beyond the original topic. I'm especially
> > > >> thinking
> > > >> > about this in the context of new potential contributors that are
> > > coming
> > > >> > along for GSOC that won't have the proper hardware to build and
> > > deploy.
> > > >> >
> > > >> > While you all are continuing the discussion around dockerization
> of
> > > >> > services, running from a single process, and running microservices
> > > >> > selectively, I wanted to raise the request that Myrle and I had
> > > >> discussed
> > > >> > around requesting a VM from the Apache infrastructure to use to
> > > deploy a
> > > >> > public demo server for the community. This would provide a tool
> for
> > > >> users
> > > >> > and partners to quickly evaluate and keep progress of
> functionality
> > > but
> > > >> > more importantly allow web and mobile devs to test their changes
> > > without
> > > >> > having to build the entire project locally.
> > > >> >
> > > >> > Myrle can we request such infrastructure?
> > > >>
> > > >> I'll request if we have someone who will take on the deployment.  Do
> > we?
> > > >>
> > > >> Best Regards,
> > > >> Myrle
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > *Ed Cable*
> > > > President/CEO, 

Re: Reducing Barriers to Entry for New Contributors WAS [ Re: GSoC 2018: Fineract CN SMS & Email Notifications]

[Viswa Ramamoorthy]

 Hello,
My 2 cents...
Assuming a) all of 30+ services (gtihub.com/apache/fineract-cn-*) to be 
deployed as individual micro servicesb) in a single VM (this is the quickest as 
more maturity needed for multi VM deployments) c) usage purpose is for 
integration environment for functional test & demo
I would say 8 core/24 GB/250 GB would be minimum spec.
For future service additions, a second VM  can be added to make it a cluster. 
To prepare towards support for deployments in multiple VMs, deployment strategy 
like Docker needs to be matured. There are other ways to deploy services across 
multiple VMs. In my opinion, Docker with swarm or Kubernetes would be a very 
good candidate
RegardsViswa Ramamoorthy
 
On ‎Saturday‎, ‎March‎ ‎17‎, ‎2018‎ ‎06‎:‎45‎:‎48‎ ‎PM‎ ‎EDT, Ed Cable 
 wrote:  
 I'm not sure the process as it's not well documented nor do I know the
virtual machine requirements for Fineract CN but I created the ticket and
would appreciate others from PMC to put in comments the specifics required
for the instance: https://issues.apache.org/jira/browse/INFRA-16203

Thanks,

Ed

On Sat, Mar 17, 2018 at 9:01 AM, Myrle Krantz  wrote:

> Hey Ed,
>
> It’s just a matter of putting in an Infra ticket. Anyone on the PMC can do
> it.
>
> Regards,
> Myrle
>
> On Sat 17. Mar 2018 at 08:50 Ed Cable  wrote:
>
> > Myrle,
> >
> > I know you are still slammed but wanted to see if you had the chance to
> > place this request or if it was something I could do as I wanted to get
> > Aleks up and going as it's proving problematic for a number of our GSOC
> > aspirants to not be able to fully grok the functionality of Fineract CN
> > without having access to a web app. For many the high hardware
> requirements
> > is proving to be an insurmountable barrier. Applications are due by the
> > 27th so I was hoping by early next week we might be able to get this
> setup.
> >
> > Cheers,
> >
> > Ed
> >
> > On Mon, Mar 12, 2018 at 7:20 AM, Ed Cable  wrote:
> >
> > > Myrle,
> > >
> > > Robert Jakech and Aleksander Vidakovic have volunteered to assist. I'll
> > > let you move forward with the process and let you provide them the
> > > necessary information to allow them to get access to infrstructure and
> > get
> > > continuous build process going for the community to have access to a
> > > publicly available instance of the demo server.
> > >
> > > Ed
> > >
> > > On Thu, Mar 8, 2018 at 6:26 AM, Myrle Krantz  wrote:
> > >
> > >> On Wed, Mar 7, 2018 at 9:25 PM, Ed Cable  wrote:
> > >> > Hi all, I wanted to give this thread a new subject line as it's a
> > >> valuable
> > >> > discussion that had gone beyond the original topic. I'm especially
> > >> thinking
> > >> > about this in the context of new potential contributors that are
> > coming
> > >> > along for GSOC that won't have the proper hardware to build and
> > deploy.
> > >> >
> > >> > While you all are continuing the discussion around dockerization of
> > >> > services, running from a single process, and running microservices
> > >> > selectively, I wanted to raise the request that Myrle and I had
> > >> discussed
> > >> > around requesting a VM from the Apache infrastructure to use to
> > deploy a
> > >> > public demo server for the community. This would provide a tool for
> > >> users
> > >> > and partners to quickly evaluate and keep progress of functionality
> > but
> > >> > more importantly allow web and mobile devs to test their changes
> > without
> > >> > having to build the entire project locally.
> > >> >
> > >> > Myrle can we request such infrastructure?
> > >>
> > >> I'll request if we have someone who will take on the deployment.  Do
> we?
> > >>
> > >> Best Regards,
> > >> Myrle
> > >>
> > >
> > >
> > >
> > > --
> > > *Ed Cable*
> > > President/CEO, Mifos Initiative
> > > edca...@mifos.org | Skype: edcable | Mobile: +1.484.477.8649
> > > <(484)%20477-8649>
> > >
> > > *Collectively Creating a World of 3 Billion Maries | *http://mifos.org
> > >   
> > >
> > >
> >
> >
> > --
> > *Ed Cable*
> > President/CEO, Mifos Initiative
> > edca...@mifos.org | Skype: edcable | Mobile: +1.484.477.8649
> >
> > *Collectively Creating a World of 3 Billion Maries | *http://mifos.org
> >   
> >
>



-- 
*Ed Cable*
President/CEO, Mifos Initiative
edca...@mifos.org | Skype: edcable | Mobile: +1.484.477.8649

*Collectively Creating a World of 3 Billion Maries | *http://mifos.org
    

Re: Reducing Barriers to Entry for New Contributors WAS [ Re: GSoC 2018: Fineract CN SMS & Email Notifications]

[Ed Cable]

I'm not sure the process as it's not well documented nor do I know the
virtual machine requirements for Fineract CN but I created the ticket and
would appreciate others from PMC to put in comments the specifics required
for the instance: https://issues.apache.org/jira/browse/INFRA-16203

Thanks,

Ed

On Sat, Mar 17, 2018 at 9:01 AM, Myrle Krantz  wrote:

> Hey Ed,
>
> It’s just a matter of putting in an Infra ticket. Anyone on the PMC can do
> it.
>
> Regards,
> Myrle
>
> On Sat 17. Mar 2018 at 08:50 Ed Cable  wrote:
>
> > Myrle,
> >
> > I know you are still slammed but wanted to see if you had the chance to
> > place this request or if it was something I could do as I wanted to get
> > Aleks up and going as it's proving problematic for a number of our GSOC
> > aspirants to not be able to fully grok the functionality of Fineract CN
> > without having access to a web app. For many the high hardware
> requirements
> > is proving to be an insurmountable barrier. Applications are due by the
> > 27th so I was hoping by early next week we might be able to get this
> setup.
> >
> > Cheers,
> >
> > Ed
> >
> > On Mon, Mar 12, 2018 at 7:20 AM, Ed Cable  wrote:
> >
> > > Myrle,
> > >
> > > Robert Jakech and Aleksander Vidakovic have volunteered to assist. I'll
> > > let you move forward with the process and let you provide them the
> > > necessary information to allow them to get access to infrstructure and
> > get
> > > continuous build process going for the community to have access to a
> > > publicly available instance of the demo server.
> > >
> > > Ed
> > >
> > > On Thu, Mar 8, 2018 at 6:26 AM, Myrle Krantz  wrote:
> > >
> > >> On Wed, Mar 7, 2018 at 9:25 PM, Ed Cable  wrote:
> > >> > Hi all, I wanted to give this thread a new subject line as it's a
> > >> valuable
> > >> > discussion that had gone beyond the original topic. I'm especially
> > >> thinking
> > >> > about this in the context of new potential contributors that are
> > coming
> > >> > along for GSOC that won't have the proper hardware to build and
> > deploy.
> > >> >
> > >> > While you all are continuing the discussion around dockerization of
> > >> > services, running from a single process, and running microservices
> > >> > selectively, I wanted to raise the request that Myrle and I had
> > >> discussed
> > >> > around requesting a VM from the Apache infrastructure to use to
> > deploy a
> > >> > public demo server for the community. This would provide a tool for
> > >> users
> > >> > and partners to quickly evaluate and keep progress of functionality
> > but
> > >> > more importantly allow web and mobile devs to test their changes
> > without
> > >> > having to build the entire project locally.
> > >> >
> > >> > Myrle can we request such infrastructure?
> > >>
> > >> I'll request if we have someone who will take on the deployment.  Do
> we?
> > >>
> > >> Best Regards,
> > >> Myrle
> > >>
> > >
> > >
> > >
> > > --
> > > *Ed Cable*
> > > President/CEO, Mifos Initiative
> > > edca...@mifos.org | Skype: edcable | Mobile: +1.484.477.8649
> > > <(484)%20477-8649>
> > >
> > > *Collectively Creating a World of 3 Billion Maries | *http://mifos.org
> > >   
> > >
> > >
> >
> >
> > --
> > *Ed Cable*
> > President/CEO, Mifos Initiative
> > edca...@mifos.org | Skype: edcable | Mobile: +1.484.477.8649
> >
> > *Collectively Creating a World of 3 Billion Maries | *http://mifos.org
> >   
> >
>



-- 
*Ed Cable*
President/CEO, Mifos Initiative
edca...@mifos.org | Skype: edcable | Mobile: +1.484.477.8649

*Collectively Creating a World of 3 Billion Maries | *http://mifos.org
  

Re: Reducing Barriers to Entry for New Contributors WAS [ Re: GSoC 2018: Fineract CN SMS & Email Notifications]

[Myrle Krantz]

Hey Ed,

It’s just a matter of putting in an Infra ticket. Anyone on the PMC can do
it.

Regards,
Myrle

On Sat 17. Mar 2018 at 08:50 Ed Cable  wrote:

> Myrle,
>
> I know you are still slammed but wanted to see if you had the chance to
> place this request or if it was something I could do as I wanted to get
> Aleks up and going as it's proving problematic for a number of our GSOC
> aspirants to not be able to fully grok the functionality of Fineract CN
> without having access to a web app. For many the high hardware requirements
> is proving to be an insurmountable barrier. Applications are due by the
> 27th so I was hoping by early next week we might be able to get this setup.
>
> Cheers,
>
> Ed
>
> On Mon, Mar 12, 2018 at 7:20 AM, Ed Cable  wrote:
>
> > Myrle,
> >
> > Robert Jakech and Aleksander Vidakovic have volunteered to assist. I'll
> > let you move forward with the process and let you provide them the
> > necessary information to allow them to get access to infrstructure and
> get
> > continuous build process going for the community to have access to a
> > publicly available instance of the demo server.
> >
> > Ed
> >
> > On Thu, Mar 8, 2018 at 6:26 AM, Myrle Krantz  wrote:
> >
> >> On Wed, Mar 7, 2018 at 9:25 PM, Ed Cable  wrote:
> >> > Hi all, I wanted to give this thread a new subject line as it's a
> >> valuable
> >> > discussion that had gone beyond the original topic. I'm especially
> >> thinking
> >> > about this in the context of new potential contributors that are
> coming
> >> > along for GSOC that won't have the proper hardware to build and
> deploy.
> >> >
> >> > While you all are continuing the discussion around dockerization of
> >> > services, running from a single process, and running microservices
> >> > selectively, I wanted to raise the request that Myrle and I had
> >> discussed
> >> > around requesting a VM from the Apache infrastructure to use to
> deploy a
> >> > public demo server for the community. This would provide a tool for
> >> users
> >> > and partners to quickly evaluate and keep progress of functionality
> but
> >> > more importantly allow web and mobile devs to test their changes
> without
> >> > having to build the entire project locally.
> >> >
> >> > Myrle can we request such infrastructure?
> >>
> >> I'll request if we have someone who will take on the deployment.  Do we?
> >>
> >> Best Regards,
> >> Myrle
> >>
> >
> >
> >
> > --
> > *Ed Cable*
> > President/CEO, Mifos Initiative
> > edca...@mifos.org | Skype: edcable | Mobile: +1.484.477.8649
> > <(484)%20477-8649>
> >
> > *Collectively Creating a World of 3 Billion Maries | *http://mifos.org
> >   
> >
> >
>
>
> --
> *Ed Cable*
> President/CEO, Mifos Initiative
> edca...@mifos.org | Skype: edcable | Mobile: +1.484.477.8649
>
> *Collectively Creating a World of 3 Billion Maries | *http://mifos.org
>   
>

Re: Reducing Barriers to Entry for New Contributors WAS [ Re: GSoC 2018: Fineract CN SMS & Email Notifications]

[Ed Cable]

Myrle,

I know you are still slammed but wanted to see if you had the chance to
place this request or if it was something I could do as I wanted to get
Aleks up and going as it's proving problematic for a number of our GSOC
aspirants to not be able to fully grok the functionality of Fineract CN
without having access to a web app. For many the high hardware requirements
is proving to be an insurmountable barrier. Applications are due by the
27th so I was hoping by early next week we might be able to get this setup.

Cheers,

Ed

On Mon, Mar 12, 2018 at 7:20 AM, Ed Cable  wrote:

> Myrle,
>
> Robert Jakech and Aleksander Vidakovic have volunteered to assist. I'll
> let you move forward with the process and let you provide them the
> necessary information to allow them to get access to infrstructure and get
> continuous build process going for the community to have access to a
> publicly available instance of the demo server.
>
> Ed
>
> On Thu, Mar 8, 2018 at 6:26 AM, Myrle Krantz  wrote:
>
>> On Wed, Mar 7, 2018 at 9:25 PM, Ed Cable  wrote:
>> > Hi all, I wanted to give this thread a new subject line as it's a
>> valuable
>> > discussion that had gone beyond the original topic. I'm especially
>> thinking
>> > about this in the context of new potential contributors that are coming
>> > along for GSOC that won't have the proper hardware to build and deploy.
>> >
>> > While you all are continuing the discussion around dockerization of
>> > services, running from a single process, and running microservices
>> > selectively, I wanted to raise the request that Myrle and I had
>> discussed
>> > around requesting a VM from the Apache infrastructure to use to deploy a
>> > public demo server for the community. This would provide a tool for
>> users
>> > and partners to quickly evaluate and keep progress of functionality but
>> > more importantly allow web and mobile devs to test their changes without
>> > having to build the entire project locally.
>> >
>> > Myrle can we request such infrastructure?
>>
>> I'll request if we have someone who will take on the deployment.  Do we?
>>
>> Best Regards,
>> Myrle
>>
>
>
>
> --
> *Ed Cable*
> President/CEO, Mifos Initiative
> edca...@mifos.org | Skype: edcable | Mobile: +1.484.477.8649
> <(484)%20477-8649>
>
> *Collectively Creating a World of 3 Billion Maries | *http://mifos.org
>   
>
>


-- 
*Ed Cable*
President/CEO, Mifos Initiative
edca...@mifos.org | Skype: edcable | Mobile: +1.484.477.8649

*Collectively Creating a World of 3 Billion Maries | *http://mifos.org
  

Re: Reducing Barriers to Entry for New Contributors WAS [ Re: GSoC 2018: Fineract CN SMS & Email Notifications]

[Ed Cable]

Myrle,

Robert Jakech and Aleksander Vidakovic have volunteered to assist. I'll let
you move forward with the process and let you provide them the necessary
information to allow them to get access to infrstructure and get continuous
build process going for the community to have access to a publicly
available instance of the demo server.

Ed

On Thu, Mar 8, 2018 at 6:26 AM, Myrle Krantz  wrote:

> On Wed, Mar 7, 2018 at 9:25 PM, Ed Cable  wrote:
> > Hi all, I wanted to give this thread a new subject line as it's a
> valuable
> > discussion that had gone beyond the original topic. I'm especially
> thinking
> > about this in the context of new potential contributors that are coming
> > along for GSOC that won't have the proper hardware to build and deploy.
> >
> > While you all are continuing the discussion around dockerization of
> > services, running from a single process, and running microservices
> > selectively, I wanted to raise the request that Myrle and I had discussed
> > around requesting a VM from the Apache infrastructure to use to deploy a
> > public demo server for the community. This would provide a tool for users
> > and partners to quickly evaluate and keep progress of functionality but
> > more importantly allow web and mobile devs to test their changes without
> > having to build the entire project locally.
> >
> > Myrle can we request such infrastructure?
>
> I'll request if we have someone who will take on the deployment.  Do we?
>
> Best Regards,
> Myrle
>



-- 
*Ed Cable*
President/CEO, Mifos Initiative
edca...@mifos.org | Skype: edcable | Mobile: +1.484.477.8649

*Collectively Creating a World of 3 Billion Maries | *http://mifos.org
  

Re: Reducing Barriers to Entry for New Contributors WAS [ Re: GSoC 2018: Fineract CN SMS & Email Notifications]

[Myrle Krantz]

On Wed, Mar 7, 2018 at 9:25 PM, Ed Cable  wrote:
> Hi all, I wanted to give this thread a new subject line as it's a valuable
> discussion that had gone beyond the original topic. I'm especially thinking
> about this in the context of new potential contributors that are coming
> along for GSOC that won't have the proper hardware to build and deploy.
>
> While you all are continuing the discussion around dockerization of
> services, running from a single process, and running microservices
> selectively, I wanted to raise the request that Myrle and I had discussed
> around requesting a VM from the Apache infrastructure to use to deploy a
> public demo server for the community. This would provide a tool for users
> and partners to quickly evaluate and keep progress of functionality but
> more importantly allow web and mobile devs to test their changes without
> having to build the entire project locally.
>
> Myrle can we request such infrastructure?

I'll request if we have someone who will take on the deployment.  Do we?

Best Regards,
Myrle

Reducing Barriers to Entry for New Contributors WAS [ Re: GSoC 2018: Fineract CN SMS & Email Notifications]

[Ed Cable]

Hi all, I wanted to give this thread a new subject line as it's a valuable
discussion that had gone beyond the original topic. I'm especially thinking
about this in the context of new potential contributors that are coming
along for GSOC that won't have the proper hardware to build and deploy.

While you all are continuing the discussion around dockerization of
services, running from a single process, and running microservices
selectively, I wanted to raise the request that Myrle and I had discussed
around requesting a VM from the Apache infrastructure to use to deploy a
public demo server for the community. This would provide a tool for users
and partners to quickly evaluate and keep progress of functionality but
more importantly allow web and mobile devs to test their changes without
having to build the entire project locally.

Myrle can we request such infrastructure?

Ed
-- Forwarded message --
From: "Viswa Ramamoorthy" 
Date: Mar 5, 2018 3:54 PM
Subject: Re: GSoC 2018: Fineract CN SMS & Email Notifications
To: "dev" , "Myrle Krantz" 
Cc: "Isaac Kamga" , "Acha Bill" ,
"Markus Geiss" 

 Hello Myrle,
Thanks for sharing your thoughts on Dockerization of services.
My experience with embedding infrastructure inside application JVM (even
for development purposes) has not been great. In a development, when things
change so much, embedding infrastructure adds additional time to bootstrap
the whole thing when application restarts needed. Having external
infrastructures gives better visibility as well as their failure to start
can be diagnosed better (e.g. a port is not available because another
instance of a infrastructure is already running in the background).
With external infrastructures, installation becomes cumbersome if we go
with installation of infrastructure and every one need to follow those
steps to install to get there. My PR is really to solve that part.
Some of the complexity, that you alluded to, are really complexity of
design/developing in micro services architecture.
Couple of points about logging (that stays within Docker) as well as debug
mode with Docker deployment, are very much solvable with Docker deployment.
Regarding high amount of resources needed for deployment, one strategy that
could be looked into is to provide capability to selectively start services
needed for a feature to complete and leave the full deployment to
integration environments.
If you looking into collapsing micro-services into a single war, for
development purposes, it can be a strategy that would work. But all of the
services need to be using compatible version of frameworks and managing
different configurations can be challenge.
Having infrastructure as Docker can still come handy in day to day
development. I understand the timeline/priority. No problem.
RegardsViswa

On ‎Monday‎, ‎March‎ ‎5‎, ‎2018‎ ‎07‎:‎17‎:‎41‎ ‎AM‎ ‎EST, Myrle Krantz
 wrote:

 Hey Viswa,

It's going to take me a little longer to get to merging and reviewing
this, so please be patient with me.  But a couple of comments while
you're waiting:

1.) That you're not seeing those error messages probably may not mean
they are gone.  It may mean that they are now "hidden" in the docker
image.  That's not ideal for error messages.  It makes debugging
harder when there really is an issue.
2.) Thank you for finding the error with the artifact path.  Consider
submitting a patch to fineract-cn-service-starter.

I'm a bit concerned about the idea of moving this all into docker.
Yes docker is one important method for deploying microservices, and
showing an example of how to use those technologies is important.  But
the demo-server is also there partly to test code and get a local
installation up and running.  When I started on it, my intention was
to support Mark van Veen so that he didn't have to start all the
services and then provision by hand to work on the UI.  Unfortunately
there are serious problems with the demo-server the way it is now.  It
takes a huge amount of resources because it starts every service in
its own process.  Many developers do not have computers with
sufficient resources to run this locally.  At one point, Kuelap
literally bought me a new computer after I had spent a couple of days
unsuccessfully trying to make the demo-server work because Markus had
added a couple more services to it.  Moving these processes into
containers doesn't solve this problem.  Docker works with computing
resources in a shockingly efficient manner, so it probably doesn't
actually make the problem worse, but it does make the problem harder
to solve.

Another point, is that currently I can start these services in debug
mode, and attack a debugger to them to understand tricky problems.  I
don't know how to do that in a docker container.  Any changes in that
direction should consider this use case.

I can see that testing this running in docker might be important for
some of our users and contributors.  But I don't want it to be the
default.