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

(FACT-3202) Add is_virtual and virtual support for crio #2574

Merged
merged 2 commits into from
Jun 7, 2024

Conversation

lollipopman
Copy link
Contributor

Prior to this change facter returned:

$ facter is_virtual
false
$ facter virtual
physical

After this change facter returns:

$ facter is_virtual
true
$ facter virtual
crio

This change separates out reading pid 1's environment from proc and reading the cgroup information. It also adds a container_other type when the container runtime is not explicitly supported.

@lollipopman lollipopman requested a review from a team as a code owner May 11, 2023 20:07
@puppetlabs-jenkins
Copy link
Collaborator

Can one of the admins verify this patch?

@lollipopman lollipopman force-pushed the crio-container-support branch 2 times, most recently from e93f832 to 0cd5606 Compare May 12, 2023 14:37
@lollipopman
Copy link
Contributor Author

Would love a review if any of the codeowners have a moment?

@lollipopman
Copy link
Contributor Author

friendly bump for a review please

@lollipopman
Copy link
Contributor Author

@joshcooper any chance you would have time to take a gander?

@lollipopman
Copy link
Contributor Author

friendly bump for a review!

@lollipopman
Copy link
Contributor Author

Would love a review, any takers?

@lollipopman
Copy link
Contributor Author

would love a review!

@joshcooper joshcooper added the enhancement New feature or enhancement label Apr 11, 2024
@lollipopman
Copy link
Contributor Author

friendly bump!

@AriaXLi
Copy link
Contributor

AriaXLi commented May 2, 2024

Hi @lollipopman thanks for the PR, could you update your PR so there's no conflicts? Thanks!

@lollipopman lollipopman force-pushed the crio-container-support branch from 0cd5606 to bae8f48 Compare May 3, 2024 20:15
@lollipopman
Copy link
Contributor Author

Happy to, pushed, thanks for looking @AriaXLi

@lollipopman lollipopman force-pushed the crio-container-support branch 3 times, most recently from 21afec5 to a6f1604 Compare May 22, 2024 16:58
@lollipopman
Copy link
Contributor Author

@AriaXLi tests are passing, do you think you could take a look? thanks!

@lollipopman
Copy link
Contributor Author

@AriaXLi any chance you could look at this again, before it bitrots? <3

Prior to this commit the safe_readlines wrapper did not support the sep
argument as supported by readlines.
@lollipopman lollipopman force-pushed the crio-container-support branch from a6f1604 to 15e7f17 Compare June 6, 2024 16:47
@lollipopman
Copy link
Contributor Author

@joshcooper patch updated, ready for another review

@joshcooper
Copy link
Contributor

joshcooper commented Jun 6, 2024

Thank you @lollipopman looks good, just running tests

Prior to this change facter returned:

    $ facter is_virtual
    false
    $ facter virtual
    physical

After this change facter returns:

    $ facter is_virtual
    true
    $ facter virtual
    crio

This change separates out reading pid 1's environment from proc and
reading the cgroup information. It also adds explicit support for podman
and returns container_other when the container runtime is not explicitly
supported.
@lollipopman lollipopman force-pushed the crio-container-support branch from 15e7f17 to 7bc38cc Compare June 6, 2024 18:13
@lollipopman
Copy link
Contributor Author

Tests look good, anything else to do @joshcooper?

@joshcooper joshcooper merged commit 3e47ee6 into puppetlabs:main Jun 7, 2024
18 checks passed
@joshcooper
Copy link
Contributor

Thank you @lollipopman!

@@ -14,45 +14,65 @@ class << self
private

def post_resolve(fact_name, _options)
@fact_list.fetch(fact_name) { read_cgroup(fact_name) }
@fact_list.fetch(fact_name) do
read_environ(fact_name) || read_cgroup(fact_name)
Copy link
Contributor

Choose a reason for hiding this comment

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

If /proc/1/environ contains container=<value> where <value> is non-empty and is not one of the values in the case, then we set vm=container_other and never fall back to read_cgroup .

Copy link
Contributor Author

Choose a reason for hiding this comment

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

true, perhaps read_environ() should only log a warning and not set the value to container_other

Copy link
Contributor

Choose a reason for hiding this comment

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

@lollipopman prior to your change, we checked /proc/1/cgroups for docker

And then 'lxc' or fell back to checking the container environment variable in /proc/1/environ

vm = 'lxc' if output_lxc || lxc_from_environ

Your commit reversed the order, so it looks in /proc/1/environ first.

read_environ(fact_name) || read_cgroup(fact_name)

Was that intentional? Would it be a problem if I reversed it?

One thing I didn't realize when I merged this is the VirtualDetector calls

Facter::Resolvers::Containers.resolve(:vm)

So the Containers resolver can't hard code container_other https://github.com/puppetlabs/facter/blob/0656d9a34ce4790129f1fd6eba5bb4d49a9b9ad1/lib/facter/resolvers/containers.rb#L60C19-L60C34

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't think I had a strong reason for changing the order, and my fault for not adding a comment if I did. I assume my rationale was that the environment variable was more authoritative, but I don't think that argument is very strong at present. As for the hard coding of container_other I agree that should be dropped and just return nil for the fact.

Copy link
Contributor

Choose a reason for hiding this comment

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

No worries @lollipopman, thanks for confirming!

@raybellis
Copy link
Contributor

raybellis commented Jan 22, 2025

Please fix this patch so that it doesn't warn when invoked on non-Linux systems (see issue 2742)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or enhancement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants