Consider using alternative to Ohai in GitLab Rails project
Overview
- Omnibus GitLab is moving to CINC from Chef
- If both Chef and CINC are present, even with wrappers, there could be conflict
- Removes the un-used Chef binaries which waste space in the final Omnibus GitLab package
Proposal
Rather than replacing chef
with cinc
, explore using the os
rubygem instead of Ohai in the rails project to drop the chef
gem as a dependency.
From !87334 (comment 946234052)+
Robert Marshall @rmarshall
@twk3 and I had a longer discussion on this during our 1:1 this week.
My concerns are, even if we do re-writing/overwriting on the Omnibus GitLab side, it's still a risk to have two versions of these gems in play.
I posed the question: what are we using
ohai
for here?It seems that
ohai
is used for ourusage ping
functionality to get the operating system name.It may be better overall to simply remove
ohai
and replace its functionality with something much more lightweight that solves the minimal use case to reduce the amount of overhead we are carrying.Who should join this discussion that can help us identify what a lightweight replacement for
ohai
would need?
Thong Kuah @tkuah
It seems these dependencies are only used by Ohai, and more specifically Ohai::System ? Could ohai be replaced by RUBY_PLATFORM ? Or https://github.com/puppetlabs/facter ? /cc @balasankarc
it's still a risk to have two versions of these gems in play.
Say we swap out ohai, and it's dependencies. How can we prevent it from being required again ?
Robert Marshall @rmarshall
Looking at lib/gitlab/usage_data.rb, I think this could be replaced with the os gem from rubygems.
As to how to prevent it from being required again - perhaps a comment in the Gemfile? I'm not sure if there is a way to prevent it, other than to document that we shouldn't be using gems in GitLab that import chef dependencies.
Deliverables
- Update the Gem installation such that the GitLab rails project is no longer causing
chef
gems next tocinc
.