Testing

[ English | Indonesia | English (United Kingdom) | русский | Deutsch | 한국어 (대한민국) ]

Testing

Menambahkan tes ke peran baru

Setiap tes peran ada di dalam tests/ foldernya.

Folder ini mengandung setidaknya file-file berikut:

  • test.yml ("super" playbook bertindak sebagai router uji untuk sub-playbook)

  • <role name>-overrides.yml. File var ini secara otomatis dimuat oleh skrip shell kami di tests repository.

  • inventory. Inventaris statis untuk pengujian peran. Mungkin saja beberapa peran memiliki banyak inventaris. Lihat misalnya peran neutron dengan lxb_inventory, calico_inventory.

  • group_vars dan host_vars. Folder ini akan menahan override file yang diperlukan untuk pengujian. Misalnya, ini adalah tempat Anda mengganti alamat IP, rentang IP, dan detail koneksi yang dimungkinkan.

  • ansible-role-requirements.yml. Ini harus cukup mudah: file ini berisi semua peran yang harus dikloning sebelum menjalankan peran Anda. Buku pedoman relatif peran harus dicantumkan dalam file test.yml. Namun, perlu diingat untuk NOT menciptakan kembali roda (wheel). Misalnya, jika peran Anda memerlukan keystone, Anda tidak perlu membuat playbook instal keystone Anda sendiri, karena kami memiliki playbook instal keystone generik dalam tests repository.

  • Hanya tambahkan folder zuul.d ketika peran Anda diimpor ke namespace yang dimungkinkan openstack.

Memperluas tes peran yang ada

  1. Ubah tox.ini untuk menambahkan skenario baru Anda. Jika diperlukan, Anda dapat mengganti inventaris, dan/atau file variabel.

  2. Tambahkan pekerjaan non-voting baru di zuul.d/jobs.yaml, dan kirimkan ke file tes proyek zuul.d/project.yaml.

Tingkatkan pengujian dengan tempest

Setelah konvergensi awal bekerja dan layanan berjalan, pengembangan peran harus fokus pada penerapan beberapa tingkat pengujian fungsional.

Idealnya, tes fungsional untuk peran OpenStack harus menggunakan Tempest untuk menjalankan tes fungsional. Tes yang ideal untuk dieksekusi adalah tes skenario karena mereka menguji fungsi yang diharapkan dilakukan oleh layanan dalam penyebaran produksi. Dengan tidak adanya tes skenario untuk layanan, pilihan mundur (fallback) adalah untuk menerapkan tes asap (smoke test) sebagai gantinya.

Jika tidak ada tempest disediakan, beberapa pengujian fungsional lainnya harus dilakukan. Untuk API, Anda mungkin dapat memeriksa kode respons HTTP, dengan permintaan yang dibuat khusus.

Menjalankan tes secara lokal

Linting

Konvensi pengkodean python diuji menggunakan PEP8, dengan pengecualian konvensi berikut:

  • F403 - 'from ansible.module_utils.basic import *'

Pengujian dapat dilakukan secara lokal dengan menjalankan:

./run_tests.sh pep8

Konvensi bash coding diuji menggunakan Bashate, dengan pengecualian konvensi berikut:

  • E003: Indent bukan kelipatan 4. Kami lebih suka menggunakan kelipatan 2 sebagai gantinya.

  • E006: Baris lebih panjang dari 79 kolom. Karena banyak skrip yang digunakan sebagai templat

    dan menggunakan jinja templating, ini sangat sulit untuk dicapai. Itu masih dianggap preferensi dan harus menjadi tujuan untuk meningkatkan keterbacaan, dengan alasan.

  • E040: Kesalahan sintaks ditentukan menggunakan bash -n. Karena banyak skrip dikerahkan

    sebagai templat dan menggunakan templat jinja, ini akan sering gagal. Tes ini diabaikan dengan aman karena kesalahan sintaksis akan diidentifikasi ketika menjalankan skrip yang dihasilkan.

Pengujian dapat dilakukan secara lokal dengan menjalankan:

./run_tests.sh bashate

Ansible lint diuji menggunakan ansible-lint.

Pengujian dapat dilakukan secara lokal dengan menjalankan:

