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

Pedoman Kontributor

Sebelum mengirimkan kode

Sebelum melompat dan mengerjakan kode, serangkaian langkah harus diambil:

  • Apakah ada bug untuk itu? Bisakah Anda melacak jika orang lain melihat bug yang sama?

  • Apakah Anda yakin tidak ada yang mengerjakan masalah ini saat ini? Mungkinkah ada ulasan yang tertunda memperbaiki masalah yang sama?

  • Sudahkah Anda memeriksa jika issue/feature permintaan Anda belum diselesaikan di branch lain?

Jika Anda ingin mengirimkan kode, harap ingat aturan berikut:

Proses peninjauan

Kode baru apa pun akan ditinjau sebelum digabungkan ke dalam repositori kami.

Kami mengikuti pedoman openstack untuk proses code reviewing <https://docs.openstack.org/project-team-guide/review-the-openstack-way.html> _.

Perlu diketahui bahwa patch apa pun dapat ditolak oleh komunitas jika tidak cocok Pedoman Umum untuk Mengirimkan Kode.

Bekerja pada perbaikan bug

Perbaikan bug apa pun harus, dalam pesan komitnya:

Closes-Bug: #bugnumber

atau

Related-Bug: #bugnumber

di mana #bugnumber merujuk ke masalah Launchpad.

Lihat juga bagian working on bugs section dari dokumentasi openstack.

Mengerjakan fitur baru

Jika Anda ingin berkontribusi pada peran untuk memperkenalkan OpenStack atau layanan infrastruktur, atau untuk meningkatkan peran yang ada, proyek OpenStack-Ansible akan menyambut kontribusi itu dan bantuan Anda dalam mempertahankannya.

Berikut adalah beberapa aturan untuk memulai:

  • Semua additions/deletions fitur besar harus disertai dengan blueprint/spec. misalnya menambahkan agen aktif tambahan ke neutron, mengembangkan peran layanan baru, dll ... Lihat juga Mengirimkan spesifikasi.

  • Sebelum membuat blueprint/spec 'Wishlist Bug' terkait dapat dimunculkan di launchpad. Masalah ini akan ditriasi dan penentuan akan dilakukan pada seberapa besar perubahan itu dan apakah perubahan tersebut menjamin blueprint/spec. Baik fitur dan perbaikan bug mungkin memerlukan pembuatan blueprint/spec. Persyaratan ini akan dipilih oleh pengulas inti dan akan didasarkan pada ukuran dan dampak perubahan.

  • Semua blueprints/specs harus dipilih dan disetujui oleh pengulas inti sebelum kode terkait akan digabungkan. Untuk informasi lebih lanjut tentang blueprints/specs, silakan baca dokumentasi OpenStack mengenai Working on Specifications and Blueprints dan milik kami sendiri Mengirimkan spesifikasi.

  • Setelah pekerjaan cetak biru (blueprint) selesai penulis dapat meminta backport pekerjaan cetak biru ke branch stabil. Setiap backport akan dievaluasi berdasarkan kasus per kasus dengan pertimbangan yang hati-hati berdasarkan pada bagaimana backport mempengaruhi setiap penyebaran yang ada. Lihat bagian Backporting untuk informasi lebih lanjut.

  • Setiap layanan OpenStack baru yang diimplementasikan yang memiliki tes Tempest tersedia harus diimplementasikan bersama dengan tes fungsional yang sesuai diaktifkan sebagai bagian dari pengembangan fitur untuk memastikan bahwa setiap perubahan pada basis kode tidak merusak fungsi layanan.

  • Penambahan fitur harus menyertakan dokumentasi yang menyediakan referensi ke dokumentasi OpenStack tentang apa fitur itu dan bagaimana cara kerjanya. Dokumentasi kemudian harus menjelaskan bagaimana ini diterapkan di OpenStack-Ansible dan opsi konfigurasi apa yang ada. Lihat juga bagian Pedoman Dokumentasi dan Catatan Rilis.

Contoh proses untuk mengembangkan peran baru

