On Tue, Jan 30, 2018 at 6:25 AM, Dilan Udara Ariyaratne
wrote:
> Hi Imesh,
>
> +1 to this suggestion.
>
> My personal experience is that even our users find it confusing to see
> dockerfile definitions for a product or product profile in multiple
> repositories.
> Thus, it
On Mon, Jan 29, 2018 at 7:36 AM, Imesh Gunaratne wrote:
> On Mon, Jan 29, 2018 at 6:58 AM, Muhammed Shariq wrote:
>
>> Hi Imesh / all,
>>
>> Personally, I think the best option going forward is to maintain a single
>> set of docker image across all platforms.
Hi Imesh,
+1 to this suggestion.
My personal experience is that even our users find it confusing to see
dockerfile definitions for a product or product profile in multiple
repositories.
Thus, it would be quite intuitive to have a single source of truth per each
product or product profile in the
On Mon, Jan 29, 2018 at 6:58 AM, Muhammed Shariq wrote:
> Hi Imesh / all,
>
> Personally, I think the best option going forward is to maintain a single
> set of docker image across all platforms. It's true that there is a concern
> of users having to do more work, but in
On Mon, Jan 22, 2018 at 2:46 PM, Pubudu Gunatilaka wrote:
> Hi Imesh,
>
> It is very convenient if we can reuse the docker image. AFAIU if we follow
> the above approach we can use a single docker image in all the container
> platforms.
>
> One of the drawbacks I see with this
In API Manager K8s artifacts, what we have followed is not having an
image-per-profile method. With the introduction of Config Maps, it has
become only two base images - for APIM and Analytics. Its extremely helpful
from the maintenance PoV that we have a single set of Dockerfiles, but has
a
Hi Imesh,
It is very convenient if we can reuse the docker image. AFAIU if we follow
the above approach we can use a single docker image in all the container
platforms.
One of the drawbacks I see with this approach is that the user has to
update the volume mounts with the necessary jar files,
Hi All,
Currently, we build Docker images for each platform (Docker, Kubernetes,
DC/OS, etc) for each WSO2 product profile (EI: Integrator, MB, BPS; API-M:
Gateway, Key Manager, Pub/Store, etc). AFAIU, the main reason to do this
was bundling platform specific JAR files (membership scheme JAR file