On Thu, Aug 11, 2016 at 9:59 AM, Sebastian Laskawiec <slaskawi@redhat.com> wrote:
Hey!

I'm working on configuration management in cloud environment [1]. I put some finding in the ticket [1] but let me tell you more about the options I investigated:
  • Kubernetes/OpenShift ConfigMaps [2][3]
    • Those structures are specially designed to hold configuration data in any format (yaml, json, properties, xml, doesn't matter).
    • The configuration can be mounted into a pod as a directory (technically a volume). We can not mount it as a single file. Having said that we would need to either store cloud.xml file separately (standalone/cloud/configuration?) or ask users to build configuration from whole standalone/configuration directory. Both options are valid in my opinion.
  • OpenShift S2I [4] builder
    • S2I builder takes a git repository and a Docker image and combines those two together.
    • We could store a cloud.xml file inside a git repository and modify our infinispan Docker image to support S2I scripts (if cloud.xml is detected in a git repository - replace the default configuration).
    • Unfortunately it's OpenShift specific thing.
  • Extend the Infinispan Docker image
    • We could ask users to extend our Docker image and put their specific configuration there
    • The biggest advantage - it will work regardless to the environment (pure Docker, Kubernetes, OpenShift, doesn't matter)
All options require restarting pods to update configuration (remember, pods were designed to be immutable).

I think we should support 2 options - ConfigMaps for Kubernetes and OpenShift and extending our Docker image for all other use cases (because this option gives the most flexibility).

What do you think?


For static configuration use cases, I think they are all valid options, it's up to the user to pick the right one depending on the environment/use case.
With relation to the S2I specifically, it could be really interesting for the cases when custom code (marshallers, filters, taks, etc) need to be deployed along Infinispan:
the S2I machinery could build those jars, add custom configurations, combine with the jboss/infinispan-server and have it running on Openshift.

When dynamic configuration changes need to be applied, I think [1] is best option.

[1] https://issues.jboss.org/browse/ISPN-6000

Cheers,
Gustavo

 

Thanks
Sebastian


_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev