Since CPU resources are usually a soft limit it is desirable to allow
setting it as low as possible to allow tasks to run only in "idle" time.
Setting it to 0 is still not allowed to avoid potential unintentional
side effects with allowing a zero value. While there may not be any side
effects this commit attempts to minimize risk by avoiding the issue.
This does *not* change the defaults.
Embed pointer conversion functions in the API package to avoid
unnecessary package dependency. `helper` package imports more
dependencies relevant for internal use (e.g. `hcl`).
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.
In the commit 622d3ddb92
"Fixed test and moved constants into standalone func" the minimum CPU
resource value for a job was increased from 100 to 20.
This can break the nomad setup for people that used lower CPU
values and are at the maximum MHz value of the available CPU on a
machine.
Change the minimum back to 20 MHz to ensure downwards compatibility.
In #3520, work was done to true up the defaults for Nomad resource
stanzas with the documentation. This fixes the tests that I
accidentally broke in the process. Some questions were raised about
using dynamic elements as part of expects, which is why I opted to
copy the MinResources pattern. During this refactor I also noticed
that structs.go had a similar issue and an inconsistent minium for CPU.
