### Starting OpenDaylight Karaf Instance (Shell)

Source: https://github.com/fahreddinozcan/doct/blob/master/_context7_rst_markdown_build/getting-started-guide/clustering.md

This command starts the OpenDaylight Karaf instance with specified Java memory settings. It is a prerequisite step before enabling clustering features within the Karaf command line.

```shell
JAVA_MAX_MEM=4G JAVA_MAX_PERM_MEM=512m ./karaf
```

--------------------------------

### Running OpenDaylight Karaf Distribution

Source: https://github.com/fahreddinozcan/doct/blob/master/_context7_rst_markdown_build/getting-started-guide/installing_opendaylight.md

This snippet demonstrates the commands to unzip the OpenDaylight Karaf distribution, navigate to its directory, and start the Karaf environment. It also shows the ASCII art banner that appears upon successful startup.

```bash
$ ls karaf-0.8.x-Oxygen.zip
karaf-0.8.x-Oxygen.zip
$ unzip karaf-0.8.x-Oxygen.zip
Archive:  karaf-0.8.x-Oxygen.zip
   creating: karaf-0.8.x-Oxygen/
   creating: karaf-0.8.x-Oxygen/configuration/
   creating: karaf-0.8.x-Oxygen/data/
   creating: karaf-0.8.x-Oxygen/data/tmp/
   creating: karaf-0.8.x-Oxygen/deploy/
   creating: karaf-0.8.x-Oxygen/etc/
   creating: karaf-0.8.x-Oxygen/externalapps/
   ... 
   inflating: karaf-0.8.x-Oxygen/bin/start.bat
   inflating: karaf-0.8.x-Oxygen/bin/status.bat
   inflating: karaf-0.8.x-Oxygen/bin/stop.bat
$ cd distribution-karaf-0.8.x-Oxygen
$ ./bin/karaf

    ________                       ________                .__  .__       .__     __
    \_____  \ ______   ____   ____ \______ \ _____  ___.__. |  | | \__ | ____ \|  | \__  \|_
     /   \|   \\____ \_/ __ \ /    \ |    |  \__  \ <   \__| |  | |  | |/ ___\\|  |/ __ \|  |
    /    \|    \  \|\> >  ___/|   \|  \|    `   \/ __ \ ___ | |  | |  | / /_/  >   Y  \  |
    \_______  /   __/ \___  >___|  /_______  (____  / ____|\|____/__\___  /|___\|  /__|
            \/|__|        \/     /        \/     \/            /_____/      \/

```

--------------------------------

### Setup and Interact with Git-Review

Source: https://github.com/fahreddinozcan/doct/blob/master/_context7_rst_markdown_build/contributor-guides/newcomers-guide.md

Commands to set up the git-review tool for a cloned repository and to download a specific change (branch) for review. Git-review simplifies the process of submitting changes to Gerrit.

```text
$ cd docs/
$ git-review -s
$ git-review -d <change_number>
```

--------------------------------

### Installing Distributed Datastore Feature (Karaf Console)

Source: https://github.com/fahreddinozcan/doct/blob/master/_context7_rst_markdown_build/getting-started-guide/clustering.md

This Karaf command installs the `odl-mdsal-distributed-datastore` feature, which is essential for enabling clustering capabilities in OpenDaylight. Successful installation creates initial configuration files.

```karaf
feature:install odl-mdsal-distributed-datastore
```

--------------------------------

### reStructuredText Directory Structure Example

Source: https://github.com/fahreddinozcan/doct/blob/master/_context7_rst_markdown_build/documentation.md

An example of a typical directory layout for reStructuredText documentation projects, showing the organization of guides and their subdirectories.

```default
$ tree -L 2
.
├── Makefile
├── conf.py
├── documentation.rst
├── getting-started-guide
│   ├── api.rst
│   ├── concepts_and_tools.rst
│   ├── experimental_features.rst
│   ├── index.rst
│   ├── installing_opendaylight.rst
│   ├── introduction.rst
│   ├── karaf_features.rst
│   ├── other_features.rst
│   ├── overview.rst
│   └── who_should_use.rst
├── index.rst
├── make.bat
├── opendaylight-with-openstack
│   ├── images
│   ├── index.rst
│   ├── openstack-with-gbp.rst
│   ├── openstack-with-ovsdb.rst
│   └── openstack-with-vtn.rst
└── submodules
    └── releng
        └── builder
```

--------------------------------

### OpenDaylight Operational Datastore Shard Manager Response Example

Source: https://github.com/fahreddinozcan/doct/blob/master/_context7_rst_markdown_build/getting-started-guide/clustering.md

An example JSON response from querying the operational datastore's shard manager MBean. It details the local shards, overall synchronization status, and the current member name. This data is essential for identifying specific shards for deeper inspection.

```json
{
  "request": {
    "mbean": "org.opendaylight.controller:Category=ShardManager,name=shard-manager-operational,type=DistributedOperationalDatastore",
    "type": "read"
  },
  "value": {
    "LocalShards": [
      "member-1-shard-default-operational",
      "member-1-shard-entity-ownership-operational",
      "member-1-shard-topology-operational",
      "member-1-shard-inventory-operational",
      "member-1-shard-toaster-operational"
    ],
    "SyncStatus": true,
    "MemberName": "member-1"
  },
  "timestamp": 1483738005,
  "status": 200
}
```

--------------------------------

### Installing Karaf Features

Source: https://github.com/fahreddinozcan/doct/blob/master/_context7_rst_markdown_build/getting-started-guide/installing_opendaylight.md

These commands show how to install single or multiple features within the OpenDaylight Karaf environment. The `feature:install` command is used, accepting feature names as arguments.

```bash
feature:install <feature1>
```

```bash
feature:install <feature1> <feature2> ... <featureN-name>
```

--------------------------------

### Listing Karaf Features

Source: https://github.com/fahreddinozcan/doct/blob/master/_context7_rst_markdown_build/getting-started-guide/installing_opendaylight.md

These commands allow you to list all available features or only the currently installed features in the OpenDaylight Karaf environment. The `-i` flag is used to list installed features.

```bash
feature:list
```

```bash
feature:list -i
```

--------------------------------

### OpenDaylight Shard Detailed Response Example

Source: https://github.com/fahreddinozcan/doct/blob/master/_context7_rst_markdown_build/getting-started-guide/clustering.md

An example JSON response detailing the state of a specific OpenDaylight operational shard. It includes metrics like transaction counts, Raft state (Leader/Follower), peer addresses, follower details, and various synchronization statuses. This data is vital for diagnosing shard behavior and cluster health.

```json
{
  "request": {
    "mbean": "org.opendaylight.controller:Category=Shards,name=member-1-shard-default-operational,type=DistributedOperationalDatastore",
    "type": "read"
  },
  "value": {
    "ReadWriteTransactionCount": 0,
    "SnapshotIndex": 4,
    "InMemoryJournalLogSize": 1,
    "ReplicatedToAllIndex": 4,
    "Leader": "member-1-shard-default-operational",
    "LastIndex": 5,
    "RaftState": "Leader",
    "LastCommittedTransactionTime": "2017-01-06 13:19:00.135",
    "LastApplied": 5,
    "LastLeadershipChangeTime": "2017-01-06 13:18:37.605",
    "LastLogIndex": 5,
    "PeerAddresses": "member-3-shard-default-operational: pekko://opendaylight-cluster-data@192.168.16.3:2550/user/shardmanager-operational/member-3-shard-default-operational, member-2-shard-default-operational: pekko://opendaylight-cluster-data@192.168.16.2:2550/user/shardmanager-operational/member-2-shard-default-operational",
    "WriteOnlyTransactionCount": 0,
    "FollowerInitialSyncStatus": false,
    "FollowerInfo": [
      {
        "timeSinceLastActivity": "00:00:00.320",
        "active": true,
        "matchIndex": 5,
        "voting": true,
        "id": "member-3-shard-default-operational",
        "nextIndex": 6
      },
      {
        "timeSinceLastActivity": "00:00:00.320",
        "active": true,
        "matchIndex": 5,
        "voting": true,
        "id": "member-2-shard-default-operational",
        "nextIndex": 6
      }
    ],
    "FailedReadTransactionsCount": 0,
    "StatRetrievalTime": "810.5 μs",
    "Voting": true,
    "CurrentTerm": 1,
    "LastTerm": 1,
    "FailedTransactionsCount": 0,
    "PendingTxCommitQueueSize": 0,
    "VotedFor": "member-1-shard-default-operational",
    "SnapshotCaptureInitiated": false,
    "CommittedTransactionsCount": 6,
    "TxCohortCacheSize": 0,
    "PeerVotingStates": "member-3-shard-default-operational: true, member-2-shard-default-operational: true",
    "LastLogTerm": 1,
    "StatRetrievalError": null,
    "CommitIndex": 5,
    "SnapshotTerm": 1,
    "AbortTransactionsCount": 0,
    "ReadOnlyTransactionCount": 0,
    "ShardName": "member-1-shard-default-operational",
    "LeadershipChangeCount": 1,
    "InMemoryJournalDataSize": 450
  },
  "timestamp": 1483740350,
  "status": 200
}
```

--------------------------------

### Install Neutron Service Feature in Karaf

Source: https://github.com/fahreddinozcan/doct/blob/master/_context7_rst_markdown_build/user-guide/neutron-service-user-guide.md

Installs the 'odl-neutron-service' Karaf feature while the OpenDaylight controller is running. This command enables the integration of OpenStack Neutron with OpenDaylight.

```karaf
feature:install odl-neutron-service
```

--------------------------------

### Start OpenDaylight Karaf Instance

Source: https://github.com/fahreddinozcan/doct/blob/master/_context7_rst_markdown_build/developer-guides/developing-apps-on-the-opendaylight-controller.md

Navigates to the Karaf assembly directory and starts the OpenDaylight controller. This step is performed after building the project and is necessary to run the application within the controller environment. It requires navigating to the 'bin' directory of the Karaf target assembly.

```shell
cd karaf/target/assembly/bin
./karaf
```

--------------------------------

### Install act using curl

Source: https://github.com/fahreddinozcan/doct/blob/master/LOCAL-TESTING-README.md

This snippet demonstrates how to download and install the latest release of 'act' for Linux AMD64 architecture using curl and move it to the local bin directory. It requires Docker to be installed.

```bash
curl -s https://api.github.com/repos/nektos/act/releases/latest | \
  grep "browser_download_url.*linux_amd64" | cut -d '"' -f 4 | \
  xargs curl -L -o act && chmod +x act && sudo mv act /usr/local/bin/
```

--------------------------------

### Pekko Module Shards Configuration Example (`module-shards.conf`)

Source: https://github.com/fahreddinozcan/doct/blob/master/_context7_rst_markdown_build/getting-started-guide/clustering.md

This configuration defines the distribution of modules and their shards across cluster members. It specifies module names, shard names, and the list of replica nodes responsible for each shard within a module.

```default
module-shards = [
    {
        name = "default"
        shards = [
            {
                name="default"
                replicas = [
                    "member-1",
                    "member-2",
                    "member-3"
                ]
            }
        ]
    },
    {
        name = "topology"
        shards = [
            {
                name="topology"
                replicas = [
                    "member-1",
                    "member-2",
                    "member-3"
                ]
            }
        ]
    },
    {
        name = "inventory"
        shards = [
            {
                name="inventory"
                replicas = [
                    "member-1",
                    "member-2",
                    "member-3"
                ]
            }
        ]
    },
    {
         name = "toaster"
         shards = [
             {
                 name="toaster"
                 replicas = [
                    "member-1",
                    "member-2",
                    "member-3"
                 ]
             }
         ]
    }
]
```

--------------------------------

### New File Copyright Header (Example)

Source: https://github.com/fahreddinozcan/doct/blob/master/_context7_rst_markdown_build/contributor-guides/copyright.md

This is an example of a standard copyright header for new files. It includes the date, copyright holder(s), and the licensing terms, ensuring compliance with the Eclipse Public License (EPL) or a compatible license. This header is crucial for downstream consumers to understand redistribution clauses.

```text
/**
 * Copyright (c) <Date> <Company or Individual> and others.  All rights reserved.
 *
 * This program and the accompanying materials are made available under the
 * terms of the Eclipse Public License v1.0 which accompanies this distribution,
 * and is available at http://www.eclipse.org/legal/epl-v10.html
 **/
```

--------------------------------

### Install and Configure lftools for OpenDaylight Releases

Source: https://github.com/fahreddinozcan/doct/blob/master/_context7_rst_markdown_build/release-process/simultaneous-release.md

This snippet demonstrates how to install and set up the 'lftools' Python package, which is essential for version bumping and tagging development branches during the OpenDaylight release process. It includes instructions for creating and activating a virtual environment.

```bash
# Skip mkvirtualenv if you already have an lftools virtualenv
mkvirtualenv lftools
workon lftools
pip install --upgrade lftools
```

--------------------------------

### Resolved Conflict Example (Text)

Source: https://github.com/fahreddinozcan/doct/blob/master/_context7_rst_markdown_build/contributor-guides/newcomers-guide.md

Demonstrates the appearance of a text file after manual conflict resolution, showing the merged content without the Git conflict markers.

```text
My Shopping list

Apples
Banana
Bread
Pancakes
Soda
Tomatoes
```

--------------------------------

### Install Neutron Logger Feature in Karaf

Source: https://github.com/fahreddinozcan/doct/blob/master/_context7_rst_markdown_build/user-guide/neutron-service-user-guide.md

Installs the 'odl-neutron-logger' Karaf feature, which is used for debugging and logging changes on Neutron YANG models. This helps in monitoring and troubleshooting the Neutron service.

```karaf
feature:install odl-neutron-logger
```

--------------------------------

### Karaf Feature XML Processing Example

Source: https://github.com/fahreddinozcan/doct/blob/master/_context7_rst_markdown_build/developer-guides/odl-parent-developer-guide.md

Illustrates how to define Karaf features, including repository dependencies, feature dependencies, and bundles, with version placeholders for dynamic replacement. This is commonly used in OpenDaylight projects for managing feature versions.

```xml
<features name="odl-mdsal-${project.version}" xmlns="http://karaf.apache.org/xmlns/features/v1.2.0"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://karaf.apache.org/xmlns/features/v1.2.0 http://karaf.apache.org/xmlns/features/v1.2.0">

    <repository>mvn:org.opendaylight.odlparent/features-odlparent/{{VERSION}}/xml/features</repository>

    [...]
    <feature name='odl-mdsal-broker-local' version='${project.version}' description="OpenDaylight :: MDSAL :: Broker">
        <feature version='${yangtools.version}'>odl-yangtools-common</feature>
        <feature version='${mdsal.version}'>odl-mdsal-binding-dom-adapter</feature>
        <feature version='${mdsal.model.version}'>odl-mdsal-models</feature>
        <feature version='${project.version}'>odl-mdsal-common</feature>
        <feature version='${config.version}'>odl-config-startup</feature>
        <feature version='${config.version}'>odl-config-netty</feature>
        <feature version='[3.3.0,4.0.0)'>odl-lmax</feature>
        [...]
        <bundle>mvn:org.opendaylight.controller/sal-dom-broker-config/{{VERSION}}</bundle>
        <bundle start-level="40">mvn:org.opendaylight.controller/blueprint/{{VERSION}}</bundle>
        <configfile finalname="${config.configfile.directory}/${config.mdsal.configfile}">mvn:org.opendaylight.controller/md-sal-config/{{VERSION}}/xml/config</configfile>
    </feature>
```

--------------------------------

### Grievance Report Description Example

Source: https://github.com/fahreddinozcan/doct/blob/master/_context7_rst_markdown_build/release-process/managed-release.md

This example shows the format for detailing a grievance report against an unresponsive project in Jira. It emphasizes including specific evidence such as situation description, Gerrit change IDs, and relevant email threads.

```text
Document the details that show ExampleProject was slow to review a change.
The report should include as much relevant information as possible,
including a description of the situation, relevant Gerrit change IDs and
relevant public email list threads.
```

--------------------------------

### Install Self-Managed Project Features using Karaf

Source: https://github.com/fahreddinozcan/doct/blob/master/_context7_rst_markdown_build/release-process/managed-release.md

This snippet demonstrates how to install features from Self-Managed OpenDaylight projects using the Karaf shell. It requires prior knowledge of the feature's Maven coordinates and the use of the `repo:add` command.

```shell
feature:repo-add mvn:org.opendaylight.netvirt/odl-netvirt-openstack/0.6.0-SNAPSHOT/xml/features
```

--------------------------------

### Add Replicas for All Shards

Source: https://github.com/fahreddinozcan/doct/blob/master/_context7_rst_markdown_build/getting-started-guide/clustering.md

Instructs a new node to replicate all shards from the cluster.

```APIDOC
## POST /restconf/operations/cluster-admin:add-replicas-for-all-shards

### Description
This RPC is sent to a new node joining the cluster to instruct it to replicate all existing shards. This allows for dynamic addition of nodes without configuration file changes or reboots of healthy nodes.

### Method
POST

### Endpoint
/restconf/operations/cluster-admin:add-replicas-for-all-shards

### Parameters
#### Query Parameters
None

#### Request Body
None

### Response
#### Success Response (200)
This endpoint typically returns an empty response body on success, or a confirmation message.

### Notes
- This RPC must be sent to the new node itself.
- While this API adds/removes shards dynamically, static configuration files (`module-shard.conf`, `modules.conf`) are still used for initial startup configuration. Dynamic changes are stored in the journal.
```

--------------------------------

### Install Dependent Projects (Maven - Quick Install) (Shell)

Source: https://github.com/fahreddinozcan/doct/blob/master/_context7_rst_markdown_build/release-notes/upgrade-process.md

Command to perform a quick clean install of dependent projects using Maven. The '-Pq' flag likely enables a quick profile, and 'clean install' builds the project.

```shell
mvn -Pq clean install
```

--------------------------------

### Install ODL Parent (Shell)

Source: https://github.com/fahreddinozcan/doct/blob/master/_context7_rst_markdown_build/developer-guides/integrating-animal-sniffer-plugin-with-projects.md

This command executes a clean install of the odlparent project after modifying its `pom.xml` to include the Animal Sniffer plugin configuration. This ensures the plugin is available for subsequent steps.

```shell
mvn clean install
```

--------------------------------

### Pekko Cluster Configuration Example (`pekko.conf`)

Source: https://github.com/fahreddinozcan/doct/blob/master/_context7_rst_markdown_build/getting-started-guide/clustering.md

This configuration defines settings for a Pekko cluster, including remote communication with Artery, seed node addresses, cluster roles, and persistence directory configurations. It specifies hostname, port, and other network-related parameters for cluster nodes.

```default
odl-cluster-data {
  pekko {
    remote {
      artery {
        enabled = on
        transport = tcp
        canonical.hostname = "10.0.2.10"
        canonical.port = 2550
      }
    }

    cluster {
      # Using artery.
      seed-nodes = ["pekko://opendaylight-cluster-data@10.0.2.10:2550",
                    "pekko://opendaylight-cluster-data@10.0.2.11:2550",
                    "pekko://opendaylight-cluster-data@10.0.2.12:2550"]

      roles = [
        "member-1"
      ]

      # when under load we might trip a false positive on the failure detector
      # failure-detector {
        # heartbeat-interval = 4 s
        # acceptable-heartbeat-pause = 16s
      # }
    }

    persistence {
      # By default the snapshots/journal directories live in KARAF_HOME. You can choose to put it somewhere else by
      # modifying the following two properties. The directory location specified may be a relative or absolute path.
      # The relative path is always relative to KARAF_HOME.

      # snapshot-store.local.dir = "target/snapshots"

      # Use lz4 compression for LocalSnapshotStore snapshots
      snapshot-store.local.use-lz4-compression = false
      # Size of blocks for lz4 compression: 64KB, 256KB, 1MB or 4MB
      snapshot-store.local.lz4-blocksize = 256KB
    }
    disable-default-actor-system-quarantined-event-handling = "false"
  }
}
```

--------------------------------

### Verify OpenDaylight Module and Log Entry

Source: https://github.com/fahreddinozcan/doct/blob/master/_context7_rst_markdown_build/developer-guides/developing-apps-on-the-opendaylight-controller.md

Checks if the 'example' module is built and running within the OpenDaylight controller by searching for a specific log entry. This command is executed within the Karaf CLI to verify the successful deployment and initialization of the application.

```shell
log:display | grep Example
```

--------------------------------

### Submit Multiple Changes for Review (Git-Review Example)

Source: https://github.com/fahreddinozcan/doct/blob/master/_context7_rst_markdown_build/contributor-guides/newcomers-guide.md

This example demonstrates submitting multiple interdependent changes for review. It involves cloning the repository, fetching a change, amending it, adding a new change, and then uploading all changes using git-review -T. The -y option can be used to bypass confirmation prompts.

```bash
$ git clone https://git.opendaylight.org/gerrit/docs
$ git-review -s
$ git-review -d 93386

// rework the change 93386
[..]
$ git add < path-of-reworked-file > [ … ]

// amend commit
$ git commit –amend

// add a new change/commit
$ git add < path-of-worked-file > [ … ]
// add a new commit
$ git commit

// repeat the operation as much time as necessary
[..]

// upload the changes to Gerrit
$ git-review -T
```

--------------------------------

### Configuration Files for Local Testing and Docs

Source: https://context7.com/fahreddinozcan/doct/llms.txt

Key configuration files used for local GitHub Actions execution, environment variables, Sphinx documentation setup, and tox test environments. Includes .actrc, .env.local, docs/conf.py, and tox.ini.

```bash
# .actrc - Act runner configuration for local GitHub Actions
-P ubuntu-latest=catthehacker/ubuntu:act-latest
--env-file .env.local
--artifact-server-path /tmp/artifacts

# .env.local - Local environment variables
ACT=true
CI=true

# docs/conf.py - Sphinx configuration
# - Extensions: sphinx.ext.autodoc, sphinx.ext.intersphinx
# - Theme: docs_conf theme (ReadTheDocs style)
# - Link checking: linkcheck_ignore patterns
# - Spelling: spelling_wordlist.txt

# tox.ini - Test environment configuration
[testenv:docs]
basepython = python3
deps = -rdocs/requirements.txt
commands = sphinx-build -W -b html -d {envtmpdir}/doctrees ./docs/ {toxinidir}/docs/_build/html

[testenv:docs-linkcheck]
commands = sphinx-build -b linkcheck ./docs/ {toxinidir}/docs/_build/linkcheck

# docs/requirements.txt - Python dependencies
# opendaylight-sphinx-theme
# sphinx
# sphinx-intersphinx

```

--------------------------------

### Install Pre-commit Hooks (Bash)

Source: https://context7.com/fahreddinozcan/doct/llms.txt

Installs pre-commit hooks for local development to automate code quality checks. These hooks run automatically on git commit and include checks for whitespace, YAML syntax, large files, and commit message format.

```bash
# Install all pre-commit hooks
cd /path/to/docs
tox -e pre-commit-install

# Installs hooks for:
# - trailing-whitespace removal
# - end-of-file-fixer
# - check-yaml syntax validation
# - check-added-large-files (prevents >500KB commits)
# - gitlint (commit message format)
#
# Hooks run automatically on: git commit
# Manual run: pre-commit run --all-files

# Example commit with hooks:
git add documentation.rst
git commit -m "Update developer guide"
# Output:
# Trim Trailing Whitespace.............................Passed
# Fix End of Files.....................................Passed
# Check Yaml..........................................Passed
# Check for added large files.........................Passed
# gitlint..............................................Passed
# [master abc1234] Update developer guide
```

--------------------------------

### Commit Message Format Example

Source: https://context7.com/fahreddinozcan/doct/llms.txt

Example of a valid commit message format, including a concise title, a blank line, a descriptive body, and Change-Id and Signed-off-by trailers.

```text
"""
Add local testing infrastructure for documentation

This commit introduces act-based local testing that enables
developers to validate documentation builds before submitting
to Gerrit, reducing CI feedback cycles.

Change-Id: I1234567890abcdef1234567890abcdef12345678
Signed-off-by: Developer Name <dev@example.com>"""
```

--------------------------------

### Karaf Workaround for Windows OS Identification

Source: https://github.com/fahreddinozcan/doct/blob/master/_context7_rst_markdown_build/getting-started-guide/installing_opendaylight.md

This snippet demonstrates the workaround to resolve Karaf's OS identification issue on Windows 10. By adding a specific property to the `system.properties` file, Karaf can correctly identify the operating system, enabling feature installation.

```properties
org.osgi.framework.os.name = Win32
```

--------------------------------

### Read Config Datastore Shard Manager Info via Jolokia REST API

Source: https://github.com/fahreddinozcan/doct/blob/master/_context7_rst_markdown_build/getting-started-guide/clustering.md

Fetches information about the shard manager for the configuration datastore. This REST call targets a specific MBean to get an overview of the shards local to the queried OpenDaylight instance. The output includes shard names, synchronization status, and the member name.

```bash
GET  /jolokia/read/org.opendaylight.controller:type=DistributedConfigDatastore,Category=ShardManager,name=shard-manager-config
```

--------------------------------

### Documentation Directory Structure and Cross-linking

Source: https://context7.com/fahreddinozcan/doct/llms.txt

The organizational structure of the project's documentation directory and an example of how to cross-link between different documentation pages using reStructuredText's toctree directive.

```bash
docs/
├── index.rst                           # Main landing page
├── documentation.rst                   # Documentation contributor guide
├── downloads.rst                       # Release downloads
├── javadoc.rst                        # Java API documentation
├── getting-started-guide/             # End-user installation guides
│   └── index.rst
├── developer-guides/                  # Development tutorials
│   ├── index.rst
│   └── coding-guidelines.rst
├── contributor-guides/                # Contribution process
│   ├── index.rst
│   └── submitting-patches.rst
├── user-guide/                        # Feature usage guides
│   └── index.rst
├── release-notes/                     # Version release notes
│   ├── index.rst
│   ├── upgrade-process.rst
│   └── projects/                      # Per-project notes
└── release-process/                   # Release management
    └── index.rst

# Cross-linking example (from index.rst):
.. toctree::
   :maxdepth: 1

   downloads
   release-notes/index
   getting-started-guide/index
   developer-guides/index

```

--------------------------------

### Karaf Feature Installation Error on Windows 10

Source: https://github.com/fahreddinozcan/doct/blob/master/_context7_rst_markdown_build/getting-started-guide/installing_opendaylight.md

This code block shows the error message encountered when attempting to install Karaf features on Windows 10. The error indicates a failure to resolve native code for the 'leveldbjni' bundle, specifically for Windows 32-bit and 64-bit processors.

```text
opendaylight-user@root>feature:install odl-restconf
Error executing command: Can't install feature odl-restconf/0.0.0:
Could not start bundle mvn:org.fusesource.leveldbjni/leveldbjni-all/1.8-odl in feature(s) odl-akka-leveldb-0.7: The bundle "org.fusesource.leveldbjni.leveldbjni-all_1.8.0 [300]" could not be resolved. Reason: No match found for native code: META-INF/native/windows32/leveldbjni.dll; processor=x86; osname=Win32, META-INF/native/windows64/leveldbjni.dll; processor=x86-64; osname=Win32, META-INF/native/osx/libleveldbjni.jnilib; processor=x86; osname=macosx, META-INF/native/osx/libleveldbjni.jnilib; processor=x86-64; osname=macosx, META-INF/native/linux32/libleveldbjni.so; processor=x86; osname=Linux, META-INF/native/linux64/libleveldbjni.so; processor=x86-64; osname=Linux, META-INF/native/sunos64/amd64/libleveldbjni.so; processor=x86-64; osname=SunOS, META-INF/native/sunos64/sparcv9/libleveldbjni.so; processor=sparcv9; osname=SunOS
```

--------------------------------

### Gerrit URL Parsing Examples (Bash)

Source: https://context7.com/fahreddinozcan/doct/llms.txt

Demonstrates how the 'test-gerrit-local.sh' script automatically parses change metadata from Gerrit URLs. It supports two common URL formats for extracting change information.

```bash
# The test script supports multiple URL formats:
# Format 1: https://git.opendaylight.org/gerrit/c/docs/+/117503
# Format 2: https://git.opendaylight.org/gerrit/c/docs/+/117503/2
```

--------------------------------

### OpenDayLight Documentation Directory Structure

Source: https://github.com/fahreddinozcan/doct/blob/master/_context7_rst_markdown_build/documentation.md

Illustrates the typical file organization for OpenDaylight documentation, showing the relationship between the main entry point, guides, and individual chapters.

```default
docs/index.rst                 -> entry point
docs/____-guide/index.rst      -> part
docs/____-guide/<chapter>.rst  -> chapter
```

--------------------------------

### List All MBeans

Source: https://github.com/fahreddinozcan/doct/blob/master/_context7_rst_markdown_build/getting-started-guide/clustering.md

Retrieves a schema of all available MBeans, but not their content.

```APIDOC
## GET /jolokia/list

### Description
Retrieves a schema of all available MBeans exposed by OpenDaylight via Jolokia. This endpoint lists MBean names but does not return their specific values.

### Method
GET

### Endpoint
/jolokia/list

### Parameters
No parameters are required for this request.

### Request Example
GET /jolokia/list

### Response
#### Success Response (200)
- **response** (object) - A JSON object containing the schema of available MBeans.

#### Response Example
```json
{
  "request": {
    "type": "list"
  },
  "value": {
    "org": {
      "opendaylight": {
        "controller": {
          "type": {
            "DistributedConfigDatastore": {
              "Category": {
                "ShardManager": {
                  "name": {
                    "shard-manager-config": {
                      "type": "read"
                    }
                  }
                }
              }
            },
            "DistributedOperationalDatastore": {
              "Category": {
                "ShardManager": {
                  "name": {
                    "shard-manager-operational": {
                      "type": "read"
                    }
                  }
                }
              }
            }
          }
        }
      }
    }
  },
  "timestamp": 1483738000,
  "status": 200
}
```
```

--------------------------------

### Karaf System Properties File Location

Source: https://github.com/fahreddinozcan/doct/blob/master/_context7_rst_markdown_build/getting-started-guide/installing_opendaylight.md

This entry specifies the location of the configuration file that needs to be modified as part of the Karaf workaround for Windows OS identification. This file contains system properties for the Karaf environment.

```filepath
etc/system.properties
```

--------------------------------

### Read Config Datastore Shard Manager Info

Source: https://github.com/fahreddinozcan/doct/blob/master/_context7_rst_markdown_build/getting-started-guide/clustering.md

Reads information about shards local to the queried OpenDaylight instance for the configuration datastore.

```APIDOC
## GET /jolokia/read/org.opendaylight.controller:type=DistributedConfigDatastore,Category=ShardManager,name=shard-manager-config

### Description
Retrieves details about the shard manager for the distributed configuration datastore. This endpoint provides information on local shards, synchronization status, and member name.

### Method
GET

### Endpoint
/jolokia/read/org.opendaylight.controller:type=DistributedConfigDatastore,Category=ShardManager,name=shard-manager-config

### Parameters
No parameters are required for this request.

### Request Example
GET /jolokia/read/org.opendaylight.controller:type=DistributedConfigDatastore,Category=ShardManager,name=shard-manager-config

### Response
#### Success Response (200)
- **request** (object) - Details of the JMX read request.
- **value** (object) - Information about the shards, including `LocalShards`, `SyncStatus`, and `MemberName`.
- **timestamp** (integer) - The timestamp of the response.
- **status** (integer) - The HTTP status code (200 for success).

#### Response Example
```json
{
  "request": {
    "mbean": "org.opendaylight.controller:Category=ShardManager,name=shard-manager-config,type=DistributedConfigDatastore",
    "type": "read"
  },
  "value": {
    "LocalShards": [
      "member-1-shard-default-config",
      "member-1-shard-entity-ownership-config",
      "member-1-shard-topology-config",
      "member-1-shard-inventory-config",
      "member-1-shard-toaster-config"
    ],
    "SyncStatus": true,
    "MemberName": "member-1"
  },
  "timestamp": 1483738005,
  "status": 200
}
```
```

--------------------------------

### Restarting Distributed Datastore Bundle (Karaf Console)

Source: https://github.com/fahreddinozcan/doct/blob/master/_context7_rst_markdown_build/getting-started-guide/clustering.md

This Karaf command restarts the `org.opendaylight.controller.sal-distributed-datastore` bundle. This is typically done after applying configuration changes to ensure they take effect.

```karaf
opendaylight-user@root>restart org.opendaylight.controller.sal-distributed-datastore
```

--------------------------------

### Cherry-Pick and Back-port Git Changes

Source: https://github.com/fahreddinozcan/doct/blob/master/_context7_rst_markdown_build/contributor-guides/newcomers-guide.md

Demonstrates cloning a specific branch and then cherry-picking a change into it. It also shows how to upload the cherry-picked change back to Gerrit, potentially to a different branch.

```shell
$ git clone -b stable/aluminium ssh://< login >@git.opendaylight.org:29418/docs
$ git-review -x 94257
//Change 94257 is on the magnesium branch and not the aluminium branch
$ git-review [–P] [stable/aluminium]
```

--------------------------------

### Generate OpenDaylight Project with Maven Archetype

Source: https://github.com/fahreddinozcan/doct/blob/master/_context7_rst_markdown_build/developer-guides/developing-apps-on-the-opendaylight-controller.md

Creates a new OpenDaylight project using the 'opendaylight-startup-archetype'. This command initiates the project scaffolding and requires specifying the archetype version. It's a crucial step for starting a new OpenDaylight application module.

```shell
mvn archetype:generate -DarchetypeGroupId=org.opendaylight.archetypes \
    -DarchetypeArtifactId=opendaylight-startup-archetype \
    -DarchetypeCatalog=remote -DarchetypeVersion=<VERSION>
```

--------------------------------

### Read Operational Datastore Shard Manager Info

Source: https://github.com/fahreddinozcan/doct/blob/master/_context7_rst_markdown_build/getting-started-guide/clustering.md

Reads information about shards local to the queried OpenDaylight instance for the operational datastore.

```APIDOC
## GET /jolokia/read/org.opendaylight.controller:type=DistributedOperationalDatastore,Category=ShardManager,name=shard-manager-operational

### Description
Retrieves details about the shard manager for the distributed operational datastore. This endpoint provides information on local shards, synchronization status, and member name.

### Method
GET

### Endpoint
/jolokia/read/org.opendaylight.controller:type=DistributedOperationalDatastore,Category=ShardManager,name=shard-manager-operational

### Parameters
No parameters are required for this request.

### Request Example
GET /jolokia/read/org.opendaylight.controller:type=DistributedOperationalDatastore,Category=ShardManager,name=shard-manager-operational

### Response
#### Success Response (200)
- **request** (object) - Details of the JMX read request.
- **value** (object) - Information about the shards, including `LocalShards`, `SyncStatus`, and `MemberName`.
- **timestamp** (integer) - The timestamp of the response.
- **status** (integer) - The HTTP status code (200 for success).

#### Response Example
```json
{
  "request": {
    "mbean": "org.opendaylight.controller:Category=ShardManager,name=shard-manager-operational,type=DistributedOperationalDatastore",
    "type": "read"
  },
  "value": {
    "LocalShards": [
      "member-1-shard-default-operational",
      "member-1-shard-entity-ownership-operational",
      "member-1-shard-topology-operational",
      "member-1-shard-inventory-operational",
      "member-1-shard-toaster-operational"
    ],
    "SyncStatus": true,
    "MemberName": "member-1"
  },
  "timestamp": 1483738005,
  "status": 200
}
```
```

--------------------------------

### Minimal setup.py for tox Workaround

Source: https://github.com/fahreddinozcan/doct/blob/master/_context7_rst_markdown_build/contributor-guides/coding-guidelines/coding-guidelines-python.md

This minimal `setup.py` file serves as a workaround for older versions of `tox` that do not support the `skipsdist=true` parameter. This is useful for projects that do not have an existing `setup.py` and are being built with a Jenkins infra `tox` version prior to 1.6.0.

```Python
# Workaround for tox missing parameter 'skipsdist=true' which was not
# introduced until tox 1.6.0

import setuptools

setuptools.setup(name='project-name')

```

--------------------------------

### Gitlint Commit Message Validation with Tox

Source: https://context7.com/fahreddinozcan/doct/llms.txt

Instructions and configuration for using Gitlint via Tox to enforce commit message standards. Includes the Tox command to run Gitlint and an example of a Gitlint configuration file.

```bash
# Run gitlint on last commit
tox -e gitlint

# Configuration in .gitlint:
# [general]
# ignore=body-is-missing
#

```

--------------------------------

### Stage Files for Commit (Shell)

Source: https://github.com/fahreddinozcan/doct/blob/master/_context7_rst_markdown_build/contributor-guides/newcomers-guide.md

This command adds specified files or a range of files to the Git staging area, preparing them to be included in the next commit.

```shell
$ git add [ … ]
```

--------------------------------

### Guice Object Binding Wiring with Java

Source: https://github.com/fahreddinozcan/doct/blob/master/_context7_rst_markdown_build/developer-guides/tests/component.md

Demonstrates how to write Guice object binding wiring classes in Java. This example shows binding a service interface to its implementation and binding another service.

```java
public class AclServiceModule extends AbstractGuiceJsr250Module {
    @Override
    protected void configureBindings() {
        bind(AclServiceManager.class).to(AclServiceManagerImpl.class);
        bind(AclInterfaceStateListener.class);
    }
    ...
```

--------------------------------

### Access odl-odlparent-version via RESTCONF

Source: https://github.com/fahreddinozcan/doct/blob/master/_context7_rst_markdown_build/user-guide/distribution-version-user-guide.md

Example curl command to access the odl-odlparent-version configuration module through the RESTCONF interface. This assumes a single node deployment and that the user is on the same system as OpenDaylight.

```bash
curl 127.0.0.1:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/controller-config/yang-ext:mount/config:modules/module/odl-distribution-version:odl-version/odl-odlparent-version
```

--------------------------------

### Shell Commands for Building and Running Project

Source: https://github.com/fahreddinozcan/doct/blob/master/_context7_rst_markdown_build/developer-guides/developing-apps-on-the-opendaylight-controller.md

This section provides shell commands for navigating directories, cleaning and installing the project using Maven, and running the Karaf server. These commands are essential for building the Java RPC implementation, packaging it, and deploying it within the OpenDaylight environment.

```shell
cd ../impl/src/main/java/org/opendaylight/hello/impl/
cd ../../../../../resources/OSGI-INF/blueprint/
cd ../../../../../
mvn clean install
cd ../
mvn clean install
cd karaf/target/assembly/bin
./karaf
log:display | grep Hello
```

--------------------------------

### Add Replicas for All Shards RPC

Source: https://github.com/fahreddinozcan/doct/blob/master/_context7_rst_markdown_build/getting-started-guide/clustering.md

RPC to add new replicas for all shards to a specified node. This operation does not require any input parameters and should be invoked on the new node itself, instructing it to join the cluster and replicate existing shards.

```default
POST  /restconf/operations/cluster-admin:add-replicas-for-all-shards

or

POST  /rests/operations/cluster-admin:add-replicas-for-all-shards
```

--------------------------------

### Enable/Disable Datastore Persistence Script

Source: https://github.com/fahreddinozcan/doct/blob/master/_context7_rst_markdown_build/getting-started-guide/persistence_and_backup.md

This bash script allows users to enable or disable the configuration datastore persistence. Changes require a node restart to take effect. It can be used at any time, including before the controller starts for the first time.

```bash
bin/set_persistence.sh <on/off>

# Example:
bin/set_persistence.sh off
```

--------------------------------

### Fetch and Checkout Change for Reworking (Git)

Source: https://github.com/fahreddinozcan/doct/blob/master/_context7_rst_markdown_build/contributor-guides/newcomers-guide.md

Fetches a specific change from Gerrit and checks it out locally. This is the first step to rework an existing change. It uses git fetch with a specific ref and then git checkout.

```bash
// fetch and checkout the change
// (checkout command can be copied from change screen, right top corner in download)
$ git fetch "https://git.opendaylight.org/gerrit/docs" refs/changes/86/93386/2
  && git checkout FETCH_HEAD
```

--------------------------------

### Build HTML Documentation with Tox

Source: https://context7.com/fahreddinozcan/doct/llms.txt

Builds HTML documentation using Sphinx and tox. Navigate to the 'docs/' directory and run 'tox -e docs'. The output HTML files will be generated in 'docs/_build/html/', including 'index.html'.

```bash
cd docs/
tox -e docs

# Output: HTML files generated in docs/_build/html/
# - index.html (main page)
# - developer-guides/index.html
# - user-guide/index.html
# - release-notes/index.html
# Opens in browser: file:///path/to/docs/_build/html/index.html
```

--------------------------------

### Upload Changes for Review to Specific Branch (Shell)

Source: https://github.com/fahreddinozcan/doct/blob/master/_context7_rst_markdown_build/contributor-guides/newcomers-guide.md

This command uses git-review to upload the current commit for review targeting a specific branch, indicated by '<branch_name>'. For example, 'stable/magnesium'.

```shell
$ git-review -T <branch_name>
```

```shell
$ git-review -T stable/magnesium
```

--------------------------------

### Local Development Workflow - Testing and Committing

Source: https://context7.com/fahreddinozcan/doct/llms.txt

Commands for testing documentation locally, running pre-commit checks, and creating a commit with a proper message format.

```bash
# 3. Test locally before commit
bash test-gerrit-local.sh --local-changes
# Output: ✅ docs: commands succeeded
#         ✅ docs-linkcheck: commands succeeded

# 4. Run pre-commit checks
tox -e pre-commit
# Output: All checks passed

# 5. Commit with proper message
git add docs/developer-guides/coding-guidelines.rst
git commit -m "Update coding guidelines with modern practices

Add sections on async/await patterns and error handling
best practices for OpenDaylight development.

Change-Id: I$(openssl rand -hex 20)
Signed-off-by: Your Name <you@example.com>"
```

--------------------------------

### Custom Sphinx Extension for JIRA Linking

Source: https://context7.com/fahreddinozcan/doct/llms.txt

Python code for a custom Sphinx role 'jira' that creates links to OpenDaylight JIRA issues. It includes the role implementation and the setup function to register the role and add CSS.

```python
# In docs/conf.py:
sys.path.append(os.path.abspath('ext'))
extensions.append('odl-jira')

# docs/ext/odl-jira.py - JIRA issue linking:
"""
Usage in RST files:
:jira:`ODL-12345` - Links to OpenDaylight JIRA issue

Generates:
<a href="https://jira.opendaylight.org/browse/ODL-12345">ODL-12345</a>
"""

# Implementation example:
def jira_role(name, rawtext, text, lineno, inliner, options={}, content=[]):
    """Create a link to a JIRA issue."""
    issue_id = text
    url = f'https://lf-opendaylight.atlassian.net/browse/{issue_id}'
    node = nodes.reference(rawtext, issue_id, refuri=url, **options)
    return [node], []

def setup(app):
    app.add_role('jira', jira_role)
    app.add_css_file("css/ribbon.css")

```

--------------------------------

### Sphinx Build Command for Verbose Output

Source: https://context7.com/fahreddinozcan/doct/llms.txt

Command to build documentation locally using Sphinx with verbose output and warning flags enabled. Useful for debugging build issues and identifying warnings.

```bash
# Verbose build output with warnings
cd docs/
sphinx-build -v -W --keep-going -b html -d _build/doctrees . _build/html
```

--------------------------------

### Git Merge Conflict Example (Text)

Source: https://github.com/fahreddinozcan/doct/blob/master/_context7_rst_markdown_build/contributor-guides/newcomers-guide.md

Illustrates how Git indicates a merge conflict in a text file. It shows the markers used to delimit conflicting sections and the expected appearance of the file before manual resolution.

```text
My Shopping list

Apples
<<<<<<< HEAD
Bread
Pancakes
=======
Banana
Soda
>>>>>>> issue3
Tomatoes
```

--------------------------------

### Local Development Workflow - Branching and Editing

Source: https://context7.com/fahreddinozcan/doct/llms.txt

Steps to create a new feature branch and edit documentation files using Git and Vim.

```bash
# 1. Create feature branch
git checkout -b update-developer-guide

# 2. Edit documentation
vim docs/developer-guides/coding-guidelines.rst
```

--------------------------------

### Enable Split Brain Resolver in Pekko Cluster Configuration

Source: https://github.com/fahreddinozcan/doct/blob/master/_context7_rst_markdown_build/getting-started-guide/clustering.md

This configuration snippet shows how to enable the Split Brain Resolver by setting the `pekko.cluster.downing-provider-class` in the Pekko configuration. This is a required step to activate the split-brain resolution mechanism.

```HOCON
pekko.cluster.downing-provider-class = "org.apache.pekko.cluster.sbr.SplitBrainResolverProvider"
```

--------------------------------

### Skip Deploy and Install for Non-Artifact Modules (Maven)

Source: https://github.com/fahreddinozcan/doct/blob/master/_context7_rst_markdown_build/developer-guides/odl-parent-developer-guide.md

This configuration snippet for Maven's `pom.xml` is used for modules that do not produce artifacts, such as aggregator POMs. It ensures that the `maven-deploy-plugin` and `maven-install-plugin` are skipped, preventing unnecessary processing of non-existent artifacts.

```xml
<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-deploy-plugin</artifactId>
            <configuration>
                <skip>true</skip>
            </configuration>
        </plugin>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-install-plugin</artifactId>
            <configuration>
                <skip>true</skip>
            </configuration>
        </plugin>
    </plugins>
</build>
```

--------------------------------

### Compile Project and Filter Warnings (Shell)

Source: https://github.com/fahreddinozcan/doct/blob/master/_context7_rst_markdown_build/contributor-guides/newcomers-guide.md

This command compiles the project, skipping tests, and logs the output. It then filters the log file for lines containing 'WARN' or 'ERROR', useful for identifying compilation issues.

```shell
$ time mvn clean install -DskipTests 2>&1 |tee mvn.log.0 |grep ‘WARN|ERROR’
```

--------------------------------

### Local Development Workflow - Submission and Review

Source: https://context7.com/fahreddinozcan/doct/llms.txt

Steps to submit changes to Gerrit for review and monitor CI results.

```bash
# 6. Submit to Gerrit for review
git review

# 7. Monitor CI results
# Gerrit UI: https://git.opendaylight.org/gerrit/c/docs/+/<change-number>
# GitHub Actions: Automatic verification runs
# Result: Verified+1 (passed) or Verified-1 (failed)

# 8. Address review feedback (if needed)
vim docs/developer-guides/coding-guidelines.rst
git add -u
git commit --amend
git review
```