Uploaded image for project: 'Machine Config Operator'
  1. Machine Config Operator
  2. MCO-500

Refactor calls to other programs in the MCD

XMLWordPrintable

    • Icon: Story Story
    • Resolution: Unresolved
    • Icon: Undefined Undefined
    • None
    • None
    • None
    • 8
    • False
    • Hide

      None

      Show
      None
    • False
    • 0

      Within the MCD, there are numerous places where we depend on binaries that are present on the underlying node to either perform some function or gather information. For example, we call rpm-ostree to perform node OS upgrades, reboot the node, etc. And we also call podman and oc to work with OS images. This makes testing certain code paths within the MCD very difficult or even impossible in certain cases. 

      It would be great if we had some kind of an Executor object that knows how to call exec.Command() and collect output / bubble up errors, etc. Under test, we could create a mock version of this object that the MCD can call. This aids unit-testing because in this context, we don't care about whether the MCD actually calls the binary; we just care that we were able to observe it attempting to call the binary.

       

      Done When:

      • We've introduced an Executor-style object that knows how to call exec.Command() but is abstracted enough that we can generate a mock version of it (either by hand or by using something like mockery). Alternatively, we can identify a third-party library that can perform this function.
      • Every call to exec.Command() in the MCD is replaced with a call to this new library.
      • At least one MCD method that shells out has a test written that uses a mock version of this Executor object to showcase how to write tests with it.

              Unassigned Unassigned
              zzlotnik@redhat.com Zack Zlotnik
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated: