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" <viswaramamoor...@yahoo.com.invalid>
Date: Mar 5, 2018 3:54 PM
Subject: Re: GSoC 2018: Fineract CN SMS & Email Notifications
To: "dev" <dev@fineract.apache.org>, "Myrle Krantz" <my...@apache.org>
Cc: "Isaac Kamga" <isaac.ka...@mifos.org>, "Acha Bill" <achabil...@gmail.com>,
"Markus Geiss" <m...@apache.org>
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
<my...@apache.org> 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. I would feel more comfortable with your change sets if you
made this "more optional".
My first priority for this project is to enable contributors. To do
that, I'd like to look for ways to run all of the services in one
process for the purposes of local testing and debugging.
Best Regards,
Myrle Krantz
Committer, Apache Fineract
On Fri, Mar 2, 2018 at 3:35 AM, Viswa Ramamoorthy
<viswaramamoor...@yahoo.com.invalid> wrote:
> Hi,
> I have raised a PR with docker compose yml for Eureka and ActiveMQ.
> It is https://github.com/apache/fineract-cn-demo-server/pull/3
> Please note that after I launch Eureka and ActiveMQ via Docker, I do not
see JMS connect error as well as Eureka registration error anymore.
> But service launch was failing with below errorCould not find artifact
io.mifos.provisioner:service-boot:jar:0.1.0-BUILD-SNAPSHOT
> Locally was able to fix artifact path to "org.apache.fineract.cn." in
fineract-cn-service-starter and move forward with service launch.
> But there were more errors. I have not looked into further yet.
> I think demo server needs some more work to get it to work consistently.
All of the services can be launched via shell script if there are no start
up dependencies between them
> Regards
> Viswa
