Ansible: Fitur: Izinkan hingga-loop pada blok atau termasuk

https://github.com/ansible/ansible/issues/13262

@mkrizek Hmm, saya mencari berbagai kombinasi kata kunci, dan yang itu tidak menonjol :-(

Yang mengatakan, saya mencoba menggunakan until: dengan block: , include: dan include_tasks , tetapi yang pertama gagal, dan 2 lainnya hanya menjalankan file yang disertakan sekali .

- hosts: localhost
  tasks:
  - include: taskboot.yml
    until: 5|random == 5

Tetapi ternyata perulangan hanya berfungsi saat menggunakan loop: ?

- hosts: localhost
  tasks:
  - include: taskboot.yml
    loop: [ 1, 2, 3, 4, 5 ]

Apa pun yang saya coba, menggunakan until: tidak berfungsi dengan include: dan include_tasks: .

- hosts: localhost
  tasks:
  - include: taskbook.yml
    until: false
    retries: 5
    delay: 1

Ya, until bukan argumen yang valid untuk menyertakan, lihat https://github.com/ansible/ansible/pull/46177 .

@mkrizek Dengan kata lain, apa yang kita butuhkan tidak mungkin, baik di blok maupun di include.

Jadi saya akan tetap membuka yang ini, tetapi mengubah judulnya.

Kami memiliki proposal terbuka untuk "bertugas" termasuk, yang akan memungkinkan hal-hal seperti sampai untuk mengerjakannya.

https://github.com/ansible/proposals/issues/136

Saya, bagaimanapun, tidak percaya bahwa blok harus diperpanjang untuk mendukung fitur ini.

@sivel Dan apa alasan untuk tidak memperluas fungsionalitas ke blok? Karena itu akan menjadi hal yang wajar jika itu akan berhasil. (yaitu mampu mengulang setiap konstruksi dalam sebuah drama)

blok saat ini adalah pengelompokan 'statis', mengaktifkan loop pada mereka (tidak hanya memiliki tugas yang mewarisinya) akan membutuhkan membuatnya dinamis ... seperti yang kita lihat dengan include: ini memiliki banyak konsekuensi yang tidak segera terlihat.

Untuk memperluas apa yang @bcoca sebutkan, melakukannya akan mengharuskan kita untuk menghentikan block dan menggantinya dengan sesuatu seperti block_dynamic dan block_static .

Juga, _setiap_ pengguna ansible menggunakan blok, baik eksplisit, atau penggunaan implisit internal kami. Mereka adalah blok bangunan mendasar tentang bagaimana tugas diwakili dan dieksekusi. Mengubah fitur integral seperti itu pasti akan menyebabkan masalah yang tidak terduga.

Bagaimanapun, dokumentasi tidak memberikan detail apa pun, atau bahkan tidak membahas apa yang seharusnya berhasil dan apa yang tidak. Tidak ada perbedaan nyata antara "loop" dan sampai-loop, tidak yakin bagaimana kita bisa membuat ini lebih jelas secara keseluruhan. Harapannya adalah apa yang berfungsi untuk "loop" juga berfungsi untuk loop sampai.

saya akan melakukan keduanya, izinkan hingga/coba lagi loop untuk bekerja dengan menyertakan dan kemudian dengan jelas mendokumentasikan cara kerjanya ... jadi kami memiliki sesuatu untuk ditunjukkan ketika itu tidak memenuhi harapan beberapa orang

Hanya untuk memberikan sedikit detail tentang cara kerja penyertaan, apakah penyertaan dinamis lebih merupakan pemicu internal, bukan sesuatu yang membungkus eksekusi.

Dengan demikian, hubung singkat task_executor pada awal termasuk, menunjukkan strategi bahwa ia harus membaca file dan memasukkan blok tugas ke dalam TQM, yang nantinya akan diproses oleh task_executor.

Karena ini, tidak ada pelacakan status sebagai roll up ke induk yang disertakan. Jadi perulangan sampai, yang akan bergantung pada beberapa versi skenario gagal ketika/sukses, hanya akan merujuk pada apakah strategi diperintahkan untuk dilakukan seperti yang dijelaskan di atas atau tidak. Dalam hal ini, itu harus selalu berhasil.

Bagaimanapun, mode operasinya adalah kita melakukan hubungan pendek jauh sebelum sampai kondisi diperiksa. Jika kita hanya "membuatnya berhasil" sekarang, itu pasti tidak akan melakukan apa yang diharapkan seseorang. Untuk melakukan apa yang orang harapkan, akan membutuhkan ansible/proposals#136 untuk dilaksanakan.

sampai dalam kasus ini harus bergantung pada vars yang disetel atau didaftarkan dari tugas yang disertakan karena pendaftaran penyertaan itu sendiri tidak akan berguna ... itu masih akan 'berfungsi' hanya saja tidak seperti kebanyakan kasus lainnya.

@dagwieers Utas lainnya dikunci sekarang. Tapi saran terbaru ini ( komentar @sivel di atas) benar-benar baru:

https://github.com/ansible/ansible/issues/46203#issuecomment -425111123

Dan Anda mengatakan kami mungkin ingin membiarkan terbuka kemungkinan orang lain datang nanti, untuk melakukan PR untuk looping blok dari punggung mereka sendiri. Maka setidaknya kita bisa membuatnya sangat jelas bagi mereka, untuk menjadikannya sebagai block_dynamic: yang terpisah dan baru, dan tidak menyentuh statis tradisional block: utuh? Bukankah itu lebih masuk akal bagi semua orang? Bisakah kita semua menyetujui itu sebelumnya? Karena saya setuju dengan ide ini. Untuk semua alasan yang sama - ini akan membantu mencegah kerusakan barang lain yang sudah ada yang kita andalkan. Sementara masih memungkinkan kemungkinan seseorang untuk ikut, cobalah membuat PR untuk benar-benar mengimplementasikannya. Haruskah kita benar-benar ingin mereka membuat pekerjaan sebaik mungkin dan semacamnya. Maka kita setidaknya harus secara jelas menentukan ini. Jika kita sudah mengetahuinya sebelumnya. Yang tampaknya menjadi kasus sekarang?

Menautkan ini di sini https://github.com/ansible/ansible/issues/16621

+1 Untuk menerapkan fitur ini

Wajar jika sebuah blok harus dapat diulang. Kalau tidak, itu sangat berlawanan dengan intuisi. Ini membingungkan.

Dan sepertinya tidak ada cara untuk menulis buku pedoman dengan loop dengan lebih dari satu pernyataan. Tidak ada bahasa pemrograman yang begitu terbatas.

Sepertinya di Ansible, jika seseorang perlu melakukan sesuatu yang rumit, ia harus menulis plugin tindakan. Inilah yang akan kita lakukan.

Di sini ada banyak contoh:
https://github.com/ansible/ansible/tree/devel/lib/ansible/plugins/action

Salam

Ini benar-benar kekurangan. Ansible telah sempurna untuk sebagian besar kebutuhan saya sejauh ini, tetapi sepertinya memperluas kemampuan blok akan membuat Ansible menjadi solusi yang jauh lebih baik.

Saya mencoba menggunakan until dalam include_tasks dan tidak berhasil.

Apa yang saya lakukan sebagai solusinya adalah membuat file yml yang menyertakan tugas ( loop.yml ) dan memanggil dirinya sendiri secara rekursif ( recursive.yml ) sementara kondisinya masih belum terpenuhi.

_recursive.yml:_

---

- name: 'checking {{ watch_job }} status (recursive)'
  include_tasks: 'loop.yml'

- name: 'count ({{ watch_count | int + 1 }})'
  set_fact:
    watch_count: '{{ watch_count | int + 1 }}'

- name: 'retries ({{ (watch_timeout | int / watch_poll | int) | int }})'
  set_fact:
    watch_retries: '{{ (watch_timeout | int / watch_poll | int) | int }}'

- name: 'timeout ({{ watch_timeout }} seconds)'
  fail: 
    msg: "Timeout of {{ watch_timeout }} seconds exceeded ({{ watch_retries }} retries)"
  when: (not watch_status.finished) and (watch_count | int > watch_retries | int)

- name: 'wait for {{ watch_poll }} seconds'
  wait_for:
    timeout: '{{ watch_poll | int }}'
  when: not watch_status.finished

- name: 'call itself recursively'
  include_tasks: 'recursive.yml'
  when: not watch_status.finished

Dalam file di atas, saya menyertakan batas waktu jika terlalu lama (ini adalah peran yang menunjukkan output dari apa yang berjalan di hosts ).

Bukan solusi ideal, tetapi bekerja untuk saya dan relatif mudah diubah menggunakan until untuk melakukan hal di atas.

+1 untuk fitur ini!

+1

+1 untuk sampai loop pada blok

Saya telah mencari cara untuk melakukan until (tanpa batas) untuk sukses di semua modul di blok dan saya berhasil melakukan ini dengan include_tasks dengan rescue

Saya tidak dapat menggunakan until biasa karena IP berubah dari waktu ke waktu dan harus memodifikasinya saat dijalankan

wait_until_success.yml

- name: 'Wait until success'
  block:
    - name: Get server updated ip
      uri:
        url: https://localhost/ip
        return_content: yes
        status_code: 200
      register: ip

    - name: ssh to the server
      wait_for:
        host: "{{ ip }}"
        port: 22
        timeout: 30
        state: started
  rescue:
    - debug:
        msg: "Failed to connect - Retrying..."
    - include_tasks: wait_until_success.yml

Sama seperti @matanbaru dengan cara gagal setelah beberapa kali mencoba

- name: 'Wait until success'
  block:
    - name: Set the retry count
      set_fact:
        retry_count: "{{ 0 if retry_count is undefined else retry_count|int + 1 }}"

    - name: Get server updated ip
      uri:
        url: https://localhost/ip
        return_content: yes
        status_code: 200
      register: ip

    - name: ssh to the server
      wait_for:
        host: "{{ ip }}"
        port: 22
        timeout: 30
        state: started
  rescue:
    - fail:
        msg: Ended after 5 retries
      when: retry_count|int == 5

    - debug:
        msg: "Failed to connect - Retrying..."

    - include_tasks: wait_until_success.yml

+1 bisakah Anda menambahkan coba lagi-sampai dalam loop!
Benar-benar fitur "Harus Dimiliki"!

+1

+1

Saya telah mengunci ini untuk kontributor untuk saat ini. Menambahkan komentar +1 terlalu berisik. Untuk referensi di masa mendatang, tambahkan reaksi ke badan masalah, dan jangan berkomentar.