luxolus/open-nomad
2
0
Fork 0
Code Issues 1 Pull requests Packages Releases Wiki Activity
open-nomad/contributing
History
Seth Hoenig d5ad580d5c structs: fix compatibility between api and nomad/structs proxy definitions 
The field names within the structs representing the Connect proxy
definition were not the same (nomad/structs/ vs api/), causing the
values to be lost in translation for the 'nomad job inspect' command.

Since the field names already shipped in v0.11.0 we cannot simply
fix the names. Instead, use the json struct tag on the structs/ structs
to remap the name to match the publicly expose api/ package on json
encoding.

This means existing jobs from v0.11.0 will continue to work, and
the JSON API for job submission will remain backwards compatible.
2020-04-13 15:59:45 -06:00
..
checklist-command.md docs contributing: checklist-command 2020-03-23 13:58:29 -04:00
checklist-jobspec.md structs: fix compatibility between api and nomad/structs proxy definitions 2020-04-13 15:59:45 -06:00
checklist-rpc-endpoint.md CSI: Scheduler knows about CSI constraints and availability (#6995) 2020-03-23 13:58:29 -04:00
golang.md
README.md

README.md

Nomad Codebase Documentation

This directory contains some documentation about the Nomad codebase, aimed at readers who are interested in making code contributions.

If you're looking for information on using Nomad, please instead refer to the Nomad website.

Architecture

The code for Nomad's major components is organized as:

  • api/ provides a Go client for Nomad's HTTP API.
  • client/ contains Nomad's client agent code.
  • command/ contains Nomad's CLI code.
  • nomad/ contains Nomad's server agent code.
  • ui/ contains Nomad's UI code.
  • website/ contains Nomad's website and documentation.

The high level control flow for many Nomad actions (via the CLI or UI) are:

# Read actions:
Client -> HTTP API -> RPC -> StateStore

# Actions that change state:
Client -> HTTP API -> RPC -> Raft -> FSM -> StateStore

Checklists

When adding new features to Nomad there are often many places to make changes. It is difficult to determine where changes must be made and easy to make mistakes.

The following checklists are meant to be copied and pasted into PRs to give developers and reviewers confidence that the proper changes have been made:

Tooling