Add rubygems for profiling and performance analyzing

[m-bucher]

Would it make sense to add a tool for profiling the rails requests?
https://github.com/MiniProfiler/rack-mini-profiler

Requires: theforeman/foreman#9897

Fixes #36898

[ekohl]

Perhaps, but then I'd expect a foreman-profiling package that pulls these gems in. To achieve that, we have bundler.d and subpackages in foreman.spec. For foreman-proxy there's a similar setup. The benefit is that it's easier for end users to set up and for packagers we'd benefit from automatic updates to these gems.

[m-bucher]

@ekohl agreed. I have a remaining question:
Adding bundler.d/profiling.rb could either be done in the spec-file or by adding it to https://github.com/theforeman/foreman.
The downside of adding it to foreman directly is that it will automatically be enabled on dev-boxes as well. Is that OK or is there a third option I currently just do not see.
I could add it as bundler.d/profiling.rb.off, but that seems hacky as well 🤔

[ekohl]

The correct solution is in foreman.git. Otherwise you have all the downsides and none of the upsides. Automatic packages updates won't work, we need to keep it in sync between Debian and RPM.

You actually have optional groups in bundler: https://bundler.io/guides/groups.html#optional-groups-and-bundlewith

group :profiling, optional: true do
  # ...
end

[m-bucher]

I see, can I achieve the group becoming active by installing the foreman-profiling sub-package?
I would assume I have to configure it somewhere. Maybe as a %post in the spec-file.

[ekohl]

I see, can I achieve the group becoming active by installing the foreman-profiling sub-package?
I would assume I have to configure it somewhere. Maybe as a %post in the spec-file.

I'd patch the optional: true part out in packaging with a simple sed statement. That needs to be duplicated for Debian and RPM, but once implemented it shouldn't change.

[ekohl]

I think by default this means the file is present in both foreman and foreman-profiling. Be sure to check that.

It may also be fine to include it in core if it gracefully falls back if the dependencies aren't present. Though there may be a security concern so I'm not strict on that. Just want to make sure you're doing what you intend to do.

[m-bucher]

So what I can say from trying it out is that in 'productive-mode, which means Gemfile.In` is present, all available groups are loaded, regardless of it being optional or not.

When we use bundler, groups matter, but even though I do bundle --with profiling, the group would have to be required somewhere in code like here: https://github.com/theforeman/foreman/blob/fa79806973c6de08b6d265ed1ae99c0ff4f06bd6/config/application.rb#L59

Assuming we want to have it in development-environment and in production, if it is installed, then I would keep it in bundler.d/profiling.rb but add it to development-group.

I think by default this means the file is present in both foreman and foreman-profiling. Be sure to check that.

AFAIK having the same filepath in multiple packages is a big NoNo in most packaging-frameworks and my first test suggests it is only in the foreman-profiling package after build.

[ekohl]

So what I can say from trying it out is that in productive-mode, which means Gemfile.In is present, all available groups are loaded, regardless of it being optional or not.

That's due to bundler_ext, which we use on Red Hat. We don't on Debian. Perhaps this is a good excuse to drop bundler_ext usage. The original use case was that you could ignore gem dependencies in RPMs, for security patching. These days we just make sure the gem dependencies are correct.

AFAIK having the same filepath in multiple packages is a big NoNo in most packaging-frameworks and my first test suggests it is only in the foreman-profiling package after build.

I know I've seen weirdness with this in the past, so just wanted to highlight that it should be checked.

[m-bucher]

@ekohl is this ready to merge now?