kubernetes-sigs/kustomize
1
0
Fork 0
mirror of https://github.com/kubernetes-sigs/kustomize.git synced 2026-06-13 01:50:55 +00:00
Code Issues Packages Projects Releases 1 Wiki Activity

More release note tweaks.

Browse Source
This commit is contained in:
Jeffrey Regan
2019-06-18 13:33:20 -07:00
parent 2cb9f81bab
commit f17698a8ea
1 changed files with 67 additions and 62 deletions
Download Patch File Download Diff File Expand all files Collapse all files

89
docs/v_2.1.0.md
View File

@@ -150,28 +150,27 @@ For more information see the
## Field changes / deprecations ## Field changes / deprecations
* Generalized `resources` field. ### `resources` expanded, `bases` deprecated
The `resources` field has been generalized; it The `resources` field has been generalized; it now
now accepts what formerly could only be accepts what formerly could only be specified in
specified in the `bases` field. the `bases` field.
This change was made so that the `resources`, This change was made to allow users fine control
`generators` and `transformers` fields all over resource processing order. With a distinct
accept the same argument format. `bases` field, bases had to be loaded separately
from resources as a group. Now, base loading may
be interleaved as desired with the loading of
resource files from the current
directory. [Resource ordering](#resource-ordering)
had to be respected before this feature could be
introduced.
> Each field's argument is a _string list_, The `bases` field is now deprecated, and will be
> where each entry is either a _resource_ (a deleted in some future major release. Manage the
> relative path to a YAML file) or a deprecation simply moving the arguments of the
> [_kustomization_] (a relative path or URL `bases` field to the `resources` field in the
> pointing to a directory with a kustomization desired order, e.g.
> file). A kustomization directory used in this
> context is called a [_base_].
The `bases` field still works, but is
deprecated. Deal with this by simply moving the
arguments of the `bases` field to the
`resources` field in the desired order, e.g.
> ``` > ```
> resources: > resources:
@@ -190,31 +189,38 @@ For more information see the
> - someOtherResourceFile.yaml > - someOtherResourceFile.yaml
> ``` > ```
The depth-first traversal order of items in the The `kustomized edit fix` command will do this for
`resources:` field is respected by you, though it will always put the bases at the
kustomize, allowing one to, say, process end.
`someBaseDir` between the two resource files.
See this discussion of
[the `build --reorder` flag](#resource-ordering).
The _base_ as a concept is as important as ever, As an aside, the `resources`, `generators` and
it's just that two new fields (`generators` and `transformers` fields now all accept the same
`tranformers`) and one existing field argument format.
(`resources`) now accept arguments that were
once accepted only by `bases`.
The fact that the `generators` and > Each field's argument is a _string list_,
`transformers` field accept [bases] > where each entry is either a _resource_ (a
(i.e. kustomization directories) and the fact > relative path to a YAML file) or a
that generator and transformer configuration > [_kustomization_] (a path or URL
objects are normal k8s resources means that one > pointing to a directory with a kustomization
can generate or transform a generator or a > file). A kustomization directory used in this
transformer (see [TestTransformerTransformers]). > context is called a [_base_].
The fact that the `generators` and `transformers`
field accept [bases] and the fact that generator
and transformer configuration objects are just
normal k8s resources means that one can generate
or transform a generator or a transformer (see
[TestTransformerTransformers]).
[TestTransformerTransformers]: ../pkg/target/transformerplugin_test.go [TestTransformerTransformers]: ../pkg/target/transformerplugin_test.go
* Consistent `envs` field for Secret and ### `replicas` field
ConfigMap generators.
The common task of patching a deployment to edit
the number of replicas is now made easier
with the new [replicas](fields.md#replicas) field.
### `envs` field
An `envs` sub-field has been added to both An `envs` sub-field has been added to both
`configMapGenerator` and `secretGenerator`, `configMapGenerator` and `secretGenerator`,
@@ -222,6 +228,5 @@ For more information see the
`env` field. The new field accepts lists, just `env` field. The new field accepts lists, just
like its sibling fields `files` and `literals`. like its sibling fields `files` and `literals`.
Optionally `kustomize edit fix` to edit your Optionally use `kustomize edit fix` to merge
kustomization file (e.g. merge singular `env` singular `env` field into a plural field.
field into a plural field).