New module idea brainstorming

[Michael DeHaan]

Hi everyone,

Thinking about what you manage with Ansible, or would like to, and what modules we have in 1.2 so far, what are some of other modules you would like to see in Ansible that we haven't added yet?

(There is still a bit of time in 1.2, but I'm also thinking forward to future releases)

--

Michael DeHaan <mic...@ansibleworks.com>
CTO, AnsibleWorks, Inc.
http://www.ansibleworks.com/

[Kavin Kankeshwar]

I am sure many people need "until" module, which in principle is similar to "wait_for" module. Have seen many discussions about it.

This module would will look for any arbitrary statistics, like look/tail log file (maybe use logcheck/logtail) for certain line or value to be matched or call another system program and check/compare the value returned.

If i had to think about implementation, Still very fuzzy in my head, it would be have a regex/filter match for key:value, additionally a flag for serial or parallel, Command to use get statistics/strings etc. like get value from a  webservice on each host or any other tool installed which can return some value based on the request.

Would be great if this module can wait for all hosts to meet the condition and then proceed or be in rolling upgrade fashion.

An actual usecase for us is:

• Run "clinfo -l -v statistics" command on the machine (A tool which talks to Aerospike Database),
• Grep/filter/regex for a key and get key=value, returned.
• Compare value to either match or exceed or less than the desired value.

I am willing to do/help with this, but this is very custom to us, Hence would be nice to have feedback on how make it as general as possible to be used by everyone.

Regards,

--

Kavin.Kankeshwar

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Michael DeHaan]

Yeah, I've been talking about this with many different folks, though I was thinking of doing it more like this, as a language feature:

 - shell: /usr/bin/somecommand blarg

   register:  foo

   until: foo.stdout.find("haystack") != -1

   delay: 15   # wait this many seconds before trying again

   tries:  5 # fail after this many tries

Thoughts?

[James Martin]

MIchael,

I think that is a very clean solution, and fits all (of my) use cases.

- James

[Lorin Hochstein]

I would love to see an idempotent "patch" module. If I had more time, I'd write it myself, but alas I haven't had the cycles.

Lorin

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

Lorin Hochstein

Lead Architect - Cloud Services

Nimbis Services, Inc.

www.nimbisservices.com

[Patrick Regan]

I'd love to see some idempotent Gluster module, but I have no idea how it could be done. This is fairly low priority for me though. It's possible in the near future I'll have time to at least look into a strategy behind it.

I'm also curious if anyone has any ideas for Drupal configuration via Ansible. Should there be a new module for it, or try to make upgrades/updates work via already implemented modules?

--

Patrick Regan
Phone: (330) 576-4044

[C. Morgan Hamill]

Excerpts from Michael DeHaan's message of 2013-05-19 21:33:35 -0400:

> Yeah, I've been talking about this with many different folks, though I was
> thinking of doing it more like this, as a language feature:
>
> - shell: /usr/bin/somecommand blarg
> register: foo
> until: foo.stdout.find("haystack") != -1
> delay: 15 # wait this many seconds before trying again
> tries: 5 # fail after this many tries
>
> Thoughts?

This would be really great to have; I can already think of several use
cases where it would, personally, simplify things.
--
C. Morgan Hamill
<cha...@wesleyan.edu>

[Hudec Peter]

Hi,

I would like to see module, that manages user groups /supplemetary/.

The user module is good for creating users and adding them to groups /with append=yes/, but there is no way how to remove user from group.

In this module would be 3 states

State = enables, means, the user is is these groups

State = absent, the user is not in these groups

State = only = the user is only in these groups

I had no time to do this. It should be very easy to to it, while the use remodel already sdo some stuff. ;)

Peter

[Serge van Ginderachter]

On 20 May 2013 03:33, Michael DeHaan <mic...@ansibleworks.com> wrote:

 - shell: /usr/bin/somecommand blarg

   register:  foo

   until: foo.stdout.find("haystack") != -1

   delay: 15   # wait this many seconds before trying again

   tries:  5 # fail after this many tries

​+1

​

[Jimmy Tang]

On Sun, May 19, 2013 at 3:01 PM, Michael DeHaan <mic...@ansibleworks.com> wrote:

Hi everyone,

Thinking about what you manage with Ansible, or would like to, and what modules we have in 1.2 so far, what are some of other modules you would like to see in Ansible that we haven't added yet?

