Ansible: Banyak file di direktori default peran

anda dapat memiliki main.yml di tasks , yang menyertakan file lain, bahkan di subdirektori tasks , misalnya untuk mengonfigurasi dua komponen utama Anda foo dan bar dari peran besar itu:

- include: foo/main.yml
- include: bar/main.yml

Menggunakan modul include_vars untuk variabel peran default mengalahkan alasan mengapa variabel default ada di tempat pertama, yaitu digunakan untuk menyediakan "default pilihan terakhir" yang dapat dengan mudah ditimpa oleh bagian lain dari peran/buku pedoman.

Ide beberapa file dalam direktori defaults/ sebelumnya telah dibahas di IRC, kami menyimpulkan bahwa mengurai direktori defaults/ mirip dengan direktori inventory/group_vars/ dan inventory/host_vars/ akan menjadi senang bisa memiliki. Kode yang dibutuhkan sudah ada, dan mudah-mudahan dapat dengan mudah diadaptasi untuk default peran.

+1

+1

Akan menyenangkan untuk memilikinya!

+1

Ya, anggap saja default/* ditemukan dan dimuat secara otomatis seperti yang disebutkan di atas. Tampaknya solusi yang disarankan (termasuk file default tambahan dalam tugas) akan menimpa inventory vars karena variabel preseden , jadi sepertinya kita harus menggabungkan dalam 1 file untuk menghindari masalah ini sampai ditangani.

Kemungkinan 2.x prioritas variabel

    role defaults [1] (loading all role defaults here critical)
    inventory vars [2]
    inventory group_vars
    inventory host_vars
    playbook group_vars
    playbook host_vars
    host facts
    registered vars
    set_facts
    play vars
    play vars_prompt
    play vars_files
    role and include vars (hack coming in here will override everything above)
    block vars (only for tasks in block)
    task vars (only for the task)
    extra vars (always win precedence)

Ini mungkin terkait dengan #8121

+1

+1

Pasti harus memiliki fitur karena kendala prioritas variabel.
Ini juga memungkinkan untuk mendefinisikan file default per kelas variabel dan menjaga pemisahan yang bersih; misalnya, dalam jaringan, ini akan memungkinkan saya untuk menentukan satu file default untuk IPv4, satu untuk IPv6, satu untuk SNMP dan seterusnya...
Akhirnya, Tampaknya perlu untuk dapat menempatkan file-file ini ke dalam folder yang berbeda di bawah "default".

Pukul saja yang ini sendiri, jadi, pasti +1

Ini benar-benar PITA.
Jika saya dapat menyarankan solusi, itu akan menambahkan opsi, mirip dengan include_vars , tetapi dalam meta/main.yml , untuk menentukan load-order.

- dependencies: []
- default_vars:
  - "main.yml"
  - "{{ ansible_os_family }}-{{ ansible_distribution_major_version }}.yml"

Ini akan memungkinkan opsi untuk default ke ["main.yml"] dan tidak merusak kode yang ada, sambil memberi pengembang kemampuan untuk mendefinisikan variabel granular berdasarkan konteks yang mereka pilih.

Aneh. Saya benar-benar curiga ini akan berhasil di luar kotak. Salah satu dari beberapa kali yang memungkinkan sebenarnya sedikit melanggar prinsip kejutan terkecil...

Pasti +1

Untuk vars/ sama, tetapi sepertinya #2958 memutuskan untuk tidak melakukannya

Contoh @cornfeedhobo sama persis dengan kasus penggunaan saya. Dengan menggunakan include_vars, saya mencegah penggantian yang mudah dari setiap variabel individual dengan permainan.

Opsi antarmuka lainnya adalah:

• Tambahkan opsi ke modul include_vars, 'as_default', yang memproses file yang disertakan seolah-olah berada di default.

Bagi saya itu benar-benar terlihat aneh/kontra-intuitif bahwa ada direktori "default" dengan satu file di dalamnya.
Maksud saya, pernahkah Anda melihat modul python dengan satu file __main__.py di dalamnya?

Itulah mengapa saya secara intuitif berpikir bahwa fungsi yang dibicarakan pada tiket ini sudah ada. "Tentu saja saya dapat memiliki beberapa file default, ada direktori untuk itu"

include_role memungkinkan Anda untuk menentukan file 'alternatif' sekarang http://docs.ansible.com/ansible/include_role_module.html melalui opsi defaults_from

Baru saja masuk ke situasi ketika defaults/main.yml split diinginkan. Menambahkan 👍 saya ke masalah ini.

Sama di sini, saya juga membutuhkannya
+1

+1

@bcoca itu adalah tambahan yang bagus dan menambah fleksibilitas, tetapi tidak membahas masalah di sini, dan menempatkan tanggung jawab pada penulis buku pedoman, ketika tujuannya adalah untuk memberdayakan peran untuk mengatur default yang waras dengan mudah.

Silakan tinjau komentar saya di atas

Ya ini adalah fitur yang sangat membantu untuk menghindari file dengan garis 2k.
+1

+1

+1

👍

+1

+1

+1
Masalah yang sama di sini. main.yml terlalu besar, dipecah menjadi beberapa file. Kami berasumsi itu akan "berfungsi" dan memuat semua vars dalam file di bawah defaults/ karena ini adalah dir. tidak senang.

+1

+1

+1

👍

+1

+1

👍

Kalian dapat mengabaikan setiap komentar +1, tetapi saya sangat ragu Anda dapat melacak jumlah pelanggan, jadi menambahkan +1 masih merupakan cara yang layak untuk menunjukkan dukungan yang diinginkan.

Sampai perhatian masalah jelas terkait dengan jumlah pelanggan suatu masalah, selamanya berharap untuk melihat +1 komentar.

Apa yang dapat Anda harapkan adalah bahwa tim yang memungkinkan mengunci komentar masalah sebagai gantinya, jadi jangan menjadi spammer dan jangan membela mereka.

Apa yang dapat Anda harapkan adalah bahwa tim yang memungkinkan mengunci komentar masalah sebagai gantinya, jadi jangan menjadi spammer dan jangan membela mereka.

Mereka bisa melakukan itu tetapi ini adalah masalah inti untuk dapat mengembangkan peran dengan benar terutama sejak pengenalan include_role di 2.x bersama dengan metode include roles yang lama. Jika Anda mendesain peran Anda agar kompatibel dengan include_role , yang lebih disukai karena membuat pengembangan jauh lebih modular dan fleksibel daripada dengan metode roles yang lama saja, maka Anda akan memiliki untuk melacak baik termasuk default sendiri sebagai tugas di buku pedoman Anda, berikan uang kepada pengguna akhir yang seharusnya tidak perlu tahu bagaimana melakukan ini agar peran Anda berfungsi dengan baik, atau lacak platform/distro/rilis sebagai level bersarang dari Anda variabel peran yang memperumit pengembangan (walaupun berfungsi karena saya telah membuat peran yang dapat mendukung 20 versi platform berbeda di sini ). Sudahkah Anda benar-benar mencoba menulis peran yang benar-benar mendukung lebih dari beberapa platform? Tidak mengherankan mengapa sebagian besar peran di Ansible Galaxy tidak, masalah ini mungkin nomor satu di daftar IMO itu.

Jadi jika mereka pergi untuk mengunci ini, tidak menanggapi sama sekali untuk satu tahun masalah, dan sinyal kepada masyarakat bahwa mereka tidak tertarik untuk membahas isu-isu kritis yang mencegah orang dari membuat solusi nyata, maka mereka pasti dapat mengharapkan orang untuk tidak menempel sekitar dan terus menggunakan produk. Jika mereka menjawab dan memberi kesan apakah mereka setuju bahwa itu suatu masalah, maka mungkin orang akan berhenti memberi +1 untuk menarik perhatian pada masalah tersebut.

Ini hanya masalah karena mereka merilis include_role tanpa memikirkan bagaimana sebenarnya menggunakannya dalam praktik akan memengaruhi default. Memaksa seseorang untuk memilih antara menggunakan roles dan include_role untuk membuat peran bekerja dengan baik atau menambahkan pekerjaan ekstra untuk memungkinkan keduanya bekerja secara simultan adalah inti dari masalah di sini.

2 sen saya.

PS Jika Anda menurunkan +1 karena Anda tidak menginginkan notifikasi .... tekan tombol berhenti berlangganan di kanan atas dan Anda tidak akan mendapatkannya lagi.

Oke, masalah ini penting bagi Anda. Saya mengerti maksudnya. Untuk saya juga. Itulah mengapa saya berlangganan, BTW, dan itulah mengapa saya tidak ingin berhenti berlangganan, dan itulah mengapa saya menurunkan suara para spammer, dan itulah mengapa saya meningkatkan komentar asli , yang merupakan cara beradab untuk menunjukkan _lazy_ dukungan untuk itu.

Saya ingin menambahkan suara saya ke permintaan kemampuan ini dan merinci kasus penggunaan saya. Selain kemampuan sederhana untuk memecah main.yml besar, kemampuan untuk melakukan sesuatu seperti ini akan sangat bagus:

- name: Some name
  include_default_vars:
  with_first_found:
    - "{{ ansible_os_family }}-{{ ansible_distribution_major_version }}.yml"
   - main.yml

Apa yang ingin saya capai dengan ini adalah [sebagai contoh] peran openssh yang mendukung semua opsi ssh_config dan sshd_config, dan mendukung banyak OS dan versi [mis. Debian 8/9, EL6/7, dll] tetapi yang jika dipanggil tanpa vars yang disetel oleh pengguna, akan dengan aman membangun konfigurasi ke pengaturan default OS_majorversion, tetapi opsi APAPUN yang tersedia dapat diganti oleh pengguna.

Seperti yang ada sekarang, jika saya menempatkan default OS tersebut di include_vars, prioritasnya terlalu tinggi, dan pengguna tidak dapat mengganti pengaturan tersebut di inventaris, atau di group_vars/all atau di group_vars/groupname atau di Host_vars dll.

Saya yakin ada cara untuk melakukan ini sekarang, tetapi apa pun yang dapat saya pikirkan sangat tidak sopan dan jelek dan akan sulit untuk dipertahankan. Selain itu, setidaknya hingga saat ini, tidak seorang pun yang saya temui #ansible memiliki ide yang lebih baik tentang bagaimana melakukan ini dengan cara yang anggun dan dapat dipelihara.

Menambahkan fitur ini akan memungkinkan untuk ini dan dapat membantu menghasilkan peran berkualitas lebih tinggi yang tersedia di github/galaxy.

@ralphie02 tidak, itu tidak mendekati solusi untuk

Varian serupa / feature_idea: https://github.com/ansible/ansible/issues/11569

Ini benar-benar PITA.
Jika saya dapat menyarankan solusi, itu akan menambahkan opsi, mirip dengan include_vars , tetapi dalam meta/main.yml , untuk menentukan load-order.

- dependencies: []
- default_vars:
  - "main.yml"
  - "{{ ansible_os_family }}-{{ ansible_distribution_major_version }}.yml"

Ini akan memungkinkan opsi untuk default ke ["main.yml"] dan tidak merusak kode yang ada, sambil memberi pengembang kemampuan untuk mendefinisikan variabel granular berdasarkan konteks yang mereka pilih.

Saya benar-benar berpikir ini adalah solusi yang baik, tidak ada cara mudah saat ini untuk memiliki set default yang berbeda dengan os/version/etc. Implementasi ini juga menjaga kompatibilitas ke belakang sehingga ini juga merupakan pilihan yang bagus.

Sejalan dengan @abedwardsw (komentar sebelumnya):
Proposal lama >2 tahun dari @cornfeedhobo (15 :+1: !) (atau sedikit lebih baru dari @doubletwist13 ) akan sangat berguna untuk banyak peran yang saya tahu, khususnya yang cukup kompleks:
https://github.com/hortonworks/ansible-hortonworks

Referensi langsung ke komentar mereka:

• https://github.com/ansible/ansible/issues/14248#issuecomment -254059046
• https://github.com/ansible/ansible/issues/14248#issuecomment -329027052

Lihat juga proposal @geerlingguy (dari 2016!), dan komentar saya di sana (yang mencoba mengumpulkan masalah terkait): https://github.com/ansible/proposals/pull/21#issuecomment -470048538