fetch: Add support for providing HTTP headers #889
Conversation
Depends: coreos/ignition#889 So that the openshift/machine-config-operator server can dispatch on them to aid with Ignition spec 3 transitions.
|
Required by: coreos/ignition-dracut#136 |
I plan to use this in ignition-dracut to inject e.g. headers from `/usr/lib/os-release`, so that a server (such as the OpenShift 4 machine-config-operator server) can dispatch on them.
cgwalters
force-pushed
the
fetch-headers
branch
from
be1f3e1 to
6566d4e
Compare
|
@cgwalters looking at the other dracut patches, I think your long term goal is to lift those from initramfs |
| @@ -272,7 +276,17 @@ func (e *Engine) fetchReferencedConfig(cfgRef types.ConfigReference) (types.Conf | |||
| if err != nil { | |||
| return types.Config{}, err | |||
| } | |||
| rawCfg, err := e.Fetcher.FetchToBuffer(*u, resource.FetchOptions{}) | |||
| headers := make(http.Header) | |||
There was a problem hiding this comment.
This means the headers specified only happen to config fetches, right?
Long term? That's what the other patch already does, yes 😉
I did think about adding this to Ignition by default, but passing things externally seemed more flexible (also, we avoid needing to have a "shell syntax parser" in Ignition). But, it does also make sense to me to have Ignition do some of this by default too. I think we'd probably want the ability to specify external headers, even if we did some of this by default though? But I don't have a really strong opinion on this - if others think it should be baked in, fine by me! |
Historically we didn't capture IIUC this is behavior that doesn't need to be customized by users, but only by distros, right? In that case, we should consider making it a compile-time option via the |
I plan to use this in ignition-dracut to inject e.g. headers
from
/usr/lib/os-release, so that a server (such as theOpenShift 4 machine-config-operator server) can dispatch on them.