# Copyright 2018-present Open Networking Foundation
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

# This file provides a template of all available configurations in Atomix.
# All options can be configured via *.conf, *.json, or *.properties files.
# Individual options can be overridden in system properties as well.

# The cluster configuration
cluster {
  # The unique cluster identifier. This must match on all nodes to successfully form a cluster.
  cluster-id: atomix

  # The node object defines the local node information.
  node {
    # The node identifier is an optional unique identifier that can be used to communicate with this node. The node
    # ID is also used in the Raft protocol to identify Raft partition group members.
    id: atomix-1

    # The address is the address through which other nodes can reach this node for cluster membership and general
    # communication. The address is a host:port tuple supports DNS lookups.
    address: "localhost:5679"
  }

  # The multicast object defines the configuration for the multicast-based BroadcastService.
  # Multicast must be explicitly enabled in order to use multicast node discovery.
  multicast {

    # To enable multicast, set this value to "true".
    enabled: true

    # The multicast group to be used by the BroadcastService when multicast is enabled..
    group: 230.0.0.1

    # The multicast port to be used by the BroadcastService when multicast is enabled.
    port: 54321
  }

  # Node discovery is an extensible mechanism by which the node joins the Atomix cluster.
  # This is a multicast based discovery configuration. When multicast discovery is used, the node will broadcast
  # its information via the provided multicast group to discover other nodes.
  discovery {

    # The discovery type indicates the discovery provider to use for node discovery.
    type: multicast

    # The failure timeout is the maximum allowed interval after which a peer will be considered dead if a heartbeat
    # has not been received.
    failure-timeout: 10s

    # The failure threshold configures the phi value for the accrual failure detector used in the multicast discovery provider.
    failure-threshold: 10
  }

  # Alternatively, node discovery can be done via the bootstrap discovery provider. The bootstrap provider works by
  # joining a pre-defined list of peers via TCP to discover the complete set of nodes in the cluster.
  discovery {

    # The discovery type indicates the discovery provider to use for node discovery.
    type: bootstrap

    # The list of nodes is a pre-defined set of peers to which to connect via the TCP-based MessagingService to request
    # information about the set of nodes in the cluster. At least one of the provided peers must be reachable in order
    # for the node to successfully join the cluster.
    nodes.1 {
      id: atomix-1
      address: "192.168.122.20:5679"
    }
    nodes.2 {
      id: atomix-2
      address: "192.168.122.21:5679"
    }
    nodes.3 {
      id: atomix-3
      address: "192.168.122.22:5679"
    }
  }
}

# A management group using the Raft consensus protocol.
management-group {
  type: raft
  partitions: 1
  members: [atomix-1]
}

# A primary-backup based management group.
#management-group {
#  type: primary-backup
#  partitions: 1
#}

# A consensus partition group.
partition-groups.consensus {
  type: raft
  partitions: 7
  members: [atomix-1]
}

# A primary-backup (data grid) partition group.
partition-groups.data {
  type: primary-backup
  partitions: 32
}

# An example primitive configuration using a Raft partition group.
primitives.foo {
  # The primitive type
  type: map
  # The protocol to use to replicate the primitive
  protocol {
    # The protocol type can be "multi-raft" or "multi-primary"
    type: multi-raft
    # The "group" indicates the name of the partition group in which to replicate the primitive.
    # The configured partition group must support the protocol indicated in "type" above.
    group: consensus
    # The read consistency indicates the consistency guarantee of reads on a Raft partition.
    # "sequential" reads guarantee state will not go back in time but do not provide a real-time guarantee
    # "linearizable-lease" reads guarantee linearizability assuming clock accuracy
    # "linearizable" guarantees linearizable reads by verifying the Raft leader
    read-consistency: sequential
    # The communication strategy indicates the node(s) to which the primitive should communicate in each partition.
    # "leader" indicates the primitive should communicate directly with the Raft leader
    # "followers" indicates the primitive should favor Raft followers
    # "any" indicates the primitive can communicate with any node in each partition
    communication-strategy: any
  }
}

# An example primitive configuration using a primary-backup partition group.
primitives.bar {
  # The primitive type
  type: set
  # The protocol to use to replicate the primitive
  protocol {
    # The protocol type can be "multi-raft" or "multi-primary"
    type: multi-primary
    # The "group" indicates the name of the partition group in which to replicate the primitive.
    # The configured partition group must support the protocol indicated in "type" above.
    group: data
    # The "consistency" is a primary-backup specific setting indicating whether the primitive should communicate
    # with the primary or backups on reads.
    consistency: sequential
    # The "replication" is a primary-backup specific setting indicating whether replication should be
    # "synchronous" or "asynchronous"
    replication: asynchronous
    # The "backups" indicates the number of copies to replicate in addition to the primary copy.
    # In other words, "2" backups means the primitive will be replicated on 3 nodes in each partition.
    backups: 2
    # "max-retries" is the maximum number of attempts to allow for any read or write.
    max-retries: 2
    # The "retry-delay" is the time to wait between retries.
    retry-delay: 100ms
  }
}