Skip to content

Limitations

Product limitations

We haven't changed our Data Center applications' architecture to support Kubernetes. So, as is with all our Data Center products, the following limitations still exist:

  • We don't support horizontal or vertical autoscaling in our products. Read about Product scaling.
  • More pods doesn't mean that the application will be more performant.
  • We still have session affinity, so you will need to have a network setup that supports that.

Jira and horizontal scaling

At present there are issues relating to index replication with Jira when immediately scaling up by more than 1 pod at a time.

Indexing improvements

Please note that Jira is actively being worked on to address these issues in the coming releases.

Although these issues are Jira specific, they are exasperated on account of the significantly reduced startup times for Jira when running in a Kubernetes cluster. As such these issues can have an impact on horizontal scaling if you don't take the correct approach.

Bamboo

There are a number of known limitations relating to Bamboo Data Center, these are documented below.

Deployment

With Bamboo DC 8.1 deployments to K8s using the Helm charts are now possible. This release does however contain an issue where partial unattended deployments to K8s do not work.

Unattended setup

Until this issue has been resolved, the recommended approach for deploying Bamboo server is using an unattended approach. That is, providing values to all those properties labeled as REQUIRED and UNATTENDED-SETUP within the values.yaml. This has the added benefit of eliminating any manual intervention (via the setup wizard) required for configuring Bamboo post deployment.

It should also be noted that the property, bamboo.unattendedSetup should be set to true (current default value) for this to work.

Cluster size

At present Bamboo Data Center utilizes an active-passive clustering model. This architecture is not ideal where K8s deployments are concerned.

1 pod clusters only

At present, Bamboo server cluster sizes comprising only 1 pod is the only supported topology for now.

Server and agent affinity

The Bamboo server and Bamboo agents must be deployed to the same cluster. You cannot have Bamboo agents in one cluster communicating with a Bamboo server in another.

When configuring application links between Bamboo server and any Atlassian Cloud server product, the Bamboo server base URL needs to be used. See public issue for more detail.

Import and export of large datasets

At present there is an issue with Bamboo where the /server and /status endpoints become un-usable when performing an export or import of large datasets.

Data migration

For large Bamboo instances we recommend using native database and filesystem backup tools instead of the built in export / import functionality that Bamboo provides. See the migration guide for more details.

The Bamboo Helm chart does however provide a facility that can be used to import data exports produced through Bamboo at deployment time. This can be used by configuring the Bamboo server values.yaml appropriately i.e.

import:
  type: import
  path: "/var/atlassian/application-data/shared-home/bamboo-export.zip"

Using this approach will restore the full dataset as part of the Helm install process.

Platform limitations

These configurations are explicitly not supported, and the Helm charts don’t work without modifications in these environments:

  • Istio infrastructure
    • Due to several reasons, Istio is imposing networking rules on every workload in the Kubernetes cluster that doesn't work with our deployments.
    • The current recommendation is to create an exemption for our workloads if Istio is enabled in the cluster by default.