jbossas / eap-charts Goto Github PK

Right now, all Helm Charts (eap74, eap-xp3) are developed in the main branch.

This is not suitable for maintenance as it is difficult to track which commits affect one or the other charts (that have different lifecycle).

Instead, each chart should be maintained in its own branch (eap74, eap-xp3).
They would still all be made available from https://jbossas.github.io/eap-charts/.

The release workflow would have to change: for all maintained branches, we will use the Helm Chart Releaser action to release a new chart every time a chart version is updated.

During maintenance, we would contribute PR to fix issues as usual.
The last step before release will be the update of the Chart version to trigger the release of the new Helm Chart.

Actions:

• EAP 7.4
  • create eap74 and eap74-dev branches
  • copy the chart and examples for the eap74 branch into the eap74 branch (and keep the history)
  • delete the chart and examples for the eap74 from the main branch
• EAP XP 3 and XP 4
  • nothing to do, they will stay on main
• EAP 8
  • create a eap8 and eap8-dev branch
• update the helm.yaml GH action to run it against any branch (other than gh-pages and *-dev ones)

Describe the bug
None of the container platform resources are configured with any limit/quota.

To Reproduce
Steps to reproduce the behavior:

$ helm install eapfoo --debug -f app.yaml -f values.yaml -n default --repo https://jbossas.github.io/eap-charts eap-xp4

Please include if possible the debug output to get the values provided to the chart with

Here we can see the deployer configured with cpu 2000m.

$ helm install eapfoo --debug -f app.yaml -f values.yaml -n default --repo https://jbossas.github.io/eap-charts eap-xp4 |grep -B 5 cpu
install.go:194: [debug] Original chart version: ""
install.go:211: [debug] CHART PATH: /home/whitingjr/.cache/helm/repository/eap-xp4-1.0.0.tgz

client.go:133: [debug] creating 8 resource(s)
  uri: https://github.com/hpehl/first-responder-demo.git
deploy:
  containers:
  - resources:
      requests:
        cpu: 2000m
--
  - name: MP_MESSAGING_CONNECTOR_SMALLRYE_KAFKA_BOOTSTRAP_SERVERS
    value: frdemo-kafka:9092
  maxReplicas: 10
  metrics:
  - resource:
      name: cpu
--
  uri: https://github.com/hpehl/first-responder-demo.git
deploy:
  containers:
  - resources:
      requests:
        cpu: 2000m
--
      port: admin
    initialDelaySeconds: 60
  maxReplicas: 10
  metrics:
  - resource:
      name: cpu

Expected behavior
At least one resource with a cpu 2000m limit.

Component Versions(please complete the following information):

$ helm version
version.BuildInfo{Version:"v3.11", GitCommit:"", GitTreeState:"", GoVersion:"go1.19.6"}
$ oc version
Client Version: 4.12.0-202304070941.p0.g31aa3e8.assembly.stream-31aa3e8
Kustomize Version: v4.5.7
Server Version: 4.10.43
Kubernetes Version: v1.23.12+8a6bfe4
$

Additional context

The Helm Chart for EAP 7.4 is displayed with the name Eap74 in the OpenShift Dev Console which is not following our naming convention.

Instead, it should be displayed as JBoss EAP 7.4 using the charts.openshift.io/name annotation in its Chart.yaml:

annotations:
  charts.openshift.io/name: JBoss EAP 7.4
  charts.openshift.io/supportURL: https://access.redhat.com/support

