This should cover all installation scenarios in the event of different minimum requirements (i.e. Satellite, Capsule, etc..).

So to write down my ideas from yesterday:

* We already have a check for 8G RAM in the Katello installer (https://github.com/Katello/katello-installer/blob/master/hooks/pre/17-memory_check.rb) which also triggers on Satellite installs.
* The check should be moved to the Foreman installer, and load values based on the scenario, that way we could provide different "profiles" with different requirements.
* The check should "just" use facter instead of trying to parse stuff itself.

An example profile could then look like this:
memorysize_mb: 7900
processorcount: 4

Or if we would want to make it more flexible:
memorysize_mb:
  compare: min
  limit: 7900
processorcount:
  compare: min
  limit: 4

Checking for free space would be a bit harder, because
* facter does not really provide that data
* you have to account for different partition layouts

How about this?

PUPPETLABS_FACTER_RB = '/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/facter.rb'

if File.exists?(PUPPETLABS_FACTER_RB)
  require PUPPETLABS_FACTER_RB
else
  require 'facter'
end

checks = [
  { :name => 'memory', :fact => :memorysize_mb, :value => 7_900, :compare => :min, :unit => 'MB'}
]

def run_check(value, check)
  if check[:compare] == :min
    return value < check[:value]
  elsif check[:compare] == :max
    return value > check[:value]
  end
end

if app_value(:disable_system_checks) || Kafo::Helpers.module_enabled?(@kafo, 'foreman_proxy_certs')
  logger.warn 'Skipping system checks.'
else
  checks.each do |check|
    current = Facter.value(check[:fact]).to_i
    if run_check(current, check)
      $stderr.puts "This system has #{current} #{check[:unit]} #{check[:name]}, but #{check[:compare]} #{check[:value]} #{check[:unit]} are required."
      kafo.class.exit(1)
    end
  end
end

Ivan, would this be a good candidate for foreman-maintain or stay on installer?

Yes, I believe this should be in a realm of the foreman-maintain, rather than the installer.

On the other hand, until the foreman-maintain is well established in the process, we might need to have it on both places. Adding Anurag to cc as well

Are we going to use foreman-maintain to install Satellite? If not, I'd vote for it goes to the installer, as otherwise people will overlook the requirements.

True, as this is not the case at the moment +1 for keeping it in installer for now

My vote is to move this into foreman-installer and store the requirements in the scenario file. That allows us to set different requirements for foreman, katello, foreman_proxy_content and devel. It also makes it easy to have different requirements downstream. It would also reduce the amount of hooks in katello-installer and ease the path of merging it into foreman-installer.

I also agree with Evgeni that foreman-maintain is not the right place.

Can we also check for /var/lib/pulp and /var/cache/pulp residing on the same FS

*** Bug 1435421 has been marked as a duplicate of this bug. ***

(In reply to Chris Roberts from comment #11)
> Can we also check for /var/lib/pulp and /var/cache/pulp residing on the same
> FS

Why don't we put the cache into the lib dir? Then you could put all pulp data on a single filesystem that doesn't need to be the same as /var

see http://docs.pulpproject.org/en/2.13/user-guide/troubleshooting.html?highlight=cache#pulp-workers-not-starting-due-to-permission-denied-exception on how to relocate it

The Satellite Team is attempting to provide an accurate backlog of bugzilla requests which we feel will be resolved in the next few releases. We do not believe this bugzilla will meet that criteria, and have plans to close it out in 1 month. This is not a reflection on the validity of the request, but a reflection of the many priorities for the product. If you have any concerns about this, feel free to contact Red Hat Technical Support or your account team. If we do not hear from you, we will close this bug out. Thank you.

Thank you for your interest in Satellite 6. We have evaluated this request, and while we recognize that it is a valid request, we do not expect this to be implemented in the product in the foreseeable future. This is due to other priorities for the product, and not a reflection on the request itself. We are therefore closing this out as WONTFIX. If you have any concerns about this, please do not reopen. Instead, feel free to contact Red Hat Technical Support. Thank you.