Hi, I was looking at the Infinispan OpenShift template repo [1], and I started questioning why this repo contains Infinispan configurations for the cloud [2]. Shouldn't these be part of the Infinispan Server distribution? Otherwise this repo is going to somehow versioned depending on the Infinispan version... Which lead me to think, should repo [1] exist at all? Why aren't all its contents part of infinispan/infinispan? The only reason that I could think for keeping a different repo is maybe if you want to version it according to different OpenShift versions, but that could easily be achieved in infinispan/infinispan with different folders.

On 19 Sep 2017, at 11:30, Sebastian Laskawiec <slaskawi(a)redhat.com&gt; wrote: Hey Galder, That sounds like an interesting idea but let me give some more context and propose other options... So during the first iteration I wanted to create templates inside OpenShift Template Library [1]. However it turned out that this repo works in a very specific way - it pulls templates from other repositories and puts them in one, single place. According to my knowledge there are plans to use it OpenShift Online (I can tell you more offline). This is why I came up with a separate repository only for templates and image streams. When adding more and more features to the templates, my goal was to externalize configuration into a ConfigMap. This makes it very convenient for editing in OpenShift UI. The main problem is how to put it there? The easiest way was to hardcode it inside a template (and I decided to go that way). But a much more robust approach would be to spin up a small container (maybe an Init Container??) that would pull proper version of Infinispan and use Kubernetes REST API to create that ConfigMap on the fly. I'm not sure if putting templates into Infinispan repository would solve our problems. Although granted, we would have an easy access to configuration but still providing custom Docker image [2] (possibly with custom configuration) is something I expect to happen frequently. Also I'm not a big fan of putting many bits in a single repository. So having said that, I believe the proper way is to implement a small container (maybe an Init Container or just a script inside the same Docker image) responsible for unpacking desired Infinispan package and creating ConfigMap directly in Kubernetes. WDYT? Thanks, Sebastian [1] https://github.com/openshift/library [2] https://github.com/infinispan/infinispan-openshift-templates/blob/master/... On Tue, Sep 19, 2017 at 10:34 AM Tristan Tarrant <ttarrant(a)redhat.com&gt; wrote: On 9/19/17 9:42 AM, Galder Zamarreño wrote: > Hi, > > I was looking at the Infinispan OpenShift template repo [1], and I started questioning why this repo contains Infinispan configurations for the cloud [2]. Shouldn't these be part of the Infinispan Server distribution? Otherwise this repo is going to somehow versioned depending on the Infinispan version... > > Which lead me to think, should repo [1] exist at all? Why aren't all its contents part of infinispan/infinispan? The only reason that I could think for keeping a different repo is maybe if you want to version it according to different OpenShift versions, but that could easily be achieved in infinispan/infinispan with different folders. It was created separately because its release cycle can be much faster. Once things settle we can bring it in. Tristan -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev