-
Notifications
You must be signed in to change notification settings - Fork 462
Update vendoring github.com/coreos/fcct → github.com/coreos/butane #2976
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update vendoring github.com/coreos/fcct → github.com/coreos/butane #2976
Conversation
The `filesystem: "root"` kv pair is a remnant of the past from when the template format was based on the Container Linux Config spec. Nowadays, it's based on the Butane config spec (formerly known as Fedora CoreOS Config) where this property node does not exist, and is thus ignored when transpiling templates to Ignition config.
pkg/controller/common/helpers.go
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While I had the patient open, I changed this to generate a single butane config, then translate it once to ignition which is way simpler than generating a tiny butane config and then continually merging ignition.
|
/assign mkenigs |
pkg/controller/common/helpers.go
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is CoreOSConfig a subset of Butane? Could we rename this TranspileButaneToIgn? Or if there are differences maybe add a comment?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CoreOSConfig came from https://github.com/coreos/container-linux-config-transpiler - it's very similar/related to butane, but there is no strict subset or superset relationship.
I have now clarified that these templates are using butane specifically variant: fcos version: 1.2 which is defined to generate Ignition 3.2 which is what was output before.
(Really though, all we care about is the ability to conveniently define files inline)
98ca97b to
669378f
Compare
|
Hmm, ok, still failing some unit tests; I fixed some but apparently not all. Will dig at some point but need to context switch. |
|
This will depend on #2980 (The issue here is that butane's ignition generation will compress, whereas prior fcct code didn't, so we need to consistently handle compression) But even with that fixed, there's still yet another regression in |
The failure there says devices required which I think comes from butane where TestReconcilable only declares old config with it:
|
What was confusing me though is the new butane code shouldn't be involved here. But what's really happening is that butane is pulling in a new vendored ignition version, which has enhanced validation. I've now reworked this to more cleanly split up the test fix, the bump of vendored ignition, then the switch from fcct to butane. |
|
/test unit |
|
/test unit |
|
OK yeah, e.g. this passed PR says:
5219/60 = ~87 - we have a 3 minute budget before the test would arbitrarily time out and fail. That's way too little. |
is this happening in other PRs or just this one? |
|
Spot checking a few others from this query |
templates: Clean out filesystem properties
|
I also had a passing run on #2987 but then it hit the timeout after I made a minor tweak which shouldn't have changed anything |
Enable unicast keepalived for all on-prem platforms
|
/test e2e-aws |
|
OK, this one should be good to go, the CI failures look unrelated. Finally got a passed e2e-gcp-op, but...trying to decide whether I or someone needs to context switch into adding some headroom there or (much harder) parallelizing tests. |
|
Will we just drop or change the cherry-pick if coreos/ignition#1329 needs changes? |
Yeah, I think we can easily update the cherry pick. We'll just need to keep it in mind when bumping the vendored Ignition in the future but hopefully we'll have that in our collective memory. |
pkg/server/server_test.go
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if I missed it but I don't see anything testing DecodeIgnitionFileContents. Would it make sense to move this test to helpers_test.go?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added one, though this function is definitely tested indirectly in a bunch of other unit tests.
pkg/controller/common/helpers.go
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is sorting here (and below) necessary? Can you add a comment?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point! Done. It may not actually be necessary...I hit an issue that made me think it was, but perhaps it isn't?
But hmm, I think because we md5sum the machineconfigs today, we really have to be sure they're "canonicalized".
pkg/controller/common/helpers.go
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| // Handle drop-ins specially; we can only have a single entry with multiple drop-ins. | |
| // Handle drop-ins specially; we can have a single unit with multiple drop-ins. |
I'm also curious how we know there aren't other fields that would have to be merged
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any other merging Ignition would have performed that the function isn't doing now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We aren't really merging fields here, we're merging drop-ins to a single unit right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking about the function as a whole. Like what happens if there's two files with the same name? Will Butane handle that the same way as an Ignition merge?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So...in the context of these templates, having duplicate files would generate an error (I am pretty sure).
Now in practice there are duplicates, e.g. kubelet.service but that's handled by generateMachineConfigForName().
(I think we should actually fix this and template the units and avoid duplicating them in the code, because it's caused real problems in the past and likely will continue to do so)
But for now, there shouldn't be any duplicates when we reach here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might be worth commenting that as a function precondition or TODO?
To properly handle compression. Prep for using butane.
Prep for using Butane APIs more directly as part of the layering work. The logic is also a bit reworked to generate a single Butane fragment which we convert to Ignition in one go, instead of converting butane into ignition repeatedly and using config merging. There's only one wrinkle with doing this, which is that today in the templates we have multiple files which are drop-ins for `crio.service`; and we need to group those together. (I think it would be cleaner to have them in a single file in the templates, but for clarity let's handle this)
We were testing this indirectly.
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cgwalters, mkenigs The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
Why does this have the templates and unicast commits? |
|
@cgwalters: The following tests failed, say
Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
|
Note that this vendors coreos/ignition#1329 which was rejected upstream. |
Prep for using Butane APIs more directly as part of the layering
work.
(Only compile tested locally)