PTG (Project Team Gathering) adalah acara di mana tim pengembangan bertemu untuk membahas tugas, status, dan rencana terkini. Beberapa tahun lalu, PTG memisahkan diri dari KTT OpenStack arus utama.
PTG pertama kali diadakan secara online melalui Zoom dan Jitsi Meet. Namun, kombinasi gambar dan suara dalam pertemuan membuat perubahan ini sama sekali tidak terlihat, terutama dengan latar belakang pertemuan tim IRC yang sekarang sudah dikenal.
Sesi Neutron tiga jam berlangsung dari Selasa hingga Jumat. Risalah rapat utama diposting di OpenStack Etherpad dan di milis OpenStack. Agenda acara dibentuk berdasarkan usulan para pengembang Neutron, dan jadwal pertemuan disiapkan oleh ketuanya, PTL (Project Team Lead) dari tim Neutron Slawek Kaplonski.
Pada artikel kali ini saya akan membahas tentang 3 topik yang menurut saya perlu mendapat perhatian, dan membutuhkan sedikit penjelasan.
OVN
Ada banyak pembicaraan tentang OVN di PTG ini, yang tidak mengherankan karena sebagian besar anggota tim inti mewakili RedHat, kontributor utama OVN.
Apa itu OVN?
- Virtualisasi jaringan L2 / L3 sumber terbuka untuk Open vSwitch (OVS):
- Sakelar logika
- Router IPv4 dan IPv6 logis
- L2 / L3 / L4 ACLs (Grup Keamanan)
- Beberapa lapisan terowongan (Geneve, STT, dan VXLAN)
- Penyeimbang beban logis
- Gerbang L2 logis-fisik berbasis TOR
- Gerbang L2 / L3 logis-fisik berbasis perangkat lunak
- Bekerja pada platform yang sama dengan OVS:
- Linux
- Wadah
- DPDK
- Integrasi dengan:
- OpenStack Neutron
- Kawanan Docker
- Kubernetes
Arsitektur OVN
“OVN dalam 75 kata.
Open Virtual Network dioperasikan oleh proyek OVS dan dikembangkan oleh tim OVS asli. Keputusan ini merupakan upaya untuk mendesain ulang bidang kendali ML2 / OVS berdasarkan pengalaman bertahun-tahun. Ini dimaksudkan untuk digunakan dengan OpenStack dan Kubernetes. OVN dibangun di atas arsitektur baru yang telah meninggalkan konsep agen Python yang berinteraksi dengan layanan API Neutron melalui RabbitMQ dan mendukung daemon C yang berkomunikasi melalui OpenFlow dan OVSDB. ” - Slawek Kaplonsky, Neutron PTL.
Awalnya, driver Neutron OVN dikembangkan sebagai proyek terpisah di stadion Neutron - jaringan-ovn, dan dalam rilisnya Ussuri dimasukkan dalam repositori Neutron utama.
Dengan demikian, solusi ini menghilangkan masalah utama ML2 / OVS - RabbitMQ, yang merupakan nilai tambah yang tidak diragukan lagi, dan secara umum “tujuan desain OVN adalah untuk memiliki implementasi kualitas produksi yang dapat beroperasi pada skala yang signifikan”. Namun, apakah OVN mendukung fungsionalitas yang tersedia saat menggunakan ML2 / OVS? Tampaknya hal tersebut tidak sepenuhnya benar, yang menjadi salah satu topik pembahasan PTG. Akibatnya, beberapa celah disorot (daftar lengkap tersedia di halaman proyek). Pertama-tama, pengembang mencatat tidak adanya atau dukungan yang tidak lengkap untuk jaringan yang dirutekan, beberapa fitur QoS, BGP, dan Zona Ketersediaan. Meski tim OVN siap melakukan semua hal di atas, dalam pertemuan tersebut mereka mengakui bahwa hal tersebut sebelumnya tidak menjadi prioritas bagi mereka - karena kepentingan internal lebih penting. Selain itu, perkembangan ML2 / OVS tentu sajatidak berhenti, yang berarti ruang baru mungkin muncul.
Namun, menurut saya, masalah utama dengan OVN adalah bahwa OVN belum banyak digunakan dan belum diuji pada instalasi besar. Selain itu, ada beberapa pertanyaan tentang Ketersediaan Tinggi:
- Salah satu komponen utama, ovn-northd, saat ini hanya mendukung mode HA aktif / pasif, aktif / aktif masih hanya dalam rencana
- Komponen sentral lainnya, ovsdb-server, juga hanya mendukung mode aktif / pasif
Ada kemungkinan bahwa poin terakhir sebenarnya sudah usang, karena dukungan untuk klaster ovsdb (berdasarkan algoritma Raft) telah ditambahkan sejak OVS 2.9, tetapi tidak jelas apakah ini telah diuji dalam versi OVN dan OpenStack. Misalnya, tiket terkait di openstack-ansible belum ditutup.
Yang juga menjadi perhatian adalah OVN menggunakan terowongan Geneve, bukan VxLAN, yang memengaruhi pengaturan MTU (header Geneve lebih besar dari VxLAN) dan dukungan untuk pemrosesan terowongan yang dipercepat perangkat keras.
Bagaimanapun, proyek ini dengan cepat mendapatkan momentum dan tampaknya dalam beberapa rilis OVN harus menjadi plugin Neutron dasar. Selain itu, selama PTG, pengembang tim inti setuju untuk menjadikan OVN sebagai plugin default untuk DevStack.
Kemana perubahan ini akan mengarah:
- OpenStack Neutron CI,
- ML2/OVS ( )
- Neutron CI , ML2/Linuxbridge ML2/OVS – ,
- , core OVN
Mengenai poin terakhir, Neutron PTL memposting pesan berikut: “Tim Neutron percaya bahwa OVN dan driver Neutron OVN dibangun di atas arsitektur modern yang memberikan fondasi yang lebih baik untuk solusi yang lebih sederhana dan lebih efisien. Kami melihat peningkatan keterlibatan dalam kubernetes-ovn, yang mengarah ke perluasan komunitas inti OVN, dan kami ingin OpenStack juga memanfaatkan investasi di OVN dari Kubernetes ini.
Saat ini, driver Neutron OVN memiliki celah dalam fungsionalitas yang didukung dibandingkan dengan ML2 / OVS, namun, tim kami mencoba untuk menutup celah ini, dan kami yakin bahwa driver ini akan menjadi masa depan Neutron, dan oleh karena itu kami ingin menjadikannya sebagai backend Neutron ML2 default untuk DevStack. "
Sejauh ini, reaksi terhadap berita ini cukup positif, meskipun masih ada keraguan tentang transisi dari VxLAN ke Geneve tunnel, cara migrasi dari ML2 OVS ke ML2 OVN, serta kinerja dan fungsionalitas yang didukung.
Penerapan EngineFacade baru
EngineFacade adalah kerangka kerja di atas sqlalchemy yang mengintegrasikan logika database yang digunakan di semua proyek OpenStack. Beberapa rilis yang lalu, telah melalui refactoring, yang menyebabkan munculnya apa yang disebut "EngineFacade baru". Langkah selanjutnya adalah menyesuaikan kerangka kerja ini ke OpenStack.
Menurut saya, topik ini masuk dalam agenda PTG karena pengerjaannya sudah berlarut-larut hingga beberapa kali rilis dan belum selesai. Alasan perkembangan peristiwa ini adalah sejumlah besar perubahan yang diperlukan, beberapa masalah non-sepele dalam proses adaptasi dan, menurut saya, kurangnya motivasi, dan karena itu sumber daya manusia. Memang, mengapa mengubah sesuatu yang sudah berfungsi dan bahkan tidak menimbulkan banyak bug? Jawaban yang cukup rinci untuk pertanyaan ini diuraikan dalam spesifikasi Mike Bayer. Di sini saya akan mencoba memberikan ringkasan singkat tentang pertimbangan dalam mendukung EngineFacade sehingga Anda tidak perlu membaca teks panjang ini:
- EngineFacade lama menyediakan API tingkat rendah, bukan API tingkat tinggi yang disesuaikan dengan kasus penggunaan tertentu, jadi ini pada dasarnya adalah pabrik, bukan fasad. Hasil dari:
- EngineFacade OpenStack
- , ,
- EngineFacade // : reader writer, , .
Kedengarannya sederhana dan logis, jadi apa masalah dengan adaptasi EngineFacade? Sejujurnya, saya tidak membahas detailnya terlalu banyak, tetapi tampaknya penyebab utama masalah ini adalah bahwa dalam beberapa skenario kompleks, EngineFacade lama disalahgunakan di Neutron dan berfungsi (!), Dan EngineFacade baru mencoba melakukan semuanya dengan benar, tetapi Namun demikian, itu merusak skrip yang berfungsi (menurut saya, masalah yang cukup khas saat bekerja dengan kode warisan). Jelas, dalam kasus ini, Anda harus terlebih dahulu memperbaiki logika skrip ini.
Faktanya, tidak banyak yang tersisa untuk diedit - hanya satu patch, dan tim inti setuju untuk bersama-sama menyelesaikan masalah ini. Tentu saja, siapa pun yang tertarik dapat membantu dalam analisis dan ulasan!
Neutron-lib
Beberapa topik telah dikhususkan untuk neutron-lib. Untuk memulainya, izinkan saya mengingatkan Anda apa itu bagi mereka yang tidak terlalu terlibat dalam pengembangan Neutron. Pertama, Neutron bukanlah sebuah proyek tunggal - pada kenyataannya, ini terdiri dari beberapa repositori yang bekerja dengan area berbeda dari jaringan OpenStack dengan nama umum Stadion Neutron, dan “neutron” hanyalah satu, meskipun merupakan proyek besar. Proyek lainnya disebut layanan lanjutan (misalnya, neutron-lbaas, -fwaas, -vpnaas, -dynamic-routing, dll.) Dan plugin pihak ketiga / vendor (misalnya jaringan-midonet, -odl, -ovn). Daftar ini mencakup proyek yang dikembangkan oleh Neutron PTL dan tim inti dan terlibat langsung di dalamnya setiap hari. Untuk membuat ini mungkin, mereka memastikan bahwa prinsip umum dan aturan kerja diikuti di seluruh Stadion dalam semua aspek pembangunan - struktur,pengembangan, gaya kode, pengujian, pendokumentasian, dll. Sejujurnya, saat ini tidak sepenuhnya benar, dan beban utama masih berada di pundak pengelola proyek.
Sebelum neutron-lib dibuat, semua proyek jaringan mengimpor semua kode umum - konstanta, antarmuka (kelas dasar abstrak), fungsi pembantu, dan banyak lagi - dari repositori utama neutron. Setiap perubahan pada kode semacam itu dalam neutron dapat merusak proyek yang bergantung. Kemudian, dalam rilis Ocata, inisiatif neutron-lib diluncurkan untuk mengatasi masalah ini: semua kode umum sekarang harus disimpan dalam repositori terpisah dan harus diversi. Secara lebih spesifik, tujuan tersebut dirumuskan sebagai berikut:
- Hapus ketergantungan subproyek dari Neutron (yaitu menghapus impor langsung dari neutron dalam subproyek)
- Kerjakan pekerjaan rumah Anda di Neutron dengan memfaktorkan ulang kode atau mendesain ulang arsitektur pola suboptimal di bagian neutron-lib yang sesuai
Faktanya, neutron-lib terlihat seperti opsi win-win: baik Neutron utama dan layanan proyek pihak ketiga harus berada dalam kegelapan sebagai hasilnya. Apa yang salah?
Kurang dukungan
Tidak ada proyek sumber terbuka yang bisa ada tanpa dukungan kontributor dan pengelola - orang yang siap menginvestasikan waktu mereka dalam mengerjakan proyek. Untuk neutron-lib, ada kekurangan sukarelawan, dan akibatnya, logika asli berhenti bekerja, yaitu. sehingga semua kode umum disimpan di sini yang dapat diimpor daripada mengimpor neutron. Pengelola utama neutron-lib (boden) meninggalkan proyek beberapa waktu lalu. Selama PTG, sebuah proposal dibuat untuk mengabaikan gagasan mem-porting semua kode umum ke neutron-lib, atau bahkan mem-porting kode neutron-lib kembali ke neutron. Proposal ini tidak lolos karena dua alasan:
- neutron-lib masih banyak digunakan
- neutron-lib membawa beberapa nilai karena menyoroti antarmuka standar yang tidak dapat diubah agar tidak merusak banyak proyek sekaligus
Setelah diskusi, neutron-lib tetap tidak berubah, tetapi kebijakan relokasi kode neutron dan keusangan perlu diperbarui.
Tentu saja, semua kode baru harus dibagikan antara neutron dan neutron-lib, jika memungkinkan. Dan itu membawa kita ke masalah kedua.
Masalah pengujian
Masalah lain terkait dengan pengujian selama pengembangan. Jika bagian dari tambalan di neutron memperkenalkan baru atau mengubah kode bersama yang ada, itu harus dikirim ke neutron-lib oleh aturan. Hal ini membuat bagian neutron dari tambalan bergantung pada perubahan lib ini. Namun, tambalan neutron saat ini sedang diuji pada versi rilis neutron-lib untuk memverifikasi bahwa mereka bekerja dengan rilis terbaru. Akibatnya, patch tersebut tidak akan lulus pengujian di CI.
Akan menguji semua patch neutron dengan kode neutron-lib dari wizard juga memiliki beberapa kelemahan. Misalnya, tidak ada jaminan bahwa wizard neutron akan bekerja dengan rilis neutron-lib terbaru, yang digunakan oleh pengguna akhir.
Berikut adalah cara untuk mengatasi masalah ini (terima kasih kepada Bence Romsics untuk ringkasannya yang luar biasa):
- , , neutron-lib , neutron .
- , :
- , “foo” neutron-lib, . neutron , “_foo” TODO , , neutron-lib.
- neutron-lib , neutron, _foo “import _foo” “from neutron-lib import foo”.
- Selain itu, Anda dapat menjalankan pemeriksaan terpisah pada CI dengan wizard dan rilis neutron-lib terbaru. Tapi hanya satu dari mereka yang bisa memilih. Cukup menggandakan jumlah tugas akan memberikan beban tambahan yang sangat besar pada infrastruktur OpenStack CI.
Selama diskusi di PTG, dibuat tiga proposal:
- Gunakan wizard neutron-lib untuk "Periksa CI"; menggunakan versi rilis neutron-lib untuk "Gate CI" - namun, jika patch neutron melewati pemeriksaan "Periksa CI" dan error pada "Gate CI", itu akan terlihat aneh
- Jangan ubah apa pun: yang terbaik adalah menjalankan pengujian pada versi rilis neutron-lib. Misalnya, ini sekarang dilakukan untuk OSC (OpenStackClient)
- Jalankan pengujian dengan wizard neutron-lib dan tambahkan tugas berkala untuk pengujian dengan rilis neutron-lib
Solusi terakhir: buat masalah non-voting baru di "Periksa CI" dengan neutron-lib dari cabang master. Pada dasarnya, semuanya tetap apa adanya, tetapi akan dimungkinkan untuk memeriksa bahwa fitur yang menyertakan perubahan dalam neutron dan neutron-lib melewati CI sebelum memasukkannya ke cabang master.
Semoga artikel ini bermanfaat dan membantu Anda lebih memahami ke mana dan mengapa Neutron menuju.
Terima kasih atas perhatian Anda!