./run_tests.sh ansible-lint

Sintaks playbook Ansible diuji menggunakan ansible-playbook.

Pengujian dapat dilakukan secara lokal dengan menjalankan:

./run_tests.sh ansible-syntax

Serangkaian semua tes lint dapat dilakukan secara lokal dengan menjalankan:

./run_tests.sh linters

Dokumentasi dibangun

Dokumentasi dikembangkan dalam reStructuredText (RST) dan dikompilasi ke dalam HTML menggunakan Sphinx.

Dokumentasi dapat dibangun secara lokal dengan mengeksekusi:

./run_tests.sh docs

Repo terintegrasi OpenStack-Ansible juga memiliki proses pembangunan dokumentasi tambahan, untuk membangun panduan penyebaran.

Panduan ini dapat dibuat secara lokal dengan menjalankan:

./run_tests.sh deploy-guide

Catatan rilis bangunan

Catatan rilis dihasilkan menggunakan the reno tool dan dikompilasi ke dalam HTML menggunakan Sphinx.

Catatan rilis dapat dibuat secara lokal dengan mengeksekusi:

./run_tests.sh releasenotes

Catatan

Argumen build releasenotes hanya menguji perubahan yang dilakukan. Pastikan perubahan lokal Anda dilakukan sebelum menjalankan build releasenotes.

Peran pengujian fungsional atau skenario

Untuk menjalankan tes fungsional peran, jalankan:

./run_tests.sh functional

Beberapa peran memiliki tes tambahan, seperti neutron, yang didefinisikan dalam``tox.ini``.

Untuk menjalankan tes fungsional bernama "calico", jalankan:

./run_tests.sh calico

