Hey Galder,
Comments inlined.
Thanks,
Seb
On Fri, Mar 2, 2018 at 11:37 AM Galder Zamarreño <galder(a)redhat.com> wrote:
Hi,
Looking at [1] and I'm wondering why the templates have to maintain a
different XML file for OpenShift?
We already ship an XML in the server called `cloud.xml`, that should
just work. Having a separate XML file in the templates means we're
duplicating the maintainance of XML files.
Also, users can now create caches programmatically. This is by far the
most common tweak that had to be done to the config. So, I see the
urgency to change XML files less immediate.
So just to give you guys a bit more context - the templates were created
pretty long time ago when we didn't have admin capabilities in Hot Rod and
REST. The main argument for putting the whole configuration into a
ConfigMap was to make configuration changes easier for the users. With
ConfigMap approach they can log into OpenShift UI, go to Resources ->
ConfigMaps and edit everything using UI. That's super convenient for
hacking in my opinion. Of course, you don't need to do that at all if you
don't want. You can just spin up a new Infinispan cluster using `oc
new-app`.
There are at least two other ways for changing the configuration that I can
think of. The first one is S2I [1][2] (long story short, you need to put
your configuration into a git repository and tell OpenShift to build an
image based on it). Even though it may seem very convenient, it's OpenShift
only solution (and there are no easy (out of the box) options to get this
running on raw Kubernetes). I'm not judging whether it's good or bad here,
just telling you how it works. The other option would be to tell the users
to do exactly the same things we do in our templates themselves. In other
words we would remove configuration from the templates and provide a manual
for the users how to deal with configuration. I believe this is exactly
what Galder is suggesting, right?
Recently we implemented admin commands in the Hot Rod. Assuming that caches
created this way are not wiped out during restart (that needs to be
checked), we could remove the configuration from the templates and tell the
users to create their caches over Hot Rod and REST. However we still need
to have a back door for modifying configuration manually since there are
some changes that can not be done via admin API.
[1]
https://github.com/openshift/source-to-image
[2]
https://github.com/jboss-dockerfiles/infinispan/blob/master/server/.s2i/b...
Sure, there will always be people who modify/tweak things and that's
fine. We should however show the people how to do that in a way that
doesn't require us to duplicate our maintanence work.
If we think about further maintenance, I believe we should take more things
into consideration. During the last planning meeting Tristan mentioned
about bringing the project and the product closer together. On the Cloud
Enablement side of things there are ongoing experiments to get a community
images out.
If we decided to take this direction (the CE way), our templates would need
to be deprecated or will change drastically. The image will react on
different set of variables and configuration options.
Also, if we want to show the users how to use a custom XML file, I don't
think we should show them how to embedd it in the template as JSON
[2]. It's quite a pain. Instead, the XML should be kept as a separate
file and the JSON file reference it.
I'm still struggling to understand why this is a pain. Could you please
explain it a bit more? If you look into the maintenance guide [3], there
are only a few steps. For me it takes no longer than 15 minutes to do the
upgrade. You also mentioned on IRC that this approach is a pain for our
users (I believe you mentioned something about Ray). I also can not
understand why, could you please explain it a bit more?
[3]
https://github.com/infinispan/infinispan-openshift-templates#maintenance-...