# addition of solaris to service module? **URL:** \ **Category:** Ansible Project\ **Created:** [September 23, 2012, 8:57am UTC](https://forum.ansible.com/t/addition-of-solaris-to-service-module/11919 "2012-09-23T08:57:55Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![Romeo\_Theriault](https://avatars.discourse-cdn.com/v4/letter/r/839c29/32.png) [@Romeo\_Theriault](https://forum.ansible.com/u/Romeo_Theriault)\ **Post date:** [September 23, 2012, 8:57am UTC](https://forum.ansible.com/t/addition-of-solaris-to-service-module/11919/1 "2012-09-23T08:57:55Z")
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](http://en.wikipedia.org/wiki/Service_Management_Facility) ---
**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\ **Post date:** [September 23, 2012, 11:16am UTC](https://forum.ansible.com/t/addition-of-solaris-to-service-module/11919/2 "2012-09-23T11:16:52Z")
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 ---
**Author:** ![Romeo\_Theriault](https://avatars.discourse-cdn.com/v4/letter/r/839c29/32.png) [@Romeo\_Theriault](https://forum.ansible.com/u/Romeo_Theriault)\ **Post date:** [September 23, 2012, 10:08pm UTC](https://forum.ansible.com/t/addition-of-solaris-to-service-module/11919/3 "2012-09-23T22:08:15Z")
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? ---
**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\ **Post date:** [September 23, 2012, 10:50pm UTC](https://forum.ansible.com/t/addition-of-solaris-to-service-module/11919/4 "2012-09-23T22:50:23Z")
> 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. ---
**Author:** ![Romeo\_Theriault](https://avatars.discourse-cdn.com/v4/letter/r/839c29/32.png) [@Romeo\_Theriault](https://forum.ansible.com/u/Romeo_Theriault)\ **Post date:** [September 24, 2012, 12:20am UTC](https://forum.ansible.com/t/addition-of-solaris-to-service-module/11919/5 "2012-09-24T00:20:12Z")
Ok, I'll give it a go and see what I can come up with. ---
**Author:** ![Paul\_Wolstenholme](https://avatars.discourse-cdn.com/v4/letter/p/e47c2d/32.png) [@Paul\_Wolstenholme](https://forum.ansible.com/u/Paul_Wolstenholme)\ **Post date:** [February 1, 2014, 12:22am UTC](https://forum.ansible.com/t/addition-of-solaris-to-service-module/11919/6 "2014-02-01T00:22:24Z")
Curious where this ended up. This would be awesome. Cheers, Paul ---
**Author:** ![Paul\_Wolstenholme](https://avatars.discourse-cdn.com/v4/letter/p/e47c2d/32.png) [@Paul\_Wolstenholme](https://forum.ansible.com/u/Paul_Wolstenholme)\ **Post date:** [February 1, 2014, 1:53am UTC](https://forum.ansible.com/t/addition-of-solaris-to-service-module/11919/7 "2014-02-01T01:53:58Z")
Oops. I should have check first: [https://github.com/ansible/ansible/pull/2490](https://github.com/ansible/ansible/pull/2490) Works great. Thanks! Cheers, Paul