(There is still a bit of time in 1.2, but I'm also thinking forward to future releases)

 

how about an opennebula inventory/facts plugin?

--

http://www.sgenomics.org/~jtang/

[Edgars]

Idempotent rpm/dpkg module. 

Extended raw module which allows to use Expect script style syntax and capabilities.

Edgars

[GW]

Hi,

+1 for "patch" module, either regexp oriented or multi-line-oriented with Jinja2 constructs

Actually it is already possible to implement the multi-line-oriented approach with a hack and some Jinja2+Python magic like this:

- name: read network/interfaces content
  command: /bin/cat /etc/network/interfaces
  register: read_interfaces_content
- name: configure network/interfaces
  template: src=network/interfaces.j2 dest=/etc/network/interfaces owner=root group=root mode=0644

And than snippet for "network/interfaces.j2":

{% for line in read_interfaces_content.stdout.split('\n')  if not skip_all -%}

{% if line.startswith('# Ansible') %}
  {%- set skip_all = True %}
{% elif line == 'auto eth0' %}
  {%- set skip_line = True %}
{% elif line.startswith('iface eth0 inet ') %}
  {%- set skip_section = True %}
{% elif line == '' %}
  {%- set skip_section = False %}
{% endif -%}

{% if skip_all %}
{% elif skip_line or skip_section %}
  {%- set skip_line = False %}
#{{ line }}
{% else %}
{{ line }}
{% endif -%}

{% endfor %}
# {{ ansible_managed }}
auto eth0
iface eth0 inet dhcp
# ..put your other content here that will appear on the end of the network/interfaces file..

By redesigning it any patching can be done with such an approach, but it gets really quickly really ugly... Therefore a "patch" module that could replace this would be much appreciated.

Greetings,
   gw 

[GW]

Hm, there could also be a syntax-checking module in case you just want to ensure that some configuration files are in correct format before finalizing the deployment that will fail.

Such a module should probably use grammars (generalization of regular expressions) for syntax definitions. BNF notation is commonly used in protocol descriptions, but afaik it is only human readable. A good grammar parsing implementation is implemented in Perl6, where grammars are first-class programming constructs, like regexs, strings, integers...

- https://en.wikibooks.org/wiki/Perl_6_Programming/Grammars
- https://en.wikipedia.org/wiki/Context-free_grammar
- https://en.wikipedia.org/wiki/Backus%E2%80%93Naur_Form 

Writing grammars usually isn't so trivial, therefore a database of commonly used (eg. for valid apache, nginx, pgsql, mongodb.. configuration files) should probably be included with the module.

Greetings,
   gw 

--

[Michael DeHaan]

So, question...

Why would we need a rpm/dpkg module when we have an apt/yum module?

Your raw question is a little interesting.

(If you are trying to manipulate a device, may I ask which device?)

[Michael DeHaan]

As for syntax checking, there is already the validate option on the copy/template module you could use for this.

How it can call visudo is shown in the docs.

[Michael DeHaan]

Sounds good.

If you build it, I'll definitely include it in examples/plugins.

--

[Michael DeHaan]

There are various folks here that are deploying Drupal.

The one I'm thinking of mainly, the Four Kitchens stuff seems to be more about dev environments though.

https://github.com/fourkitchens/server-playbooks/blob/master/ubuntu-12.04-lamp-dev/setup.yml

Any comments, Mark?

[Edgars]

1. To deploy self-made packages. 

2. Cisco switches, HP iLO, Dell Drac, SUN ILOM, etc.

[Michael DeHaan]

Ok, so for 1, you can easily just set up your own repository.   I highly recommend folks do that.   Yum can also install an RPM directly.

As for 2,  various answers.

I'm waiting on Cisco to release good remote APIs for various hardware, but suspect it will be a while.  A action module that knows how to parse the CLI would be terrible, but is I think as good as we can get.

As for ILO, depends what you want to do, but the basic fence scripts around that stuff are pretty easy and straight forward.

Where things have APIs and libraries, a good 'local_action' module is the best way to deal with them, rather than trying to screen scrape.

[aam...@vecora.com]

Hi,

ACL support for the file module. I'm amazed that everyone seems to get by using only owner and group.

Regards,

Harald

On Sunday, May 19, 2013 4:01:26 PM UTC+2, Michael DeHaan wrote:

[David Golden]

On Monday, May 20, 2013 6:04:38 PM UTC-4, Michael DeHaan wrote:

Ok, so for 1, you can easily just set up your own repository.   I highly recommend folks do that.   Yum can also install an RPM directly.

You *can*, but it would be nice not not have to do that for one or two packages.  My hack has been to set a 'creates' on a file that the package installs.  That doesn't help for versioning, but it avoid repetitive installs.

David

[Michael DeHaan]

yum can still take filesystem paths though.

--

You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Edgars]

Regarding Cisco, I found that Puppet already has this functionality:

https://puppetlabs.com/blog/puppet-network-device-management/

Edgars

On Sunday, May 19, 2013 4:01:26 PM UTC+2, Michael DeHaan wrote:

[Michael DeHaan]

Cisco hardware is generally difficult because it comes in difficult flavors (Catalyst, Nexus, etc) and doesn't have a lot of strong APIs.

These modules don't seem to be well received:

http://www.scottyob.com/2012/12/08/my-experiences-of-managing-a-cisco-switch-with-puppet/

That all being said, I'd like to not discuss other CM tools too much on this list, as a professional courtesy.

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.