[ English | Indonesia | Deutsch | 日本語 ]
Bekerja dengan Roadmap¶
Berita baiknya: OpenStack memiliki transparansi yang belum pernah terjadi sebelumnya ketika datang untuk memberikan informasi tentang apa yang akan terjadi. Berita buruknya: setiap rilis bergerak sangat cepat. Tujuan dari lampiran ini adalah untuk menyoroti beberapa halaman yang berguna untuk dilacak, dan mengambil tebakan yang terpelajar tentang apa yang akan terjadi pada rilis berikutnya dan mungkin lebih jauh.
OpenStack mengikuti siklus rilis enam bulan, biasanya dirilis pada bulan April / Mei dan Oktober / November setiap tahun. Pada awal setiap siklus, masyarakat berkumpul di satu lokasi untuk Project Teams Gathering (PTG). Di PTG, fitur untuk rilis mendatang dibahas, diprioritaskan, dan direncanakan. Gambar di bawah ini menunjukkan contoh siklus rilis, dengan tanggal yang menunjukkan rilis tonggak, pembekuan kode, dan tanggal pembekuan string, bersama dengan contoh kapan KTT terjadi. Tonggak sejarah adalah rilis sementara dalam siklus yang tersedia sebagai paket untuk diunduh dan diuji. Pembekuan kode (code freeze) menghentikan penambahan fitur baru ke rilis. Pembekuan string (string freeze) menghentikan perubahan string dalam kode sumber.
Informasi Tersedia untuk Anda¶
Ada beberapa sumber informasi yang tersedia yang dapat Anda gunakan untuk melacak keinginan pengembangan OpenStack Anda.
Mempengaruhi Roadmap¶
OpenStack benar-benar menyambut ide-ide Anda (dan kontribusi) dan sangat menghargai umpan balik dari pengguna perangkat lunak dunia nyata. Dengan mempelajari sedikit tentang proses yang mendorong pengembangan fitur, Anda dapat berpartisipasi dan mungkin mendapatkan tambahan yang Anda inginkan.
Permintaan fitur biasanya memulai kehidupannya di Etherpad, alat pengeditan kolaboratif, yang digunakan untuk membuat catatan koordinasi pada sesi puncak desain khusus untuk fitur tersebut. Ini kemudian mengarah pada pembuatan cetak biru di situs Launchpad untuk proyek tertentu, yang digunakan untuk menggambarkan fitur lebih formal. Cetak biru kemudian disetujui oleh anggota tim proyek, dan pengembangan dapat dimulai.
Karena itu, cara tercepat untuk mempertimbangkan permintaan fitur Anda adalah dengan membuat Etherpad dengan ide-ide Anda dan mengusulkan sesi ke PTG. Jika PTG telah lulus, Anda juga dapat membuat cetak biru secara langsung. Baca ini blog post about how to work with blueprints perspektif Victoria Martínez, pengembang intern.
Roadmap untuk rilis berikutnya yang sedang dikembangkan dapat dilihat di Releases.
Untuk menentukan fitur potensial yang masuk ke rilis mendatang, atau untuk melihat fitur yang diterapkan sebelumnya, lihat cetak biru yang ada seperti OpenStack Compute (nova) Blueprints, OpenStack Identity (keystone) Blueprints, dan catatan rilis.
Selain dari jalur direct-to-blueprint, ada mekanisme lain yang sangat dipertimbangkan untuk memengaruhi roadmap pengembangan: survei pengguna. Ditemukan di OpenStack User Survey <https://www.openstack.org/user-survey/> _, ini memungkinkan Anda untuk memberikan rincian penyebaran dan kebutuhan Anda, secara anonim secara default. Setiap siklus, komite pengguna menganalisis hasil dan menghasilkan laporan, termasuk memberikan informasi spesifik kepada komite teknis dan pimpinan tim proyek.
Aspects to Watch (aspek untuk dilihat)¶
Anda ingin mengawasi area yang meningkat dalam OpenStack. Cara terbaik untuk "watch" peta jalan untuk setiap proyek adalah dengan melihat cetak biru yang disetujui untuk bekerja pada rilis tonggak. Anda juga dapat belajar dari webinar PTL yang mengikuti KTT OpenStack dua kali setahun.
Peningkatan Kualitas Driver¶
Peningkatan kualitas utama telah terjadi di seluruh driver dan plug-in di Block Storage, Compute, dan Networking. Khususnya, pengembang driver Compute dan Networking yang memerlukan produk-produk perangkat keras atau kepemilikan sekarang diminta untuk menyediakan sistem pengujian eksternal otomatis untuk digunakan selama proses pengembangan.
Upgrade yang Lebih Mudah¶
Salah satu fitur yang paling banyak diminta sejak OpenStack dimulai (untuk komponen selain Object Storage, yang cenderung "just work"): peningkatan yang lebih mudah. Dalam semua rilis terbaru, komunikasi pesan internal diversi versi, layanan makna secara teoritis dapat kembali ke perilaku backward-compatible. Ini memungkinkan Anda untuk menjalankan versi beberapa komponen yang lebih baru, sambil mempertahankan versi yang lebih lama dari yang lain.
Selain itu, migrasi basis data sekarang diuji dengan alat Turbo Hipster. Alat ini menguji kinerja migrasi basis data pada salinan basis data pengguna dunia nyata.
Perubahan ini telah memfasilitasi panduan peningkatan OpenStack pertama yang tepat, ditemukan di ops-upgradeades, dan akan terus meningkat pada rilis berikutnya.
Penghentian Nova Network¶
Dengan diperkenalkannya full software-defined networking stack (tumpukan jaringan yang ditentukan oleh perangkat lunak lengkap) yang disediakan oleh OpenStack Networking (neutron) dalam rilis Folsom, upaya pengembangan pada kode jaringan awal yang tetap menjadi bagian dari komponen Compute secara bertahap berkurang. Sementara banyak yang masih menggunakan nova-network dalam produksi, telah ada rencana jangka panjang untuk menghapus kode yang mendukung OpenStack Networking yang lebih fleksibel dan berfitur lengkap.
Upaya telah dilakukan untuk menurunkan (deprecate) nova-network selama rilis Havana, yang dibatalkan karena kurangnya fungsi yang setara (seperti mode FlatDHCP multi-host high-availability yang disebutkan dalam panduan ini), kurangnya migrasi jalur antara versi, pengujian yang tidak mencukupi, dan kesederhanaan saat digunakan untuk kasus penggunaan yang lebih mudah nova-network yang didukung secara tradisional. Meskipun upaya signifikan telah dilakukan untuk mengatasi masalah ini, nova-network tidak ditinggalkan dalam rilis Juno. Selain itu, untuk tingkat yang terbatas, patch ke nova-network telah mulai diterima lagi, seperti menambahkan fitur pengaturan per-network dan dukungan SR-IOV di Juno.
Ini membuat Anda memiliki titik keputusan penting saat merancang cloud Anda. OpenStack Networking cukup kuat untuk digunakan dengan sejumlah kecil pembatasan (masalah kinerja dalam beberapa skenario, hanya ketersediaan tinggi dasar layer 3 systems) dan menyediakan banyak fitur lebih banyak daripada nova-network. Namun, jika Anda tidak memiliki kasus penggunaan yang lebih kompleks yang dapat mengambil manfaat dari kemampuan jaringan yang ditentukan perangkat lunak lebih lengkap, atau tidak nyaman dengan konsep-konsep baru yang diperkenalkan, nova-network dapat terus menjadi opsi yang layak untuk 12 berikutnya bulan.
Demikian pula, jika Anda memiliki cloud yang ada dan ingin memutakhirkan dari nova-network ke OpenStack Networking, Anda harus memiliki opsi untuk menunda upgrade untuk periode waktu ini. Namun, setiap rilis OpenStack membawa inovasi baru yang signifikan, dan terlepas dari penggunaan metodologi jaringan Anda, mungkin yang terbaik untuk mulai merencanakan peningkatan dalam jangka waktu yang wajar dari setiap rilis.
Seperti yang disebutkan, saat ini tidak ada cara untuk bermigrasi secara bersih dari nova-network ke neutron. Kami menyarankan Anda mengingat migrasi dan apa proses yang mungkin terlibat ketika jalur migrasi yang tepat dirilis.
Distributed Virtual Router (router virtual terdistribusi)¶
Salah satu keluhan lama seputar OpenStack Networking adalah kurangnya ketersediaan tinggi untuk komponen layer 3. Rilis Juno memperkenalkan Distributed Virtual Router (DVR), yang bertujuan untuk menyelesaikan masalah ini.
Indikasi awal adalah bahwa ia melakukan ini dengan baik untuk serangkaian skenario dasar, seperti menggunakan plug-in ML2 dengan Open vSwitch, satu jaringan eksternal datar dan jaringan penyewa VXLAN. Namun, tampaknya ada masalah dengan penggunaan VLAN, IPv6, Floating IPs, skenario lalu lintas north-south yang tinggi dan sejumlah besar node komputasi. Diharapkan ini akan meningkat secara signifikan dengan rilis berikutnya, tetapi laporan bug tentang masalah spesifik sangat diinginkan.
Penggantian Open vSwitch Plug-in dengan Modular Layer 2¶
Plug-in Modular Layer 2 adalah kerangka kerja yang memungkinkan OpenStack Networking untuk secara simultan memanfaatkan berbagai teknologi jaringan layer-2 yang ditemukan di pusat data dunia nyata yang kompleks. Saat ini bekerja dengan agen Open vSwitch, Linux Bridge, dan Hyper-V L2 yang ada dan dimaksudkan untuk mengganti dan mencabut plug-in monolitik yang terkait dengan agen L2 tersebut.
Versi API Baru¶
Versi ketiga dari Compute API dibahas secara luas dan dikerjakan selama siklus rilis Havana dan Icehouse. Diskusi saat ini menunjukkan bahwa V2 API akan tetap untuk banyak rilis, dan iterasi API berikutnya akan dilambangkan v2.1 dan memiliki sifat yang mirip dengan v2.0 yang ada, daripada API v3 yang sama sekali baru. Ini adalah waktu yang tepat untuk mengevaluasi semua API dan memberikan komentar ketika API generasi berikutnya sedang didefinisikan. Kelompok kerja baru dibentuk secara khusus untuk improve OpenStack APIs <https://wiki.openstack.org/wiki/API_Working_Group> _ dan membuat pedoman desain, yang dapat Anda ikuti.
OpenStack pada OpenStack (TripleO)¶
Proyek ini terus membaik dan Anda dapat mempertimbangkan menggunakannya untuk penyebaran greenfield, meskipun menurut hasil survei pengguna terbaru, masih ada untuk melihat serapan luas.
Layanan pemrosesan data untuk OpenStack (sahara)¶
Jawaban yang banyak diminta untuk masalah big data, tim berdedikasi telah membuat kemajuan yang solid pada proyek Hadoop-as-a-Service.
Penggunaan bare-metal (ironic)¶
Penggunaan bare-metal telah dipuji secara luas, dan pengembangan terus berlanjut. Rilis Juno membawa OpenStack Bare metal drive ke proyek Compute, dan itu bertujuan untuk menurunkan (deprecate) driver bare-metal yang ada di Kilo. Jika Anda adalah pengguna saat ini dari driver bare metal, cetak biru tertentu untuk diikuti adalah Deprecate the bare metal driver
Database as a Service (trove)¶
Komunitas OpenStack telah memiliki alat basis data sebagai layanan dalam pengembangan selama beberapa waktu, dan kami melihat rilis terintegrasi pertama di Icehouse. Dari rilisnya, ia dapat menggunakan server database dengan cara yang sangat tersedia, awalnya hanya mendukung MySQL. Juno memperkenalkan dukungan untuk Mongo (termasuk pengelompokan), PostgreSQL dan Couchbase, di samping fungsi replikasi untuk MySQL. Di Kilo, kemampuan pengelompokan yang lebih maju disampaikan, selain integrasi yang lebih baik dengan komponen OpenStack lainnya seperti Networking.
Message Service (zaqar)¶
Layanan untuk menyediakan antrian pesan dan pemberitahuan dirilis.
Layanan DNS (ditunjuk)¶
Layanan yang lama diminta, untuk menyediakan kemampuan untuk memanipulasi entri DNS yang terkait dengan sumber daya OpenStack telah mengumpulkan hal berikut. Proyek yang ditunjuk juga dirilis.
Perbaikan Penjadwal¶
Compute dan Block Storage keduanya bergantung pada penjadwal untuk menentukan di mana menempatkan mesin atau volume virtual. Di Havana, penjadwal Compute mengalami peningkatan yang signifikan, sedangkan di Icehouse itu penjadwal di Block Storage yang menerima dorongan. Lebih jauh ke bawah jalur, upaya memulai siklus ini yang bertujuan untuk membuat penjadwal holistik yang mencakup keduanya akan membuahkan hasil. Beberapa pekerjaan yang dilakukan di Kilo dapat ditemukan di bawah Gantt project.
Peningkatan Block Storage¶
Block Storage dianggap sebagai proyek yang stabil, dengan serapan luas dan rekam jejak yang panjang mengenai driver berkualitas. Tim telah membahas banyak bidang pekerjaan di puncak, termasuk pelaporan kesalahan yang lebih baik, penemuan otomatis, dan fitur thin provisioning.
Menuju SDK Python¶
Meskipun banyak yang berhasil menggunakan berbagai kode python-*client sebagai SDK yang efektif untuk berinteraksi dengan OpenStack, konsistensi antara proyek dan ketersediaan dokumentasi semakin berkurang. Untuk mengatasi ini, sebuah effort to improve the experience telah dimulai. Upaya pengembangan lintas proyek di OpenStack memiliki sejarah kotak-kotak (checkered history), seperti unified client project memiliki beberapa kesalahan awal. Namun, tanda-tanda awal untuk proyek SDK cukup menjanjikan, dan kami berharap dapat melihat hasilnya selama siklus Juno.
