addition of solaris to service module?

[Romeo Theriault]

I was hoping to add solaris SMF [1] support to the 'service' module in
ansible but after looking over the service module I'm not sure if this
is the best idea anymore. Mainly since the solaris SMF tools are quite
different than the linux based equivalents. For example, in SMF, there
is not a clean separation between chkconfig and service. It's the same
tool that is used to start a service and enable it on boot, svcadm.
And a different tool svcs which is used to check the status of the
service.

This among other differences, it would take quite a large refactoring
and abstracting of the module to make it work cleanly. I'm now
thinking this might be a better fit for another module entirely.

Thoughts on approach here?

Thanks,


[1] http://en.wikipedia.org/wiki/Service_Management_Facility

--
Romeo

[Michael DeHaan]

I'd say the service module likely warrants such refactoring. I really would want just one service module and it probably wouldn't be too complicated (unlike package management).

-- Michael

[Romeo Theriault]

On Sun, Sep 23, 2012 at 1:16 AM, Michael DeHaan
<michael...@gmail.com> wrote:
> I'd say the service module likely warrants such refactoring. I really would want just one service module and it probably > wouldn't be too complicated (unlike package management).

Actually, I think it's a quite similar scenario to package management.
I say this because of the wide variance of how different platforms
handle services (think freebsd's rc.conf, solaris's smf, gentoo's
rc-update, aix's stopsrc/startsrc, daemontools, runit, etc, etc...),
their differing capabilities and how differently they implement these
features.

For example:
* enabling and disabling a service in aix requires editing /etc/inittab file.
* Solaris SMF does not seperate the act of enabling a service and
starting it. To enable it you have to start it. Same goes for
disabling it. To disable it you have to stop it. (Yes it's silly, but
that's how it works.)
* etc...

Just thinking aloud here to make sure we're on the same page. But my
thoughts are that If we're going to try to keep this as one module I
think it makes sense to have a base service module class and then
different platforms would need to subclass the base class to define
how they implement each of the features. I think this keeps it cleaner
and more maintainable. The tricky part of doing it this way though
would be the best way to determine what arch/platform they are running
on to automatically figure out which service subclass to use.

Thoughts? Suggestions?


--
Romeo

[Michael DeHaan]

>
> For example:
> * enabling and disabling a service in aix requires editing /etc/inittab file.
> * Solaris SMF does not seperate the act of enabling a service and
> starting it. To enable it you have to start it. Same goes for
> disabling it. To disable it you have to stop it. (Yes it's silly, but
> that's how it works.)

I think that's ok if this just works that way under the covers.

We can keep the user from worrying about how it works.

> * etc...
>
> Just thinking aloud here to make sure we're on the same page. But my
> thoughts are that If we're going to try to keep this as one module I
> think it makes sense to have a base service module class and then
> different platforms would need to subclass the base class to define
> how they implement each of the features. I think this keeps it cleaner
> and more maintainable. The tricky part of doing it this way though
> would be the best way to determine what arch/platform they are running
> on to automatically figure out which service subclass to use.

>
> Thoughts? Suggestions?
>

Subclassing sounds great to me.

OS detection could work similar to the way the facts do it.

[Romeo Theriault]

Ok, I'll give it a go and see what I can come up with.

--
Romeo

[Paul Wolstenholme]

Curious where this ended up. This would be awesome.

Cheers,

Paul

[Paul Wolstenholme]

Oops. I should have check first:

https://github.com/ansible/ansible/pull/2490

Works great. Thanks!

Cheers,

Paul