[JBoss JIRA] (ISPN-6840) Consider using Dogen
by Sebastian Łaskawiec (JIRA)
[ 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)
> Consider using Dogen
> --------------------
>
> Key: ISPN-6840
> URL: https://issues.jboss.org/browse/ISPN-6840
> Project: Infinispan
> Issue Type: Sub-task
> Components: Cloud Integrations
> Reporter: Sebastian Łaskawiec
> Assignee: Sebastian Łaskawiec
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (ISPN-6489) Create (or adjust) autoscaling policies in Openshift
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/ISPN-6489?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec commented on ISPN-6489:
-------------------------------------------
[Kubernetes 1.2 adds alpha support for custom metrics|http://kubernetes.io/docs/user-guide/horizontal-pod-autoscaling]. An Autoscaler component can scale out/in based on exposed metrics.
Things to do in order to support this:
- Expose [cAdvisor|https://github.com/google/cadvisor/blob/master/docs/application_...] configuration. There are at least two options here - colocate them in the same Docker image (a simple Docker Label might be used: {{LABEL io.cadvisor.metric.redis="/var/cadvisor/redis_config.json"}}) or create another container only for exposing the configuration.
- Expose metrics. Even though cAdvisor has been written to be metric format agnostic, it prefers Prometheus metrics. We could use [JMX/Prometheus bridge|https://github.com/prometheus/jmx_exporter].
- [Optional] Add JMX/Prometheus bridge to the library mode.
- Create an autoscaler template and instruction for the users.
> Create (or adjust) autoscaling policies in Openshift
> ----------------------------------------------------
>
> Key: ISPN-6489
> URL: https://issues.jboss.org/browse/ISPN-6489
> Project: Infinispan
> Issue Type: Feature Request
> Components: Cloud Integrations
> Reporter: Sebastian Łaskawiec
> Assignee: Sebastian Łaskawiec
>
> During the conference [Ray|https://twitter.com/saturnism] mentioned that it would be really nice to have Openshift autoscaling policies for Infinispan based on:
> * number of entries (and/or)
> * memory usage
> Some examples might be found in his repos
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (ISPN-6851) EncryptProtocolIT fails after jgroups upgrade
by Vojtech Juranek (JIRA)
[ https://issues.jboss.org/browse/ISPN-6851?page=com.atlassian.jira.plugin.... ]
Vojtech Juranek updated ISPN-6851:
----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/4455
> EncryptProtocolIT fails after jgroups upgrade
> ---------------------------------------------
>
> Key: ISPN-6851
> URL: https://issues.jboss.org/browse/ISPN-6851
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Server
> Affects Versions: 9.0.0.Alpha3
> Reporter: Vojtech Juranek
> Assignee: Vojtech Juranek
>
> After upgrading jgroups to 3.6.10, {{EncryptProtocolIT}} fails with
> {noformat}
> java.lang.AssertionError: expected:<2> but was:<1>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at org.infinispan.server.test.security.jgroups.encrypt.EncryptProtocolIT.testEncryptProtocolRegistered(EncryptProtocolIT.java:98)
> {noformat}
> Also see JGRP-2088 for details
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (ISPN-6851) EncryptProtocolIT fails after jgroups upgrade
by Vojtech Juranek (JIRA)
[ https://issues.jboss.org/browse/ISPN-6851?page=com.atlassian.jira.plugin.... ]
Vojtech Juranek updated ISPN-6851:
----------------------------------
Status: Open (was: New)
> EncryptProtocolIT fails after jgroups upgrade
> ---------------------------------------------
>
> Key: ISPN-6851
> URL: https://issues.jboss.org/browse/ISPN-6851
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Server
> Affects Versions: 9.0.0.Alpha3
> Reporter: Vojtech Juranek
> Assignee: Vojtech Juranek
>
> After upgrading jgroups to 3.6.10, {{EncryptProtocolIT}} fails with
> {noformat}
> java.lang.AssertionError: expected:<2> but was:<1>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at org.infinispan.server.test.security.jgroups.encrypt.EncryptProtocolIT.testEncryptProtocolRegistered(EncryptProtocolIT.java:98)
> {noformat}
> Also see JGRP-2088 for details
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (ISPN-6851) EncryptProtocolIT fails after jgroups upgrade
by Vojtech Juranek (JIRA)
[ https://issues.jboss.org/browse/ISPN-6851?page=com.atlassian.jira.plugin.... ]
Vojtech Juranek commented on ISPN-6851:
---------------------------------------
JGroups {{ENCRYPT}} is deprecated and {{SYM_ENCPRYT}} or {{ASYM_ENRYPT}} should be used instead.
> EncryptProtocolIT fails after jgroups upgrade
> ---------------------------------------------
>
> Key: ISPN-6851
> URL: https://issues.jboss.org/browse/ISPN-6851
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Server
> Affects Versions: 9.0.0.Alpha3
> Reporter: Vojtech Juranek
> Assignee: Vojtech Juranek
>
> After upgrading jgroups to 3.6.10, {{EncryptProtocolIT}} fails with
> {noformat}
> java.lang.AssertionError: expected:<2> but was:<1>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at org.infinispan.server.test.security.jgroups.encrypt.EncryptProtocolIT.testEncryptProtocolRegistered(EncryptProtocolIT.java:98)
> {noformat}
> Also see JGRP-2088 for details
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (ISPN-6851) EncryptProtocolIT fails after jgroups upgrade
by Vojtech Juranek (JIRA)
Vojtech Juranek created ISPN-6851:
-------------------------------------
Summary: EncryptProtocolIT fails after jgroups upgrade
Key: ISPN-6851
URL: https://issues.jboss.org/browse/ISPN-6851
Project: Infinispan
Issue Type: Bug
Components: Test Suite - Server
Affects Versions: 9.0.0.Alpha3
Reporter: Vojtech Juranek
Assignee: Vojtech Juranek
After upgrading jgroups to 3.6.10, {{EncryptProtocolIT}} fails with
{noformat}
java.lang.AssertionError: expected:<2> but was:<1>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:555)
at org.junit.Assert.assertEquals(Assert.java:542)
at org.infinispan.server.test.security.jgroups.encrypt.EncryptProtocolIT.testEncryptProtocolRegistered(EncryptProtocolIT.java:98)
{noformat}
Also see JGRP-2088 for details
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months