Need serial at the task level for delegate_to or another solution

226 views
Skip to first unread message

Kesten Broughton

unread,
Oct 20, 2014, 5:49:14 PM10/20/14
to ansible...@googlegroups.com

ansible has a "serial" option at the playbook level but not at the tasks level. I feel like i need a similar construct to avoid race conditions when I have multiple hosts delegate_to something.  Perhaps there is an existing ansible idiom to help me?

My current problem is copying a bunch of ssl csr's to a certificat_authority.  Then i delegate_to the ca.  The trouble comes when the CA tries to sign multiple certs in parallel.  

  - name: Sign the request
    delegate_to: "{{certificate_authority}}"
    command: creates="{{ca_out_dir}}/{{ansible_fqdn}}.crt"
             openssl ca -batch -in "{{ca_in_dir}}/{{ansible_fqdn}}.csr"
                         -out "{{ca_out_dir}}/{{ansible_fqdn}}.crt"
                         -keyfile "{{ca_key}}" 
                         -config "{{ca_cnf}}"
                         -passin "file:{{ca_keystore_password_path}}"


Output:  The task fails for the first host, but fails for others.

Certificate is to be certified until Oct 17 21:32:45 2024 GMT (3650 days)

Write out database with 1 new entries

unable to rename /etc/pki/21ct/SigningCA1/ca.db.serial.new to /etc/pki/21ct/SigningCA1/ca.db.serial

reason: No such file or directory


It seems to me that the ca.db.serial.new is a tmp resource and one target removes it while another is still using it.
I also get this on other tasks if the command acquires a lock on a resource.  I feel like if i could attache a - serial: 1 - to the above, things would work.

any tips?


Kesten Broughton
512 701 4209

Michael Peters

unread,
Oct 21, 2014, 9:58:50 AM10/21/14
to ansible...@googlegroups.com
I agree that it would be nice to have serial on the task level. Until
that happens you could break out of your current play with a one task
play that does just this but with "serial: 1" set. Then go back to
another play that doesn't use serial to finish the rest of the tasks.
> --
> 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.
> To post to this group, send email to ansible...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ansible-project/CAO2fFsV8ULz_%2BVNh7qrbPmAoiGR9dVPc4%3D%3Dib4Rh7Cr79HFpZQ%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

Michael DeHaan

unread,
Oct 21, 2014, 11:49:23 PM10/21/14
to ansible...@googlegroups.com
"ansible has a "serial" option at the playbook level but not at the tasks level."

While you can't set serial on a task, you can also in 1.8 set "run_once" to a task and it will run on just one host in the loop.

Breaking out to a new play and then restarting a different play is definitely an option.

I think a lot of people don't know a playbook can have more than one play in it.







Tomasz Kontusz

unread,
Oct 22, 2014, 3:40:51 AM10/22/14
to ansible...@googlegroups.com
Another workaround is to use with_items: play_hosts, when: inventory_hostname == item. This can be used inside a role, but generates huge amounts of output (len(play_hosts)² lines).

I think the right way here would be to fix the signing script to either work with randomly generated temporary directories or use some locking mechanism.

Michael DeHaan <mic...@ansible.com> napisał:

--
Wysłane za pomocą K-9 Mail.

Michael DeHaan

unread,
Oct 22, 2014, 2:02:59 PM10/22/14
to ansible...@googlegroups.com
"Another workaround is to use with_items: play_hosts, when: inventory_hostname == item."

This will not do what you are thinking it does.



Reply all
Reply to author
Forward
0 new messages