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

init.d support #2

Merged
merged 4 commits into from
Jun 19, 2014
Merged

init.d support #2

merged 4 commits into from
Jun 19, 2014

Conversation

kimor79
Copy link
Contributor

@kimor79 kimor79 commented Jun 17, 2014

This allows one to use init.d instead of upstart for service management. Ie in hiera:

uwsgi::service_file: /etc/init.d/uwsgi
uwsgi::service_file_mode: '0555'
uwsgi::service_provider: redhat
uwsgi::service_template: uwsgi/uwsgi_service-redhat.erb

@jarshwah
Copy link
Contributor

Looks good to me, thanks! I'll merge as soon as I run a test (probably tomorrow).

@jarshwah
Copy link
Contributor

@kimor79 I'm wondering if we should auto-detect the template to use based on the service_provider. What are your thoughts on that?

@kimor79
Copy link
Contributor Author

kimor79 commented Jun 18, 2014

Yes that would be better. I've got some other changes in the works in regards to defaults on CentOS (pid location, etc) so I'll see if I can do that as well.

@kimor79
Copy link
Contributor Author

kimor79 commented Jun 18, 2014

I was thinking something like this in params.pp:

    $service_file = $service_provider ? {
        redhat  => '/etc/init.d/uwsgi',
        upstart => '/etc/init/uwsgi.conf',
    }

    $service_file_mode = $service_provider ? {
        redhat  => '0555',
        upstart => '0644',
    }

    $service_template = $service_provider ? {
        redhat  => 'uwsgi/uwsgi_server-redhat.erb',
        upstart => 'uwsgi/uwsgi_upstart.conf.erb',
    }

But the problem I'm running into is that those variables aren't changed from 'upstart' since $server_provider [when not the default value] gets set from init.pp.

@jarshwah
Copy link
Contributor

Yes I see the issue. You'd have to do the resolution within init.pp unless we change the params defaults to be OS based (which is probably a good idea to be honest). The problem would be changing the service provider and template within params, and it being backwards incompatible.

I think the solution here is to undef the majority of parameters in init.pp, and only use defaults from params.pp when there is no user supplied parameters. We can then do service provider based resolution of the template and file mode within init.pp if they are undef'd, and trust the user selection if they are provided.

I'm probably asking a little much though. If you'd like to have a go I'd be more than happy to merge. Otherwise, I can merge what you've already provided, and I can finish off the service based defaults.

kimor79 added 2 commits June 18, 2014 11:56
This is so one doesn't have to manually configure all $service_ variables but
still can if they desire.
@kimor79
Copy link
Contributor Author

kimor79 commented Jun 18, 2014

This patch works for me using init.d on CentOS and should allow for other service providers to be configured manually while still retaining backwards compat (I haven't actually tested).

jarshwah added a commit that referenced this pull request Jun 19, 2014
@jarshwah jarshwah merged commit e1bc5b6 into rvdh:master Jun 19, 2014
@jarshwah
Copy link
Contributor

Thanks @kimor79 for the patch. I'll make a slight change so that the auto-set behaviour for non redhat or upstart providers doesn't result in empty variables, by replacing the ? upstart with ? default.

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