[infinispan-issues] [JBoss JIRA] (ISPN-6840) Consider using Dogen

[ https://issues.jboss.org/browse/ISPN-6840?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec edited comment on ISPN-6840 at 7/13/16 7:37 AM: -------------------------------------------------------------------- Since this issue is related to the upstream project as well as JDG, please restrict your comments to Red Hat Employees! h2. Building JDG images JBoss Data Grid OpenShift images are built using tool called [Dogen|https://github.com/jboss-dockerfiles/dogen]. It is responsible for generating Dockerfiles based on YAML specification and a bunch of scripts. For JDG there are two repositories - [the first one|https://gitlab.mw.lab.eng.bos.redhat.com/cloudenablement/jboss-datagr...] is a standalone image with no OSE enhancements whereas [the second one|https://gitlab.mw.lab.eng.bos.redhat.com/cloudenablement/jboss-docker...] contains full OSE support. The images are created using [generate.sh script|https://gitlab.mw.lab.eng.bos.redhat.com/cloudenablement/jboss-doc...]. h2. [JDG 7.1 Roadmap|https://docs.google.com/spreadsheets/d/1wS6g5x-CohhV3n3rFeh7ANAYC...] # Client/Server mode with OSE # Library mode with OSE # Deploying the same image on prem # Multicast within the same OSE project # Adding nodes dynamically # Autoscaling # Graceful shutdown # Rolling updates h2. [Infinispan 9 Roadmap|https://docs.google.com/document/d/1uxe4V0OgHen4Ki-JHPdeKVARo5tPF...] # JGroups discovery # SNI support # Using HTTP/2 upgrade for HotRod protocol # Multi-tenancy # Configuration management # Rolling updates # Autoscaling # Health and readiness monitoring using REST h2. Things Infinispan can reuse from JDG (in terms of OpenShift integration) # KUBE_PING integration. However in the upstream (as well as in JDG 7.1) will also need to support library mode. This means that KUBE_PING needs to be present at least in Infinispan [Uber Jar|https://github.com/infinispan/infinispan/tree/master/all/embedded]. # Liveness and Readiness probe. However we would like to expose more functionality over HTTP. This means that we will need to abandon bash script approach and embrace newly created REST endpoints. See [this JIRA for details|https://issues.jboss.org/browse/ISPN-6679]. # (Optional/not decided yet) Jolokia for collecting metrics, however both Kubernetes and OpenShift collect metrics differently (see comments in [this JIRA|https://issues.jboss.org/browse/ISPN-6489]). Since we will need a unified approach, we probably have to develop some adapters or use some common format (maybe Prometheus?) h2. Additional arguments for using Dogen approach and porting product bits into the upstream * Similar code base between Project and Product. Less bugs, less overall maintenance. * Some of the things will be available out of the box (like Jolokia) h2. Additional arguments against using Dogen approach and sticking with pure Dockerfile as we do now * Much easier to consume by the community (easier to read, less complicated, no Dogen knowledge required) * Almost all features will be implemented the other way around in the community (and possibly should be backported to the product later) was (Author: sebastian.laskawiec): Since this issue is related to the upstream project as well as JDG, please restrict your comments to Red Hat Employees! h3. Building JDG images JBoss Data Grid OpenShift images are built using tool called [Dogen|https://github.com/jboss-dockerfiles/dogen]. It is responsible for generating Dockerfiles based on YAML specification and a bunch of scripts. For JDG there are two repositories used - [the first one|https://gitlab.mw.lab.eng.bos.redhat.com/cloudenablement/jboss-datagr...] is a standalone image with no OSE enhancements whereas [the second one|https://gitlab.mw.lab.eng.bos.redhat.com/cloudenablement/jboss-docker...] contains full OSE support. The images are created using [generate.sh script|https://gitlab.mw.lab.eng.bos.redhat.com/cloudenablement/jboss-doc...]. h3. [JDG 7.1 Roadmap|https://docs.google.com/spreadsheets/d/1wS6g5x-CohhV3n3rFeh7ANAYC...] # Client/Server mode with OSE # Library mode with OSE # Deploying the same image on prem # Multicast within the same OSE project # Adding nodes dynamically # Autoscaling # Graceful shutdown # Rolling updates h3. [Infinispan 9 Roadmap|https://docs.google.com/document/d/1uxe4V0OgHen4Ki-JHPdeKVARo5tPF...] # JGroups discovery # SNI support # Using HTTP/2 upgrade for HotRod protocol # Multi-tenancy # Configuration management # Rolling updates # Autoscaling # Health and readiness monitoring using REST h3. Things Infinispan can reuse from JDG (in terms of OpenShift integration) # KUBE_PING integration. However in the upstream (as well as in JDG 7.1) we also need to support library mode. This means that KUBE_PING needs to be present in at least in Infinispan [Uber Jar|https://github.com/infinispan/infinispan/tree/master/all/embedded]. # Liveness and Readiness probe. However we would like to expose more functionality over HTTP. This means that we will need to abandon bash script approach for this and embrace newly created REST endpoints. See [this JIRA for details|https://issues.jboss.org/browse/ISPN-6679]. # (Optional/not decided yet) Jolokia for collecting metrics, however both Kubernetes and OpenShift do this differently (see comments in [this JIRA|https://issues.jboss.org/browse/ISPN-6489]). Since we will need a unified approach, we probably have to develop some adapters or use some common format (maybe Prometheus?) h3. Additional arguments for using Dogen approach and porting product bits into the upstream * Similar code base between Project and Product. Less bugs, less overall maintenance. * Some of the things will be available out of the box (like Jolokia) h3. Additional arguments against using Dogen approach (sticking with pure Dockerfile as we do now) * Much easier to consume by the community (easier to read, less complicated, no Dogen knowledge required) * Almost all features will be implemented the other way around in the community (and possibly should be backported to the product later) -- This message was sent by Atlassian JIRA (v6.4.11#64026)