[talk] classifying BSD init

[Patrik Lundin]

On Thu, Sep 03, 2015 at 09:45:03AM +0530, Sujit K M wrote:
> On Thu, Sep 3, 2015 at 12:53 AM, Patrik Lundin <patrik at sigterm.se> wrote:
> >
> > Currently there exists both modules that handle more than one system
> > (like the service module), and modules that are separate based on what
> > tool they manage (examples of these are the package management modules
> > "apt", "yum" and "openbsd_pkg") which are separate modules but keep a
> > similar list of base arguments that they understand.
> 
> Are you sure regarding this? All I see in the current implementation is similar
> arguments only on the derivative. Like Linux Distros. BSD only.
> 

I am not sure what you are asking if I am sure about. I am
referring to the ansible modules, not the backend tools. Compare the
following:

http://docs.ansible.com/ansible/yum_module.html
http://docs.ansible.com/ansible/apt_module.html
http://docs.ansible.com/ansible/openbsd_pkg_module.html

They all understand the "name" and "state" arguments. This is what I
mean when I say they take similar basic arguments.

> >
> > This means that while I can have a playbook that works on more than one
> > operating system if it calls the service module, if I also want to
> > install packages I would need to use the "pkg_mgr" fact instead of
> > naming a specific module by name.
> >
> > Just the direction of standardizing on one scheme for handling OS agnostic
> > playbooks seems like a good thing to me. Going in the opposite direction
> > and trying to merge the package management modules would probably create
> > quite a massive module (and lets not forget that while we generally have
> > enough bandwidth to go around it might be wasteful to have ansible
> > upload large amounts of code that is never run to all managed systems).
> >
> > Another reason why I like the idea of splitting the module is because
> > it separates the logic of deciding "what tool to use" from the actual
> > tool logic. This is not that big of a deal for the *BSD classes because
> > they are already nicely compartmentalized, but the Linux class is pretty
> > complex as it stands right now.
> 
> In Ansible It get the OS dependent information every time it upgrades
> or installs
> a package.
> 

I dont understand what you mean by this.

-- 
Patrik Lundin