* Serve /metadata including group metadata, selectors, and
query variables in KEY=value "env file" format lines
* Recurse into nested maps (e.g. OUTER_INNER=val)
* Add query parameters to template variables, referenced by
{{.request.query.param}}
* Render Ignition/Fuze, cloud-config, and generic templates and
metadata with collected variables
* Replace template variable {{.query}} with {{.request.raw_query}}
(breaking)
* Simplify common http request handling chains
* Separate github.com/dghubble/ctxh source so we can move
it to a separate CoreOS package or vendor upstream
* Remove unused requireGET
* When raw Ignition (.ign/.ignition) content is provided, Parse
the contents with ignition, but return the contents as JSON
regardless of the result to respect user pass-through expectations
* Warn on parse errors which can occur if a newer Ignition format
is used than the version of Ignition that bootcfg was compiled
with
* By default, templates for Ignition are rendered and
parsed as github.com/coreos/fuze YAML configs, which
formalize the transform from YAML to Ignition JSON
* Ignition files (.ign/.ignition) should be validated and
served directly, without template rendering
* Remove support for Ignition v1
* This change is breaking! Users need to tweak any YAML
Ignition templates to the very similar Fuze YAML format
* Revert NetBoot id in storage.proto for compatibility
* Add URL.RawQuery to data for generic templates
* Add generic directory to scripts/setup-data-dir
* Add documentation for generic templates.
* Rendering an Ignition config or cloud-config template
with machine group metadata will error and log if a metadata
value is missing.
* Previously, the default missing value was "no value"
* Stop showing version hash at / path. If bootcfg were deployed
at a public endpoint, the version could be used by attackers to
find out-of-date deployments.
* Allow Ignition 2.0.0 JSON documents to be served
* Stop requiring Ignition templates to use file extensions to
specify their rendered format for parsing
* Setting k8s_version via metadata gives the impression
it can be bumped and the cluster will operate with the
desired version. In reality, the k8s profiles change in
minor but important ways which we validate between k8s
releases. It should be part of the k8s profile Ignition.
* bootcfg/version package provides the linker's GIT SHA based
version to bootcfg components
* Display the bootcfg version via the HTTP server / path for
convenience and for validating a deployed version easily
* Log requests to the / rooted subtree paths to surface machines
which are making requests containing typos and mistakes that do
not match HTTP API endpoints
* Ignition and Cloud config templates can reference selector
key/value pairs by lowercase key name
* Metadata endpoint will provide metadata and selector key/val
pairs for the matching machine group
