* 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.
Profiles now have GenericId which can be used to render a "generic" go template file (neither ignition nor cloud-init) using group metadata and selectors. The storage interface and it's implementations use GetGeneric to retrieve this template.
Partially addresses #224
* gRPC API server requires a CA certificate to verify
and authenticate clients (passed via -ca-file)
* gRPC clients must authenticate with a client certificate
and key (passed via -cert-file and -key-file)
* A CA certificate (e.g. ca.crt) should be used to sign a server
certificate (server.crt for a private key server.key)
* gRPC API server requires a server certificate and key to be enabled
(passed via -cert-file and -key-file)
* gRPC client bootcmd tool must verify the server identity using a
known CA (passed to bootcmd via -ca-file)
* This provides transport security, it does not provide client
authentication
* 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
* All Groups retrieved from FileStore's GroupGet (via ParseGroup)
should have normalized selectors since end-users may write Group
definitions with MAC addresses which don't match Go's format
* Split config.yaml files into JSON groups files
* Update examples to use folders of mountable groups files
* Stop reading groups from a -config config.yaml file
* Add RichGroup JSON <-> Protobuf Serialize Group
* Defining protobuf messages with protobuf rpc services resulted
in generated code which depended upon the gRPC package. This meant
the core server lib depended on gPRC and thus, so did the HTTP
server.
* Move rpc service protobuf definitions under bootcfg/rpc, so the
bootcfg/server package no longer depends on grpc.
* Simplify server lib responses so HTTP server components don't
have to unwrap protobuf Response types intended for gRPC uses
* Wrap server lib responses in protobuf Response types in the
rpc package
