On Thu, Aug 11, 2016 at 9:59 AM, Sebastian Laskawiec <slask...@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 > > [1] https://issues.jboss.org/browse/ISPN-6675 > [2] http://kubernetes.io/docs/user-guide/configmap/ > [3] https://docs.openshift.org/latest/dev_guide/configmaps.html > [4] https://github.com/openshift/source-to-image > > _______________________________________________ > 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
