IOPS have been modelled as a resource since Nomad 0.1 but has never
actually been detected and there is no plan in the short term to add
detection. This is because IOPS is a bit simplistic of a unit to define
the performance requirements from the underlying storage system. In its
current state it adds unnecessary confusion and can be removed without
impacting any users. This PR leaves IOPS defined at the jobspec parsing
level and in the api/ resources since these are the two public uses of
the field. These should be considered deprecated and only exist to allow
users to stop using them during the Nomad 0.9.x release. In the future,
there should be no expectation that the field will exist.
* add vault integration guide in guides section and move current vault integration content to docs section
* complete guide with image
* fix typos
* rename step 6 and fix typos
* fix typos and awkward phrasing along with links
* fix duplicated step #
* fix typo
* fix links so that pages that pointed to the original vault integration content still point there
Give demo agents unique names to improve `nomad node status` output.
Since the agents default to the hostname, they all had the same name
whether using the root or demo Vagrantfiles.
* Add new commands for 0.6
* update version in documnetation for 0.6
* more information in example.nomad
* 0.6 additional information for viewing status of a job
* 0.6 status for alloc-status
* changes with 0.6 in modifying a job
* status is healthy when consul is running
* make new date consistent in
* add Latest Deployment and Deployed sections to output
* small changes in status values so that things the user should see as thesame, are the same in the example (e.g. Node ID should be the same in all places we list it in the example)
* further information in job status added in 0.6
* update output when changing redis version
* make new date consistent in
* add Latest Deployment and Deployed sections to output
* small changes in status values so that things the user should see as thesame, are the same in the example (e.g. Node ID should be the same in all places we list it in the example)
* Add new commands for 0.6
* update version in documnetation for 0.6
* more information in example.nomad
* 0.6 additional information for viewing status of a job
* 0.6 status for alloc-status
* changes with 0.6 in modifying a job
* status is healthy when consul is running
* further information in job status added in 0.6
* evaluation status for deployment in 0.6
* updating client demo config to match website
* update output of status for cluster
* update output when changing redis version
* update terminal output of adding more redis instances.
* small update so id numbers are consistent in example
* update ouput for , also stitch up ids from previous lines to match
* add to output when starting server and clients
* add to output
* remove text showing large parts of example.nomad file
* Small fixes to stopping and updating a job
I apologize in advance for the rather long PR, but unfortunately there
is not an easy way to break this up into smaller chunks. This separates
the agent configuration into smaller, more consumable pieces just like
the job specification.