You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
pkg/asset/machines: Convert Master to a WriteableAsset
Since 3326b6b (pkg/tfvars: Pull from []Machine instead of
InstallConfig, 2018-11-28, openshift#792), we've been consuming structured
master configurations to generate Terraform variables. But before
this commit, the Openshift asset was the WriteableAsset responsible
for the master configs, giving you the following issue:
1. openshift-install create manifests
i. Master asset populated with structured data
ii. Openshift asset pulls in Master, flattens to YAML, and writes to
disk.
2. openshift-install create cluster
i. Openshift asset reads master YAML from disk.
ii. TerraformVariables asset pulls in Master, but it's empty.
iii. Panic [1].
With this commit, responsibility for reading and writing master
manifests to disk gets shifted to the Master asset itself.
I've dropped the structured Master properties (Machines and
MachineDeprecated) in favor of new methods on the asset. There are
three possible paths towards recovering the asset that we feed in to
TerraformVariables:
a. After rendering it with Generate. This information had been
structured before this commit, so no problems here.
b. After reading from the disk. This information could be
unmarshalled in Master.Load(), but...
c. After loading it from the state file. There are no hooks for
custom unmarshalling in this pathway, so while the generic YAML
unmarshal would give us a structured machine object, it would not
unmarshal the RawExtension that holds the provider spec.
The lack of custom-unmarshal hooks for (c) means there's no reliable
way to use Master properties to feed TerraformVariables structured
provider information. With this commit, we use Master methods
instead. That's just as efficient for the (b) and (c) cases, and
while it's an uneccessary (de)serialize cycle for (a), that's not too
expensive.
Unpacking the YAML data into the appropriate structures is a bit
hairy. I'm not familiar with this code though, maybe there's a better
way. It will help once we complete the shift to the OpenShift
machine-API types started in cf60daa (Pivot aws from cluster.k8s.io
into machine.openshift.io, 2019-02-01, openshift#1175).
I've also taken the opportunity to drop the list. It saves us a few
lines of code for (de)serializing, and there's no upside to collecting
the Machine configs together in a single file.
The "glob, but not the master files" logic in the Openshift loader is
also a bit ugly. Moving forward, I expect us to push the remaining
Openshift assets out into their own assets as well, which would allow
us to tighten down on the wildcard there.
There's also a bit of dancing to ensure our Machine filenames are
ordered by increasing index. I'm padding the filenames with %02d (for
example) to get ...-01.yaml, etc. so they come back in the right order
on load (filepath.Glob sorts its output [2]). To avoid hard-coding a
pad size, I format the largest index, measure its length, and use that
length to construct padFormat.
[1]: openshift#1205
[2]: https://github.com/golang/go/blob/go1.11.5/src/path/filepath/match.go#L325
0 commit comments