Solum

Bug #1358462
Comment #6

Comment 6 for bug 1358462

Revision history for this message

Devdatta Kulkarni (devdatta-kulkarni) wrote on 2014-09-08:

I have completed the investigation. Here is the analysis.

TLDR
---------
It is possible for Solum to directly leverage CF Java build pack (and probably other CF build packs as well). For this, what we need is an 'interpreter' that is able to execute the 'detect', 'compile', and 'release' steps of the Java buidpack. Such an interpreter does not have to be part of Solum per se. It could be part of a Docker container that we would use in Solum. This is how Solum currently support Heroku buildpacks.

Details
-----------
CF Java build pack supports three kinds of components -- containers (Tomcat, Play, etc.), jres (openjdk, oracle), and frameworks (jdbc, newrelic, etc.). The primary responsibility of each component is to determine whether, it is applicable to a given application and if so, prepare the application for release. Such determination and preparation for release is accomplished via three phases that each component implements. These are, 'detect', 'compile', and 'release'. Developer of a component is responsible for implementing these interfaces/methods. These methods also form the contract between CF and the component.

When an application repository is passed to CF, it tries the 'detect' step of all the components and picks the first one which is applicable. It then invokes the 'compile' and 'release' steps of that particular component. A buildpack is made up of n such components (c containers, j jres, and f frameworks).

So for Solum to be able to directly use CF build pack, Solum needs to implement the CF-side of contract.

One way to do this is to create a Docker container that has this CF 'interpreter' embedded in it. For reference, see the 'builder' script in progrium:

https://github.com/progrium/buildstep/blob/master/stack/builder

Look at lines 39-41.

Progrium provides the basic interpreter for heroku buildpacks, which also implement a contract that is similar to CF buildpack contract. In lines 39-41, we see that the interpreter is iterating through the list of buildpacks and calling 'detect' on each.
Currently Solum's 'cedarish' language pack uses progrium's Docker container as the starting point. That is how Solum is able to support Heroku buildpacks.

We will need something similar for handling CF buildpacks.

I have completed the investigation. Here is the analysis.

TLDR
---------
It is possible for Solum to directly leverage CF Java build pack (and probably other CF build packs as well). For this, what we need is an 'interpreter' that is able to execute the 'detect', 'compile', and 'release' steps of the Java buidpack. Such an interpreter does not have to be part of Solum per se. It could be part of a  Docker container that we would use in Solum. This is how Solum currently support Heroku buildpacks.

Details
-----------
CF Java build pack supports three kinds of components -- containers (Tomcat, Play, etc.), jres (openjdk, oracle), and frameworks (jdbc, newrelic, etc.). The primary responsibility of each component is to determine whether,  it is applicable to a given application and if so, prepare the application for release. Such determination and preparation for release is accomplished via three phases that each component implements. These are, 'detect', 'compile', and 'release'. Developer of a component is responsible for implementing these interfaces/methods. These methods also form the contract between CF and the component.

So for Solum to be able to directly use CF build pack, Solum needs to implement the CF-side of contract.

One way to do this is to create a Docker container that has this CF 'interpreter' embedded in it. For reference, see the 'builder' script in progrium:

https://github.com/progrium/buildstep/blob/master/stack/builder

Look at lines 39-41.

We will need something similar for handling CF buildpacks.