I like option (1) -- that best reflects the model I assumed we were following
Keeping up a configuration file with URL paths seems complicated...
-- nick --
Nick Reid | nick...@villagereach.org
Friendly Neighborhood
Spiderman, Information Systems Group
VillageReach Starting
at the Last Mile
2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA
CELL: +1.510.410.0020
SKYPE: nickdotreid
www.villagereach.org
I like option (1) -- that best reflects the model I assumed we were following
Keeping up a configuration file with URL paths seems complicated...
-- nick --
Nick Reid | nick.reid@villagereach.org
Friendly Neighborhood
Spiderman, Information Systems Group
VillageReach Starting at the Last Mile
2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA
CELL: +1.510.410.0020
SKYPE: nickdotreid
www.villagereach.org
From: openlm...@googlegroups.com <openlm...@googlegroups.com> on behalf of Paweł Nawrocki <pnaw...@soldevelo.com>
Sent: Friday, September 23, 2016 9:38:02 AM
To: OpenLMIS Dev
Subject: [openlmis-dev] Developing with Blue vs individual services
Hello everybody!--
We are currently starting to use openlmis-blue as our development environment for usage of multiple services. Each service no longer links another instances to be booted along with it. Instead, we run openlmis-blue to have them all functional and have a look at how they communicate with each other.
The above sentences seem fine, however, there's a problem that now might not be too troublesome, but in future, when we'll have more and more services, it might become really painful for developers.
Right now, in our services, we have urls to our services hardcoded like "http://auth:8080". Of course, our goal would be to have them host-based. This means, that our in-app links for developers would look like, for example, "http://localhost/auth" (or even "http://localhost", but that's not relevant for this issue). This would perfectly work with openlmis-blue settings, as we have our proxy server configured for such routing. However, if any developer would want to run, for example, just referencedata and auth individually (from services' own docker-compose files), without bringing the whole Blue up, the services would no longer communicate correctly, as referencedata would be "http://localhost:8082", auth would be "http://localhost:8081", and referencedata would still call "http://localhost/auth" for communication, and that would of course fail constantly.
This means that a developer would never be able to run just a few services instead of whole openlmis-blue and have them working properly. Also, he would be able to debug only if running singular services, which would be actually useless, because nearly everything needs to contact auth (besides other inter-service communication), and that wouldn't work. So, I was thinking about a solution to this problem, and there seem to be 2 ways of solving it.
1. Make this similar to blue. We would have something like a basic docker-compose file which runs all the stuff that is essential to our system, like nginx-proxy, consul, db, etc. Then, after running it, developer would just run docker-compose files for individual services (by the way, they would no longer need to have db and log included), and those services would be also automatically registered and being routed to, as they normally would on openlmis-blue. So overall, this would be similar to just running openlmis-blue, but developers would have choice of what they want to run, and more importantly, they could run each service on debug mode.
2. Have a separate configuration for this case. We would have another set of configuration files, stored for example on openlims-config. It would probably consist of alternative docker-compose files, that would run each service under specified port, and sort of envronment file for each, that would contain this service-url mappings that would be used by other services to communicate with it. This would, hovewer, involve additional work for keeping all the references up to date and running them separately.
Let me know which direction you think we should follow.
Regards,Paweł
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/0ed91c23-cfad-4ca1-80f3-57921194cb56%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/BY2PR02MB330C7D2348E06BFF37FC52E94C80%40BY2PR02MB330.namprd02.prod.outlook.com.
I also think #1 is the way to go. There should be a way to fire up the "minimal platform", to which a dev (or implementation!) could add whichever other services they want.-Darius
On Fri, Sep 23, 2016 at 12:17 PM, Nick Reid <nick...@villagereach.org> wrote:
I like option (1) -- that best reflects the model I assumed we were following
Keeping up a configuration file with URL paths seems complicated...
-- nick --
Nick Reid | nick...@villagereach.org
Friendly Neighborhood
Spiderman, Information Systems Group
VillageReach Starting at the Last Mile
2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA
CELL: +1.510.410.0020
SKYPE: nickdotreid
www.villagereach.org
From: openlm...@googlegroups.com <openlm...@googlegroups.com> on behalf of Paweł Nawrocki <pnaw...@soldevelo.com>
Sent: Friday, September 23, 2016 9:38:02 AM
To: OpenLMIS Dev
Subject: [openlmis-dev] Developing with Blue vs individual services
Hello everybody!--
We are currently starting to use openlmis-blue as our development environment for usage of multiple services. Each service no longer links another instances to be booted along with it. Instead, we run openlmis-blue to have them all functional and have a look at how they communicate with each other.
The above sentences seem fine, however, there's a problem that now might not be too troublesome, but in future, when we'll have more and more services, it might become really painful for developers.
Right now, in our services, we have urls to our services hardcoded like "http://auth:8080". Of course, our goal would be to have them host-based. This means, that our in-app links for developers would look like, for example, "http://localhost/auth" (or even "http://localhost", but that's not relevant for this issue). This would perfectly work with openlmis-blue settings, as we have our proxy server configured for such routing. However, if any developer would want to run, for example, just referencedata and auth individually (from services' own docker-compose files), without bringing the whole Blue up, the services would no longer communicate correctly, as referencedata would be "http://localhost:8082", auth would be "http://localhost:8081", and referencedata would still call "http://localhost/auth" for communication, and that would of course fail constantly.
This means that a developer would never be able to run just a few services instead of whole openlmis-blue and have them working properly. Also, he would be able to debug only if running singular services, which would be actually useless, because nearly everything needs to contact auth (besides other inter-service communication), and that wouldn't work. So, I was thinking about a solution to this problem, and there seem to be 2 ways of solving it.
1. Make this similar to blue. We would have something like a basic docker-compose file which runs all the stuff that is essential to our system, like nginx-proxy, consul, db, etc. Then, after running it, developer would just run docker-compose files for individual services (by the way, they would no longer need to have db and log included), and those services would be also automatically registered and being routed to, as they normally would on openlmis-blue. So overall, this would be similar to just running openlmis-blue, but developers would have choice of what they want to run, and more importantly, they could run each service on debug mode.
2. Have a separate configuration for this case. We would have another set of configuration files, stored for example on openlims-config. It would probably consist of alternative docker-compose files, that would run each service under specified port, and sort of envronment file for each, that would contain this service-url mappings that would be used by other services to communicate with it. This would, hovewer, involve additional work for keeping all the references up to date and running them separately.
Let me know which direction you think we should follow.
Regards,Paweł
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.
To post to this group, send email to openl...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/0ed91c23-cfad-4ca1-80f3-57921194cb56%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/BY2PR02MB330C7D2348E06BFF37FC52E94C80%40BY2PR02MB330.namprd02.prod.outlook.com.
What do you mean by 'deployment'
I feel like there is a thin line between a OpenLMIS that is implemented/configured and OpenLMIS blue
Josh - do you have opinions on this thread?
Nick Reid | nick...@villagereach.org
Friendly Neighborhood
Spiderman, Information Systems Group
VillageReach Starting
at the Last Mile
2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA
CELL: +1.510.410.0020
SKYPE: nickdotreid
www.villagereach.org
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/0DBA00FC-6426-41DF-A81A-BBBEF6B5B8D9%40villagereach.org.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/57ED07F5.5020308%40soldevelo.com.
So is everyone OK with closing this ticket? Or are there any
concerns?
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/779DE6F9-535D-4CC9-BF2D-CAA68274EA77%40villagereach.org.
I agree with Josh that (1) testing and (2) independent development of services are important.
So, debugging *two* services at a time means we are doing it wrong, and we should not assume we are going to need to do this.
-Darius (by phone)
Friendly NeighborhoodSpiderman, Information Systems Group
VillageReach Starting at the Last Mile
2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA
CELL: +1.510.410.0020
SKYPE: nickdotreid
www.villagereach.org
From: openlmis-dev@googlegroups.com <openlm...@googlegroups.com> on behalf of Paweł Nawrocki <pnaw...@soldevelo.com>
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlmis-dev@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/8e843ae5-a83c-46ac-a7ce-0014343fe2a2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/0DBA00FC-6426-41DF-A81A-BBBEF6B5B8D9%40villagereach.org.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/57ED07F5.5020308%40soldevelo.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/779DE6F9-535D-4CC9-BF2D-CAA68274EA77%40villagereach.org.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/02e791d8-8142-62ba-2738-6f340af60257%40soldevelo.com.
I've closed the ticket.
I understand the idea of not needing this from our perspective,
since it's not the perfect way of developing services. Something
that will help stimulate this will be smaller tickets, more along
the lines of services, rather than lines of end user features. But
I am aware it may take time to get there and will not always be
possible.