fetch: Add support for providing HTTP headers#889
fetch: Add support for providing HTTP headers#889cgwalters wants to merge 1 commit intocoreos:mainfrom
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 |
| 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 |
4 participants
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.