Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Spike on how extensions are built and published

Description

came up with a mechanism for extension points of a service that could be built and ran locally.

However there are 2 issues related to build and deployment we need to solve for in order for this to really be viable in our dockerized environment:
1. left the solution to building an extension module against extension points with the mainProjectPath solution. This required a developer to checkout the main service so that the extension points could be built off of this. This would be difficult to achieve in CI and requires a developer to go through extra steps. Our first thought was that we'd publish the Service to maven so that the extension could simply list it as an dependancy. This would work, but we'd need to be publishing the service to two locations: Docker Hub and Maven. and should address this.
2. The extension point once built ends up as a JAR that is then host mounted into the service during deployment of the reference distribution. This would not work well in CD as host mounts aren't recommended. We'd need a solution to this. Current thought is that a best practice might be to publish the extension module's JAR as a docker data container, that could then be composed with the service (using container volumes) during deployment.

Acceptance Criteria:

  • Service extension publishing (Maven and DockerHub or alternative) is known and accepted and works in CI/CD

  • Extension point publishing doesn't use host mounts and works in a dockerized way with CI/CD.

Reference:

FELOMIS-99: http://review.openlmis.org:7788/cru/FEOLMIS-99
Dev discussion: https://groups.google.com/d/msg/openlmis-dev/9jTd-RE1qeo/bPXugrOWBQAJ

QAlity Plus - Test Management

Checklists

Activity

Show:

Josh Zamor November 1, 2016 at 9:43 PM

I updated OLMIS-1283's criteria, also I spotted that a step was missing in that the extension module also needs to be published to Maven as OLMIS-1288.

Brandon Bowersox-Johnson November 1, 2016 at 8:32 PM
Edited

I added a few comments on OLMIS-1283. But otherwise I feel this ticket (1124 here) can be considered Done. The "spike" has been achieved and it's clear there is a specific plan of action represented in those tickets.

Update: Josh, I re-assigned this one (1124) back to you. When you respond to that comment in 1283, feel free to move to Done.

Josh Zamor November 1, 2016 at 7:02 PM

, this ticket escaped my attention in that I didn't add it to any sprint. Darius and I met on this, output was above, and this happened in Sprint 11. I wrote up the tickets so that extension module work may proceed post-beta in sprint 12 here. I think this is done, and I pulled this ticket into this sprint so we know it's done. If you could review the tickets I mentioned above I'd appreciate it.

Josh Zamor November 1, 2016 at 7:00 PM

Added tickets:


Versioning was handled in OLMIS-1105.

Josh Zamor October 12, 2016 at 11:48 PM

Darius and I met on this today, some salient points on our discussion:

  • It's okay to publish a service to both DockerHub as well as Maven, so long as this is controlled through Jenkins (the version, the timing, etc)

  • We identified again that versioning isn't well hammered out. A service should know it's version - in source hard coded - and that should be useable by Jenkins when it's publishing in the step above.

  • We should be publishing to a version today (currently it's just "latest") so that everyone is working on, and Jenkins is likely overwriting, 3.0-Beta. Then when the service moves on, say 3.0, Jenkins won't be overwriting 3.0-Beta but instead 3.0.

  • Bringing in extension points (the JARs), should indeed follow the docker publishing and data container strategies. A service should have one "partner" container that it's getting it's extension modules from. So an implementation would fork the image creation for extension of that service, publish it (perhaps to their own docker hub spot or private), and then consume the container made from such an image when they launch Blue.

Done
Pinned fields
Click on the next to a field label to start pinning.

Details

Assignee

Reporter

Labels

Components

Sprint

Fix versions

Affects versions

Priority

Parent

Time Assistant

Created October 7, 2016 at 9:26 PM
Updated December 6, 2016 at 8:14 PM
Resolved November 1, 2016 at 10:43 PM