(I've added the support link which is another annotation we can provide to the OpenShift Dev Console)

Is your feature request related to a problem? Please describe.
I need to configure minimum and maximum replicas for my containers

Describe the solution you'd like
The ability to declare minimum and maximum values.

Describe alternatives you've considered
Patching my Containers/Pod with resource definition in my container platform.

Additional context

Label issues with a good-first-issues label, add a guide for new contributors, and a file identifying code owners of this project.

Is your feature request related to a problem? Please describe.

Add a NOTES to the chart to let the users know the next steps for their applications:

• watch the builds if build is enabled
• watch the deployment if deploy is enabled

Add labels to identify the resource workload for metering:

• com.company: Red_Hat
• rht.prod_name: Red_Hat_Runtimes
• rht.prod_ver: 2021-Q1
• rht.comp: EAP
• rht.comp_ver: <- use the Chart.AppVersion. there might be inconsistencies if the Helm Release overrides this value but it should be only for edge cases (as we will release new version of the Helm Chart for every EAP Minor release)
• rht.subcomp_t: Application

The Helm chart for EAP 8.0 requires a valid Jakarta EE application specified by the build.uri field
to be installable.

This requires the user to figure out which Git repository could be used when they are getting started with the Helm Chart for EAP 8.0.

The Helm chart should instead provide a "default" Jakarta EE application so that a release of the Helm Chart can be installed without any user input to improve the onboarding experience.

A candidate for this default Jakarta EE application is https://github.com/jboss-eap-up-and-running/eap8-getting-started which provides a self-contained Jakarta EE application.

Is your feature request related to a problem? Please describe.

EAP 7.4 provides images for Z-Series and PowerPC that are distinct from the x86 images.
The users must be able to specify they want to use these images.

Describe the solution you'd like

Add a build.s2i.arch property:

• type: string
• allowed values: amd64
• default value: amd64

When the EAP 7.4 images for PPC and Z-Series are released, the constraint will be extended to:

• allowed values: amd64, ppc64le, s390x
• restriction: ppc64le, s390x are valid only when build.s2i.jdk == 11.

The actual builder and runtime images will be determined in the eap74.eapBuilderImage and eap74.eapRuntimeImage
template functions.

The value.yaml will list all the available images:

build:
  s2i:
    version: latest
    arch: "amd64"
    jdk: "11"
    amd64: 
      jdk8:
        builderImage: registry.redhat.io/jboss-eap-7-tech-preview/eap74-openjdk8-openshift-rhel7
        runtimeImage: registry.redhat.io/jboss-eap-7-tech-preview/eap74-openjdk8-runtime-openshift-rhel7
      jdk11:
        builderImage: registry.redhat.io/jboss-eap-7-tech-preview/eap74-openjdk11-openshift-rhel8
        runtimeImage: registry.redhat.io/jboss-eap-7-tech-preview/eap74-openjdk11-runtime-openshift-rhel8

When the EAP 7.4 images for PPC and Z-Series are released, they will be listed in value.yaml:

build:
  s2i:
    ppc64le: 
      jdk11:
        builderImage: registry.redhat.io/jboss-eap-7-tech-preview/eap74-openj9-11-openshift-rhel8
        runtimeImage: registry.redhat.io/jboss-eap-7-tech-preview/eap74-openk9-11-runtime-openshift-rhel8
    s390x: 
      jdk11:
        builderImage: registry.redhat.io/jboss-eap-7-tech-preview/eap74-openj9-11-openshift-rhel8
        runtimeImage: registry.redhat.io/jboss-eap-7-tech-preview/eap74-openk9-11-runtime-openshift-rhel8

Is your feature request related to a problem? Please describe.
I need to configure scaling. With a min and max.

Describe the solution you'd like
To configure somewhere the following

  - resource:
      name: cpu
      target:
        averageUtilization: 95
        type: Utilization
    type: Resource
  minReplicas: 1
  maxReplicas: 5
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: foobar

Describe alternatives you've considered
Patching my resources after deploying to a container platform.

The Helm chart for EAP 7.4 requires a valid Jakarta EE application specified by the build.uri field
to be installable.

This requires the user to figure out which Git repository could be used when they are getting started with the Helm Chart for EAP 7.4.

The Helm chart should instead provide a "default" Jakarta EE application so that a release of the Helm Chart can be installed without any user input to improve the onboarding experience.

A candidate for this default Jakarta EE application is https://github.com/jboss-eap-up-and-running/eap7-getting-started which provides a self-contained Jakarta EE application.

Is your feature request related to a problem? Please describe.
The problem is the containers created currently only support cgroups v1.

Describe the solution you'd like
What is necessary is cgroups v2 support is provided by default. Allowing the JVM to detect container characteristics when deployed in a container environment.
At the moment a jvm checking for the number of available cpu cores will only get what's provided by the host platform.

Describe alternatives you've considered
none

Additional context

jshell> java.lang.Runtime.getRuntime().availableProcessors()
$1 ==> 64

If cgroups v2 is working then in my particular configuration the above should be 2.

sh-4.4$ java -XshowSettings:system -version
Operating System Metrics:
    Provider: cgroupv1
    Effective CPU Count: 64
    CPU Period: 100000us
    CPU Quota: -1
    CPU Shares: -1

Describe the bug
https://jbossas.github.io/eap-charts/ only mentions EAP 7.4

Expected behavior
EAP 8 should be listed, and before 7.4

1. Go to https://jbossas.github.io/eap-charts/.
2. At the very bottom of the page, click on the documentation link in the "A complete documentation of the eap7 Chart is available in its README." sentence.
3. You get 404.