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

Add centos support #4

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

jonathanmorley
Copy link

No description provided.

default['sysfs']['package'] = 'sysfsutils'
default['sysfs']['service'] = 'sysfsutils'

default['sysfs']['init_type'] = value_for_platform(

Choose a reason for hiding this comment

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

would it not be better to do some detection rather than having to manage a list of versions?

Copy link
Author

Choose a reason for hiding this comment

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

Yes, now detecting versions

Copy link

@majormoses majormoses Jun 28, 2016

Choose a reason for hiding this comment

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

I meant something more along the lines of some helper functions detect the presence of systemd, upstart, and fall back to sysvinit:

def systemd?
  IO.read('/proc/1/comm').chomp == 'systemd'
end

def upstart?
  File.executable?('/sbin/initctl')
end

def determine_init_subsytem
  if systemd?
    'systemd'
  elsif upstart?
    'upstart'
  else
    'sysv'
  end
end

We can still choose to overwrite it if we want (such as in a docker container where you would never run systemd) but we can try doing some sane default detection.

@majormoses
Copy link

@jonathanmorley is there a reason they cant be a single resource called something like service which uses some helper library to determine the appropriate subsystem? This feels kind of wrong to have a custom resource for debian as well as each init subsystem...just my 2 cents...

@majormoses
Copy link

@jonathanmorley with this we are expecting the user in their wrapper to know if they are systemd or init right? I think we should have some example in the readme. Also this is a breaking change should this be a major CB bump?

@jonathanmorley
Copy link
Author

The systemd and init resources are very similar, and I dont think there is a need to have a single resource.

Through dynamic resolution the two resources behave as one, and picks automatically based on the init process. There is no need for the user to know their init system (see tests).

The only breaking change should be the dropping of the 'default' recipe.

@majormoses
Copy link

sorry I misread, its not a breaking change. With how close they are I do feel like the effort would be minimal to make a single resource. But we can let the maintainer give their thoughts on this. I have yet to pull down and test this out.

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

Successfully merging this pull request may close these issues.

2 participants