Menguji peran baru dengan AIO

  1. Sertakan peran Anda di host penyebaran. Lihat juga Menambahkan peran baru atau utama dalam instalasi OpenStack-Ansible Anda.

  2. Lakukan persiapan host lainnya (seperti tugas yang dilakukan oleh playbook bootstrap-aio.yml). Ini termasuk tugas persiapan apa pun yang khusus untuk layanan Anda.

  3. Buat file untuk memasukkan layanan Anda dalam inventaris yang dimungkinkan menggunakan file env.d dan conf.d untuk digunakan pada host penyebaran Anda.

    Hint

    Anda dapat mengikuti contoh dari peran lain, membuat modifikasi yang sesuai memastikan bahwa label grup dalam file env.d dan conf.d konsisten.

    Hint

    Deskripsi tentang cara kerja ini dapat ditemukan di Memahami grup host (conf.d structure) dan Memahami grup container (env.d structure).

  4. Hasilkan rahasia, jika ada, seperti yang dijelaskan dalam Configure Service Credentials. Anda dapat menambahkan kunci Anda ke file yang sudah ada user_secrets.yml atau menambahkan file baru ke file openstack_deploy direktori untuk memuatnya. Berikan override untuk variabel lain yang Anda perlukan saat ini juga, baik di user_variables.yml atau file lain.

    Lihat juga halaman kami Mengganti konfigurasi default.

    Setiap rahasia yang diperlukan untuk menjalankan peran harus dicatat dalam file etc/openstack_deploy/user_secrets.yml untuk digunakan kembali oleh pengguna lain.

  5. Jika layanan Anda diinstal dari sumber atau bergantung pada paket python yang perlu diinstal dari sumber, tentukan repositori untuk kode sumber dari setiap persyaratan dengan menambahkan file ke host deploy Anda di bawah playbooks/defaults/repo_packages di OpenStack-Ansible repositori sumber yang dimungkinkan dan mengikuti pola file yang saat ini ada di direktori itu. Anda juga bisa menambahkan entri ke file yang ada di sana. Pastikan untuk menjalankan pemutaran repo-build.yml nanti sehingga roda (wheel) untuk paket Anda akan dimasukkan dalam infrastruktur repositori.

  6. Buat penyesuaian yang diperlukan untuk konfigurasi penyeimbang beban (misal ubah inventory/group_vars/all/haproxy.yml di repositori sumber OpenStack-Ansible pada host penyebaran Anda) sehingga layanan Anda dapat dijangkau melalui penyeimbang beban, jika sesuai, dan pastikan untuk menjalankan play haproxy-install.yml nanti agar perubahan Anda akan diterapkan. Harap dicatat, Anda juga dapat menggunakan variabel haproxy_extra_services` jika Anda tidak ingin memberikan layanan Anda sebagai standar untuk semua orang.

  7. Menyatukan layanan menginstal file playbook untuk peran Anda. Ini juga dapat dimodelkan dari buku pedoman layanan apa pun yang ada yang memiliki dependensi serupa dengan layanan Anda (basis data, pengiriman pesan, driver penyimpanan, titik pemasangan kontainer (container mount points), dll.). Tempat umum untuk menyimpan file playbook di peran Galaxy adalah dalam direktori examples dari root peran. Jika playbook dimaksudkan untuk menginstal layanan OpenStack, beri nama os- <service> -install.yml dan targetkan pada grup yang sesuai yang ditentukan dalam file layanan env.d. Sangat penting bahwa implementasi layanan bersifat opsional dan bahwa pemilik harus memilih untuk menggunakan penyebaran melalui populasi host di grup host yang berlaku. Jika grup host tidak memiliki host, Ansible melompati tugas playbook secara otomatis.

  8. Setiap variabel yang dibutuhkan oleh peran lain untuk terhubung ke peran baru, atau oleh peran baru untuk terhubung ke peran lain, harus diimplementasikan dalam inventory/group_vars. Vars grup pada dasarnya adalah perekat yang digunakan buku pedoman untuk memastikan bahwa semua peran diberi informasi yang sesuai. Ketika vars grup diimplementasikan, itu harus menjadi set minimum untuk mencapai tujuan mengintegrasikan peran baru ke dalam bangunan terintegrasi.

  9. Dokumentasi harus ditambahkan dalam peran untuk menggambarkan bagaimana menerapkan layanan baru di lingkungan yang terintegrasi. Konten ini harus mematuhi Pedoman Dokumentasi dan Catatan Rilis. Sampai peran tersebut telah mengimplementasikan pengujian fungsional terintegrasi (lihat juga paragraf kedewasaan pengembangan peran), dokumentasi harus memperjelas bahwa inklusi layanan di OpenStack-Ansible adalah eksperimental dan tidak sepenuhnya diuji oleh OpenStack-Ansible dalam build terintegrasi. Atau, cerita pengguna dapat dibuat.

  10. Catatan rilis fitur harus ditambahkan untuk mengumumkan ketersediaan layanan baru dan untuk merujuk ke dokumentasi peran untuk rincian lebih lanjut. Konten ini harus mematuhi Pedoman Dokumentasi dan Catatan Rilis.

  11. Harus dimungkinkan untuk melakukan tes fungsional dan terintegrasi yang mengeksekusi penyebaran dengan cara yang sama seperti lingkungan produksi. Tes harus menjalankan serangkaian tes fungsional menggunakan Tempest. Ini adalah langkah terakhir yang diperlukan sebelum layanan dapat menghapus peringatan eksperimental dari dokumentasi.

Hint

Jika Anda mematuhi pola mengisolasi persyaratan penempatan tambahan peran Anda (rahasia dan file var, fragmen HAProxy yml, file repo_package, dll.) Dalam file mereka sendiri, itu memudahkan Anda untuk mengotomatisasi langkah-langkah tambahan ini saat menguji peran Anda.

Repo fungsional atau pengujian skenario terintegrasi

Untuk menguji repo terintegrasi, ikuti Deployment Guide

Atau, Anda dapat memeriksa aio guide, atau bahkan menjalankan skrip wrapper gate, bernama skrip/gate-check-commit.sh`, dijelaskan di bawah ini.

OpenStack Infrastructure menguji secara otomatis

Seharusnya tidak ada perbedaan antara menjalankan tes dalam infrastruktur openstack, dibandingkan menjalankan secara lokal.

Pengujian dalam infrastruktur openstack dipicu oleh pekerjaan yang ditentukan dalam setiap folder zuul.d.

Lihat juga zuul user guide.

Namun, untuk tujuan keandalan, beberapa variabel didefinisikan untuk menunjuk ke OpenStack infra pypi dan paket mirror.