Berikut langkah-langkah untuk menulis peran:

  1. Anda dapat meninjau peran yang saat ini sedang dalam pengembangan dengan memeriksa specs repository dan unmerged specs kami di review.openstack.org. Jika Anda tidak menemukan spek untuk peran tersebut, usulkan blueprint/spec. Lihat juga Mengirimkan spesifikasi.

  2. Buat repositori sumber (misal di Github) untuk memulai pekerjaan Anda di Role.

  3. Hasilkan struktur direktori referensi untuk peran Ansible yang merupakan subset yang diperlukan dari Best Practice yang didokumentasikan. Anda mungkin menggunakan alat Ansible Galaxy untuk melakukan ini untuk Anda (misal Ansible-galaxy init). Anda juga mungkin ingin memasukkan direktori seperti docs dan ` examples`` dan tests untuk peran Anda.

  4. Hasilkan meta/main.yml segera. File ini penting bagi Ansible untuk memastikan peran dependen Anda diinstal dan tersedia dan memberi orang lain informasi yang mereka perlukan untuk memahami tujuan peran Anda.

  5. Kembangkan file tugas untuk masing-masing tahap instalasi pada gilirannya, buat penangan dan template apa pun sesuai kebutuhan. Pastikan bahwa Anda memberi tahu penangan setelah tugas apa pun yang memengaruhi cara layanan akan dijalankan (seperti modifikasi file konfigurasi). Juga berhati-hatilah bahwa kepemilikan dan izin file sesuai.

    Petunjuk

    Isi default variabel, perpustakaan, dan prasyarat saat Anda menemukan kebutuhan untuknya. Anda juga dapat mengembangkan dokumentasi untuk peran Anda secara bersamaan.

  6. Tambahkan tes ke peran. Lihat juga halaman kami Testing.

  7. Memastikan perannya cocok dengan standar terbaru OpenStack-Ansible. Lihat juga halaman Aturan kode kami.

  8. Pastikan peran menyatu (converge):

    • Menjalankan developer_mode untuk membangun dari sumber git ke lingkungan virtual Python.

    • Menyebarkan file konfigurasi yang berlaku di tempat yang tepat.

    • Pastikan layanan mulai.

    Konvergensi dapat melibatkan penggunaan peran OpenStack-Ansible lainnya (Misalnya: galera_server, galera_client, rabbitmq_server) untuk memastikan bahwa infrastruktur yang sesuai sudah ada. Menggunakan kembali peran yang ada di OpenStack-Ansible atau Ansible Galaxy sangat dianjurkan.

  9. Setelah konvergensi awal bekerja dan layanan berjalan, pengembangan peran harus fokus pada penerapan beberapa tingkat pengujian fungsional. Lihat juga Tingkatkan pengujian dengan tempest.

  10. Uji peran pada mesin baru, menggunakan skrip yang disediakan kami.

  11. Kirim peran Anda untuk ditinjau.

  12. Jika diperlukan, mintalah PTL OpenStack-Ansible untuk mengimpor peran github ke namespace openstack-ansible (Ini hanya dapat dilakukan di awal siklus pengembangan, dan dapat ditunda ke siklus berikutnya).

  13. Jika perlu, bekerja pada integrasi dalam repositori terintegrasi openstack-ansible, dan menyebarkan peran pada AIO. Lihat juga Menguji peran baru dengan AIO.

Contoh proses untuk menambahkan fitur ke peran yang ada

  1. Cari di OpenStack-Ansible Launchpad project untuk permintaan fitur.

  2. Jika tidak ada item "Wishlist" di Launchpad untuk fitur Anda, buat bug untuknya. Jangan ragu untuk bertanya apakah spesifikasi diperlukan dalam bug.

  3. Bug triage akan mengklasifikasikan jika fitur baru ini memerlukan spesifikasi atau tidak.

  4. Kerjakan file peran, ikuti kami Aturan kode.

  5. Tambahkan skenario uji peran tambahan, untuk memastikan jalur kode Anda diuji dan berfungsi.

  6. Uji skenario baru Anda dengan mesin baru. Lihat juga halaman Menjalankan tes secara lokal.

  7. Kirim kode Anda untuk ditinjau, dengan dokumentasi yang diperlukan dan catatan rilis.

Contoh proses untuk menginkubasi proyek "ops" baru

Proyek baru dalam "openstack-ansible-ops" dapat dimulai kapan saja, tanpa kendala seperti menulis spesifikasi, atau membuat bug.

Sebaliknya, kode baru harus diisolasi pada folder yang terpisah dari openstack-ansible-ops repo.

Backporting

  • Backporting didefinisikan sebagai tindakan mereproduksi perubahan dari branch lain. Unclean/squashed/modified cherry-picks dan implementasi ulang yang lengkap OK.

  • Backporting sering dilakukan dengan menggunakan kode yang sama (melalui cherry picking), tetapi ini tidak selalu terjadi. Metode ini lebih disukai ketika cherry-pick memberikan solusi lengkap untuk masalah yang ditargetkan.

  • Ketika cherry-picking commit dari satu branch ke yang lain, pesan komit harus diubah dengan file yang mungkin ada konflik saat melakukan operasi cherry-pick. Selain itu, pesan komit pilihan cherry harus mengandung komit asli SHA di dekat bagian bawah pesan komit baru. Ini bisa dilakukan dengan cherry-pick -x. Berikut informasi lebih lanjut tentang Submitting a change to a branch for review.

  • Setiap backport commit harus tetap hanya menyelesaikan satu masalah, sesuai panduan dalam Pedoman Umum untuk Mengirimkan Kode.

  • Jika backport adalah set squat dari komit pilihan, SHA asli harus dirujuk dalam pesan komit dan alasan untuk squat komit harus dijelaskan dengan jelas.

  • Ketika cherry-pick dimodifikasi dengan cara apa pun, perubahan yang dilakukan dan alasannya harus dinyatakan secara eksplisit dalam pesan komit.

  • Pekerjaan refactoring tidak boleh di-backport ke branch "released".

  • Ulasan Backport harus dilakukan dengan mempertimbangkan efek patch pada lingkungan yang ada yang digunakan oleh OpenStack-Ansible. Umum OpenStack Guidelines for stable branches dapat digunakan sebagai referensi.