pkg/daemon: add atomic files writing and remove file system abstraction

[runcom]

pkg/daemon: add atomic files writing and remove file system abstraction

This patch makes sure we write files and ssh (file)
atomically so, if and only if, we'll be able to reconcile a failing machine,
we don't end up having old files lying around.

Last thing this patch does is getting rid of the FileSystemClient abstraction.
I've replaced that with normal 1st class function assignements so we don't
regress in testing. We would need to move those tests to e2e anyway.

Closes #101

@cgwalters @kikisdeliveryservice @ashcrow ptal

Signed-off-by: Antonio Murdaca [email protected]

[ashcrow]

I'm cool with replacing the abstraction with functions that can be mocked for testing.

[ashcrow]

/cc @kikisdeliveryservice

[cgwalters]

"fix files leak" is a bit understated of a commit message title 😉

"Remove filesystem mock, fix bugs"? dunno.

Personally I am not a huge fan of the current unit testing we have...I tend to prefer "real" testing and make that as convenient as possible. When the mocking starts to get nontrivial (as is the case not only with the filesystem but also our mock kube client stuff) I think the value proposition gets a lot more uncertain.

OTOH it can be easier to test error conditions via mocking. On the other other hand...a few strategic points to inject errors can go a long way.

I think though I'd say we probably shouldn't do this change right now...the bug isn't worth the code churn? Let's fix the leak in the existing code and keep this around for later?

[cgwalters]

Something that did change of course since the unit testing here was introduced is that we have our own e2e-aws-op where we can test functionality "for real". EDIT: And another thing that changed is clusters install reliably so one can use them for testing.

[runcom]

"fix files leak" is a bit understated of a commit message title

added potential, even if, on any error, we end up leaving files around :)

Personally I am not a huge fan of the current unit testing we have...I tend to prefer "real" testing and make that as convenient as possible. When the mocking starts to get nontrivial (as is the case not only with the filesystem but also our mock kube client stuff) I think the value proposition gets a lot more uncertain.

I belive the abstraction introduced was because there was no e2e, not that we have it, we can indeed test it for real

I think though I'd say we probably shouldn't do this change right now...the bug isn't worth the code churn? Let's fix the leak in the existing code and keep this around for later?

I'm not sure about, this mainly adds atomic file writing to prevent files laying around, the defer file.Close() isn't really doing nothing per-se (I spotted that later, was already adding atomic file write).

[ashcrow]

I think though I'd say we probably shouldn't do this change right now...the bug isn't worth the code churn? Let's fix the leak in the existing code and keep this around for later?

That sounds reasonable to me.

[runcom]

Something that did change of course since the unit testing here was introduced is that we have our own e2e-aws-op where we can test functionality "for real".

this is indeed why I've added Closes #101 as well in the first comment

[runcom]

#402

[runcom]

/retest

[runcom]

e2e(s) rock 🚀

--- FAIL: TestMCDeployed (308.89s)
	mcd_test.go:146: machine config didn't result in file being on any worker: timed out waiting for the condition

I0211 18:44:43.251341    5348 daemon.go:657] Unable to apply update: rename /tmp/file-write126687226 /etc/mytestconf: invalid cross-device link
E0211 18:44:43.251467    5348 writer.go:91] Marking degraded due to: rename /tmp/file-write126687226 /etc/mytestconf: invalid cross-device link

[kikisdeliveryservice]

Could you explain what this is for?

[runcom]

this is a lightweight version of the filesystem client, as in, the client existed mainly to be able to unit test the flow as we shouldn't wrap the file management API of Golang. By having a function which deals with writes only, we're able to mock it out in unit test till we have proper e2e in place for these scenarios.

[kikisdeliveryservice]

ah thanks! I missed the note on line 87.

[runcom]

Unit flake tracked here: #449

/retest

[runcom]

I'm moving this to master-4.1 once I understand how I can rebase that branch -.-

[runcom]

/retest

[cgwalters]

Can you push the rebased commit here?

[runcom]

Can you push the rebased commit here?

just done

[cgwalters]

/approve

This LGTM.

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: cgwalters, runcom

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [cgwalters,runcom]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[runcom]

/approve

This LGTM.

I guess we can let this go in with #548 as that is based on this now.