Tes fungsional repo terintegrasi menggunakan skrip scripts/gate-check-commit.sh, yang menerima argumen dari definisi playbook zuul run.

Walaupun skrip ini dikembangkan dan dipelihara untuk digunakan di OpenStack-CI, skrip ini dapat digunakan di lingkungan lain.

Kematangan perkembangan peran

Peran mungkin sepenuhnya matang, bahkan jika itu tidak terintegrasi dalam repositori openstack-ansible. Kematangan tergantung pada tingkat pengujiannya.

Peran dapat berada dalam salah satu dari empat tingkat kematangan:

  • Complete

  • Incubated

  • Unmaintained

  • Retired

Berikut adalah serangkaian aturan yang menentukan tingkat kematangan:

  • Suatu peran dapat dihentikan kapan saja jika tidak relevan lagi.

  • Peran dapat Incubated untuk maksimum 2 siklus.

  • Peran Incubated yang melewati pengujian fungsional akan ditingkatkan ke status Complete, dan tidak dapat kembali dalam status Incubated.

  • Peran Incubated yang tidak menerapkan pengujian fungsional dalam jangka waktu enam bulan akan menjadi Unmaintained.

  • Peran dalam status Complete dapat diturunkan ke status Unmaintained, sesuai dengan prosedur penurunan versi jatuh tempo.

Prosedur penurunan peringkat jatuh tempo

Jika sebuah peran gagal dalam uji periodik atau gerbang (periodics or gate test) selama dua minggu, bug harus diajukan, dan pesan ke milis akan dikirim, merujuk bug.

Pertemuan komunitas berikutnya harus membahas tentang penghentian peran, dan jika tidak ada kontributor yang muncul untuk memperbaiki peran tersebut, pengujian berkala akan dimatikan, dan peran tersebut akan pindah ke keadaan unmaintained.

Maturity Matrix (matriks kematangan)

Semua peran OpenStack-Ansible tidak memiliki tingkat kematangan dan pengujian yang sama.

Berikut adalah dasbor dari status peran saat ini:

Active roles

Role name Created during cycle Maturity level Included into openstack-ansible by default Supports Ubuntu Supports CentOS Supports OpenSUSE
ansible-hardening Liberty Complete
apt_package_pinning Mitaka Complete
ceph_client Newton Incubated
galera_client Mitaka Complete
galera_server Mitaka Complete
haproxy_server Newton Incubated
lxc_container_create Mitaka Complete
lxc_hosts Mitaka Complete
memcached_server Mitaka Complete
openstack_hosts Mitaka Complete
openstack_openrc Mitaka Complete
os_almanach Queens Complete
os_aodh Mitaka Complete
os_barbican Ocata Complete
os_ceilometer Mitaka Complete
os_cinder Mitaka Complete
os_cloudkitty Ocata Incubated
os_congress Unknown Unknown
os_designate Mitaka Complete
os_glance Mitaka Complete
os_gnocchi Newton Complete
os_heat Mitaka Complete
os_horizon Mitaka Complete
os_ironic Mitaka Complete
os_keystone Mitaka Complete
os_magnum Newton Complete
os_manila Stein Incubated
os_masakari Stein Incubated
os_molteniron Pike Incubated
os_monasca Ocata Unmaintained
os_monasca-agent Ocata Unmaintained
os_monasca-ui Ocata Unmaintained
os_neutron Mitaka Complete
os_nova Mitaka Complete
os_octavia Pike Complete
os_panko Rocky Inclubated
os_rally Newton Complete
os_sahara Newton Complete
os_searchlight Queens Complete
os_swift Mitaka Complete
os_tacker Queens Complete
os_tempest Mitaka Complete
os_trove Ocata Complete
os_watcher Queens Incubated
os_zaqar Queens Complete
pip_install Mitaka Complete
plugins Mitaka Complete
rabbitmq_server Mitaka Complete
repo_build Mitaka Complete
repo_server Mitaka Complete
rsyslog_client Mitaka Complete
rsyslog_server Mitaka Complete

Retired roles

Role name Created during cycle Retired during cycle
openstack-ansible-security Liberty Pike
pip_lock_down Liberty Newton
Creative Commons Attribution 3.0 License

Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.