Yevhen Atlassian Team

@kube130 Fluentd is optional and not included by default. It's just an option to aggregate and send logs to a backend with Fluentd sidecar in case there's no centralized logging solution in the cluster.

Yes, a liveness probe would restart the container since the server never listens on 8080. Once again - the logs you shared show no errors at all, and perhaps it's worth grabbing logs from ${JIRA_INSTALL_DIR}/logs Though Jira isn't officially supported on OpenShift I have been running it in OCP 4.8+ (and a local CodeReady…

@sreenivasulu vadde also we have added below parameters under addtionalajvmparameters but still we are getting SSL PKI error when we use ldaps in user directory for connecting ldap server - -Djavax.net.ssl.trustStore=/opt/java/openjdk/lib/security/cacerts - -Djavax.net.ssl.trustStorePassword=XXX Can you confirm your ldap…

@SEKHAR A I don't think just the deployment method defines how much resources you need to allocate to Jira container. If you see performance issues, I'd suggest taking thead dumps and analyzing those or simply bump memory/cpu requests and limits. You may also scale Jira horizontally, i.e. scale Jirta statefulset. Other…

@Alberto Aragón I don't see any permission issues or anything related to OpenShift (yes, I understand anyuid isn't an option due to security concerns). So, logs are stuck at Starting the Jira plugin system? Have you waited long enough and made sure it's stuck there? Also, can you check logs in Jira install dir perhaps (in…

@Rekha Khandhadia jdbc url has nothing to do with the app route. Yes, edge is the way to go, so that tls termination happens on the OpenShift router level. So, Jira is finally up and running?

@Alberto Aragón is allowing anyiud for the service account an option for you? I mean leat the container run as 2001 user (or whatever user is defined in the Dockerfile)? You may also make /opt/atlassian/jira writable for root group in your custom Dockerfile. The chunks of log you have shared are warnings and not critical…

I have checked your values yaml. Nothing special in there. And yes, the typical way to scale Confluence is to deploy with 1 replica and then scane the statefulset directly or updated replicas in values and helm upgrade it. Have you checked the link I have checked in a previous comment? I wonder if diagnosis and…

Also, there's another article https://confluence.atlassian.com/confkb/confluence-will-not-start-due-to-fatal-error-in-confluence-cluster-179439771.html which can help

@Phong Vũ Quốc I deployed with pretty much standard values. Can you share your confluence statefulset yaml and your values file?

@Rekha Khandhadia can you please share your route yaml? It looks like you reencrypt the request or passthough. In other words, you make https request to the backend which expects http (Jira server in this case).

@Rekha Khandhadia you do not need to build any custom image to be able to run Jira on OpenShift. All permissions issues can be mitigated by adding runtime volumes. Have you seen my most recent response? As far as I understand, Jira container starts which means there are no issues with scc. In OpenShift your containers…

I'd suggest checking access log and looking at IP there. It can be your ingress pod IP or a node IP. In any case, I guess whitelisting a CIDR is a way to go.

@Alberto Aragón OpenShift isn't officially supported but it is possible to deploy. Can you please share info on what exactly fails when you deploy to OpenShift?

@Rekha Khandhadia regarding database encryption error, I have found a similar thread https://community.atlassian.com/t5/Jira-questions/Jira-won-t-start-after-hard-reboot-due-to-password-decryption/qaq-p/1224018 Have you tried flushing everything, including PVCs, and running again? Also, it's worth checking if there are…

Jira data is your local home.

@Rekha Khandhadia why the same? * local-home: /var/atlassian/application-data/jira * shared-home:/var/atlassian/application-data/shared-home Two different mountPaths.

@Rekha Khandhadia Local home should be /var/atlassian/application-data/jira and shared home /var/atlassian/application-data/shared-home

@Rekha Khandhadia wrong mountPath? It should be /opt/atlassian/jira/logs not /opt/jira/atlassian/logs

@Rekha Khandhadia OpenShift runs pods with a non privileged user having UID from a predefined range. When Jira starts, it cannot write a log file. There are a couple of fixes here: * run as root (i.e. allow anyuid scc for your service account) * build a custom image and make /opt/atlassian/jira writable for root group…

@Phong Vũ Quốc to me it looks like the database PV wasn't flushed and somehow you are using an existing database. It's just a theory though. This KB may help a bit. I failed to reproduce it in my lab cluster. Perhaps, it's worth trying running a test deployment with an in memory database just to see if it makes a…

@Phong Vũ Quốc Confluence DC uses Hazelcast K8s discovery method. How did you deploy your Confluence DC? Official Helm charts? K8s discovery method is configured by default.

Pradeep, let me try answering your questions: 1. If you are using RollingUpgrade policy you need to enable ZDU mode 2. No it's not required. If you declared any additional plugins in values.yaml they will be persisted in the volumes 3. No, there's no need to clean up local home directory

@Pradeep Naramaneni it's better if you upgrade the entire Helm chart. See: Upgrades. Technically, you can just update image in the stateful set, however, the latest Helm chart version may have some important bug fixes. Please, do not use latest tag, it's always better to know what exact product version is pulled.

Hi Steve! If you change db values in values.yaml and run helm upgrade you should see these changes in container env, for example ATL_JDBC_URL or ATL_JDBC_USER. These envs are then used in the image entrypoint to generate configuration xmls. In case of dbconfig.xml, it's overwrite=False, i.e. this particular file generation…

@Sandra Carrillo if migration to OpenShift is in question, the mentioned dataset does not look too big and you can anticipate pretty fast and smooth migration.

@Konrad Garus can you please file an issue at https://github.com/atlassian/data-center-helm-charts?

@Himanshu Sinha I can only recommend looking at your available worker node capacity and trying the smallest cpu request possible - say 10m. Perhaps, you have other workloads that reserve cpu resources?

@Himanshu Sinha experiment with cpu request. So far, it's purely K8s issue - the cluster does not have a worker node with enough cpu. And yes, if the node has 2 vcpu it does not mean all of them are allocatable. Try with a small request like 500m for example.

@Himanshu Sinha sorry, wrong pod name, it's rel-test-1-bitbucket-0 - the one that is in a Pending state.