[talk] classifying BSD init

[Sujit K M]

On Sat, Sep 5, 2015 at 6:47 PM, Patrik Lundin <patrik at sigterm.se> wrote:
> 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

These are just documentation of the yum/apt or openbsd modules. Below
what I mean.

https://raymii.org/s/tutorials/Ansible_-_Only_if_on_specific_distribution_or_distribution_version.html

>> >
>> > 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.

Well what I mean is given below.

http://docs.ansible.com/ansible/playbooks_variables.html#information-discovered-from-systems-facts