docs: adds an adr for clustering

adr/0001-record-architecture-decisions.md

@@ -0,0 +1,23 @@
+# 1. Record architecture decisions
+
+Date: 20224-02-04
+
+## Status
+
+Accepted
+
+## Context
+
+> NOTE:
+>
+> This file was automatically created when we used [adr-tools](https://github.com/npryce/adr-tools) to initialize the document log in the repo. ADRs on ADRs are a little silly, but it does give a lightweight way to direct the reader over to our contributor guide that has a lot more information.
+
+We need to record the architectural decisions made on this project.
+
+## Decision
+
+We will use Architecture Decision Records, as [described by Michael Nygard](http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions), with a couple of small tweaks. See the [Documentation section in the Contributor guide](../CONTRIBUTING.md#documentation) for full details.
+
+## Consequences
+
+See Michael Nygard's article, linked above. For a lightweight ADR toolset, see Nat Pryce's [adr-tools](https://github.com/npryce/adr-tools).

adr/0002-clustering-istio-exception.md

@@ -0,0 +1,26 @@
+# 0002. Clustering for Atlassian products
+
+Date: 21 October 2024
+
+## Status
+
+**STATUS** Accepted
+
+## Context
+
+Per Atlassian documentation, Istio interferes with Atlassian products' ability to function properly, especially when running the programs in a clustered scenario. Some issues that arise when more than one instance in the cluster is present include session loss, login loops, data loss, etc.
+
+### Attempted Solutions
+
+- Disable PeerAuthentication in the Istio sidecar: The idea behind this solution was to prevent Istio from encrypting the traffic between the instances. However, this traffic still passes through Istio, which disrupts clustering.
+- Remove Istio entirely from the namespace: This solution eliminates all encryption of traffic within the namespace, allowing multiple instances to communicate freely and function properly. However, this approach compromises traffic security and is not ideal from a security standpoint.
+- Add PodAnnotations to exclude specific inbound/outbound ports: By using annotations such as traffic.sidecar.istio.io/excludeOutboundPorts: 40001,40011, Istio remains in the namespace but does not interfere with instance-to-instance traffic. This solution enabled full clustering functionality for the instances.
+- Forego clustering and allocate maximum resources to a single instance.
+
+## Decision
+
+Since the customer will eventually have 1000+ users, a single Jira or Confluence node will not be sufficient. Clustering is, therefore, a must-have requirement. As such, we have decided to proceed with Solution #3.
+
+## Consequences
+
+Excluding specific ports from Istio, rather than removing it entirely, is the least disruptive way to mitigate risk while maintaining full functionality. This approach, combined with a DestinationRule to manage session cookies, allows the end user to leverage clustering while keeping the instances within the service mesh.

adr/template.md

@@ -0,0 +1,19 @@
+# NUMBER. TITLE
+
+Date: DATE
+
+## Status
+
+STATUS
+
+## Context
+
+The issue motivating this decision, and any context that influences or constrains the decision.
+
+## Decision
+
+The change that we're proposing or have agreed to implement.
+
+## Consequences
+
+What becomes easier or more difficult to do and any risks introduced by the change that will need to be mitigated.