Skip to content
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

kola/tests/ignition: add test for systemd instantiated units #1266

Merged

Conversation

sohankunkerkar
Copy link
Member

@sohankunkerkar sohankunkerkar commented Mar 19, 2020

This PR is not mergeable until (coreos/ignition#934) PR gets merged.

@sohankunkerkar sohankunkerkar changed the title {WIP] kola/tests/ignition: add test for systemd instantiated units [WIP] kola/tests/ignition: add test for systemd instantiated units Mar 19, 2020
@cgwalters
Copy link
Member

This depends on coreos/ignition#934 so we can't have the test run until we have the patched Ignition built in FCOS.

That said, we could land all the code for the test and just comment out the register bit, and then turn on the register once it's ready.

Going into a future in which we use exttests more...ultimately, exttests would need to do "version/feature detection", so we can support running tests from git master on older releases easily. (Or we could try to do something where we check out the git commit for projects based on the version in the OS but that gets tricky)

m := c.Machines()[0]

fooStatus := c.MustSSH(m, "systemctl status echo@foo.service")
barStatus := c.MustSSH(m, "systemctl status echo@bar.service")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

might be able to use systemctl is-enabled echo@foo.service --quiet and systemctl is-active --quiet echo@foo.service here instead and just use the exit code

Comment on lines 60 to 62
if strings.Contains(string(fooStatus), "inactive") && strings.Contains(string(barStatus), "inactive") {
c.Fatalf("services are not enabled or systemd-presets did not run")
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should probably check them individually rather than together, right? i.e. if either is not enabled or not active then the test fails.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking about failing the entire test if either of them isn't enabled/active rather than checking it individually.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

right what you said is what we want to do and also what I'm saying we should do. What I'm saying here is I don't think your code is doing that. The if () && () that you are doing I think will only fail this test if both are inactive. What if one is active and one isn't? Then the current code would pass.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

right what you said is what we want to do and also what I'm saying we should do. What I'm saying here is I don't think your code is doing that. The if () && () that you are doing I think will only fail this test if both are inactive. What if one is active and one isn't? Then the current code would pass.

Yes, you're right. I have written that condition taking the assumption that those two services will either be active or inactive. I wasn't sure (specifically for instantiated services) if we need to consider a case where only one of them will be active. Thanks for the clarification.

@arithx
Copy link
Contributor

arithx commented Mar 23, 2020

Going into a future in which we use exttests more...ultimately, exttests would need to do "version/feature detection", so we can support running tests from git master on older releases easily. (Or we could try to do something where we check out the git commit for projects based on the version in the OS but that gets tricky)

Alternatively we could properly implement version detection back into kola for both FCOS & RHCOS & use the MinVersion & MaxVersion fields. One big caveat is that given the *COS version number schemes it can be a bit tricky to figure out a way to define it that can work for multiple streams.

@dustymabe
Copy link
Member

The code LGTM, but we do need to wait until a new version of ignition hits the repos.

/hold

@sohankunkerkar WDYT about dropping [WIP] from the title?

@dustymabe
Copy link
Member

/hold

@sohankunkerkar sohankunkerkar changed the title [WIP] kola/tests/ignition: add test for systemd instantiated units kola/tests/ignition: add test for systemd instantiated units Mar 24, 2020
@sohankunkerkar
Copy link
Member Author

/unhold

@dustymabe
Copy link
Member

and the latest version of testing stream has new ignition in it so we should be good to go

@cgwalters
Copy link
Member

/lgtm

@openshift-ci-robot
Copy link

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ashcrow, cgwalters, dustymabe, sohankunkerkar

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

The pull request process is described here

Needs approval from an approver in each of these files:
  • OWNERS [ashcrow,cgwalters,dustymabe]

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

@openshift-merge-robot openshift-merge-robot merged commit 951805e into coreos:master Mar 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants