That sounds like a good idea. My main worry with how things are right now is that the config will get outdated and you need to keep in check not only with version changes, but any default behaviour changes we make.
I'm happy for it to be a temporary solution for now. Cheers, > On 19 Sep 2017, at 11:30, Sebastian Laskawiec <slask...@redhat.com> 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/templates/infinispan-ephemeral.json#L376 > > On Tue, Sep 19, 2017 at 10:34 AM Tristan Tarrant <ttarr...@redhat.com> 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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño Infinispan, Red Hat _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
