[ English | 中文 (简体, 中国) | русский | português (Brasil) | नेपाली | 한국어 (대한민국) | Indonesia | français | español | esperanto | English (United Kingdom) | Deutsch ]
Menentukan pengaturan default dalam kode¶
Catatan
Halaman ini mencoba menjelaskan rencana untuk menetapkan nilai default pengaturan horizon/openstack_dashboard dalam kode. Ini termasuk blueprint ini-based-configuration. Halaman ini akan updated setelah upaya selesai.
Langkah yang Direncanakan¶
Tetapkan nilai default pengaturan yang ada
Tinjau kembali HORIZON_CONFIG
Mengintrodusir
oslo.config
Tetapkan nilai default dari pengaturan yang ada¶
Saat ini semua nilai default didefinisikan dalam kode di mana mereka dikonsumsi. Ini mengarah pada situasi bahwa tidak mudah untuk mengetahui apa nilai default dan dalam kasus yang lebih buruk nilai default yang didefinisikan dalam codebase kami dapat memiliki nilai default yang berbeda.
Sebagai langkah pertama menuju konfigurasi berbasis ini, saya mengusulkan untuk mendefinisikan semua nilai default pengaturan yang ada di satu tempat per modul. Lebih khusus lagi, modul berikut digunakan:
openstack_dashboard.defaults
untuk openstack_dashboardhorizon.defaults
untuk horizonopenstack_auth.defaults
untuk openstack_auth
horizon.defaults
memuat openstack_auth.defaults
dan override pengaturan openstack_auth jika perlu. Demikian pula, openstack_dashboard.defaults
memuat horizon.defaults
dan mengabaikan pengaturan horizon (dan openstack_auth) jika perlu.
Style getattr(settings, <foo>, <default value>)
saat ini akan dihapus pada saat yang bersamaan.
Perhatikan bahwa HORIZON_CONFIG
tidak tersentuh pada langkah ini. Ini akan dibahas pada langkah selanjutnya.
Menangani pengaturan Django¶
Django menyediakan banyak pengaturan dan tidak praktis untuk mencakup semua di horizon. Hanya pengaturan Django yang diatur secara eksplisit oleh horizon akan ditentukan dalam modul python dedicated.
Pertanyaan terbuka adalah bagaimana mempertahankan pengaturan terkait Django di openstack_dashboard dan horizon. Bagaimana kita bisa membuat mereka menjadi bersama? File berikut terkait:
openstack_dashboard.settings (dan local_settings.py)
openstack_dashboard.test.settings
horizon.test.settings
Ini akan dianggap sebagai langkah terakhir dari upaya konfigurasi berbasis ini setelah pengaturan horizon dan openstack_dashboard berhasil dimigrasi ke oslo.config yang dijelaskan di bawah ini.
Tinjau kembali HORIZON_CONFIG¶
HORIZON_CONFIG adalah antarmuka internal sekarang dan sebagian besar (?) Dari mereka tidak boleh diekspos sebagai opsi konfigurasi. Misalnya, mekanisme plugin horizon menyentuh HORIZON_CONFIG untuk mendaftarkan plugin horizon.
Lebih baik untuk mengekspos hanya pengaturan HORIZON_CONFIG yang dapat benar-benar diekspos ke operator. Untuk pengaturan seperti itu, kita harus mendefinisikan pengaturan baru di openstack_dashboard dan dapat mengisinya ke HORIZON_CONFIG di settings.py
.
Misalnya, ajax_poll_interval
di HORIZON_CONFIG dapat diekspos ke operator. Dalam kasus seperti itu, kita dapat menetapkan pengaturan baru AJAX_POLL_INTERVAL
di openstack_dashboard/defaults.py
(atau horizon/defaults.py
).
Investigasi sedang dirangkum dalam an etherpad page.
Mengintroduksi oslo.config¶
local_settings.py akan memiliki prioritas di atas oslo.config. Ini berarti nilai pengaturan dari oslo.config akan dimuat terlebih dahulu dan kemudian local_settings.py
dan local_settings.d
akan dimuat dalam settings.py
.
Strategi dasar pemetaan¶
Konvensi penamaan saat ini adalah acak, sehingga terdengar kurang masuk akal untuk menggunakan nama yang sama untuk oslo.config. Mekanisme konfigurasi ini-based python dan oslo.config menyediakan konsep kategori dan tidak ada alasan untuk menggunakannya. Sebagai nama kategori, kategori Referensi Pengaturan (seperti keystone, glance) akan dikenal.
Misalnya, beberapa pengaturan keystone memiliki awalan
OPENSTACK_KEYSTONE_
seperti OPENSTACK_KEYSTONE_DEFAULT_ROLE. Beberapa menggunakanKEYSTONE_
sepertiKEYSTONE_IDP_PROVIDER_ID
. Beberapa tidak (sepertiENFORCE_PASSWORD_CHECK
). Dalam opsi oslo.config, semua awalan akan dihapus. Pemetaannya adalah:OPENSTACK_KEYSTONE_DEFAULT_ROLE
<->[keystone] default_role
KEYSTONE_IDP_PROVIDER_ID
<->[keystone] idp_provider_id
ENFORCE_PASSWORD_CHECK
<->[keystone] enforce_password_check
Bagian
[default] `` tidak digunakan sebanyak mungkin. Ini hanya akan digunakan untuk sejumlah opsi terkenal yang terbatas. Mungkin beberapa pengaturan Django umum seperti ``DEBUG
,LOGGING
akan cocok dengan kategori ini.Kelas opt yang didefinisikan dalam oslo.config digunakan sebanyak mungkin.
StrOpt, IntOpt
ListOpt
MultiStrOpt
DictOpt
Pengaturan kamus akan dipecah menjadi opsi yang terpisah. Contoh yang baik adalah
OPENSTACK_KEYSTONE_BACKEND
danOPENSTACK_NEUTRON_NETWORK
.OPENSTACK_KEYSTONE_BACKEND['name']
<->[keystone] backend_name
OPENSTACK_KEYSTONE_BACKEND['can_edit_user']
<->[keystone] backend_can_edit_user
OPENSTACK_KEYSTONE_BACKEND['can_edit_group']
<->[keystone] backend_can_edit_group
OPENSTACK_NEUTRON_NETWORK['enable_router']
<->[neutron] enable_router
OPENSTACK_NEUTRON_NETWORK['enable_ipv6']
<->[neutron] enable_ipv6
Pemetaan Otomatis¶
Pendekatan straight-forward adalah memiliki kamus dari pengaturan nama ke opsi oslo.config seperti:
{
'OPENSTACK_KEYSTONE_DEFAULT_ROLE': ('keystone', 'default_role'),
'OPENSTACK_NEUTRON_NETWORK': {
'enable_router': ('neutron', 'enable_router'),
'enable_ipv6': ('neutron', 'enable_ipv6'),
...
}
Kunci dari top-level dict adalah nama pengaturan Django. Nilai yang sesuai menentukan nama oslo.config berdasarkan daftar atau tuple dimana elemen pertama dan kedua menentukan bagian dan nama opsi masing-masing.
Ketika sebuah nilai adalah dict, ini berarti pengaturan dict Django yang sesuai dipecah menjadi beberapa opsi oslo.config. Pada contoh di atas, OPENSTACK_NEUTRON_NETWORK['enable_router']
dipetakan ke [neutron] enable_router
.
Gagasan lain adalah memperkenalkan field baru ke kelas oslo.config. oslo-sample-generator mungkin perlu diperbarui. Jika pendekatan ini benar-benar menarik, kita dapat mencoba pendekatan ini di masa depan. Pendekatan dictionary-based di atas akan digunakan dalam upaya awal.
cfg.StrOpt(
'default_role',
default='member',
django-setting='OPENSTACK_KEYSTONE_DEFAULT_ROLE',
help=...
)
cfg.BoolOpt(
'enable_router',
default=True,
django_setting=('OPENSTACK_NEUTRON_NETWORK', 'enable_router'),
help=....)
)
Pertimbangan Khusus¶
LOGGING¶
Pengaturan LOGGING` cukup panjang. Python sekarang merekomendasikan untuk mengkonfigurasi logging menggunakan python dict secara langsung, tetapi dari perspektif operator/packager gaya lama (legacy style) menggunakan format ini terdengar masuk akal. Format ini juga digunakan dalam proyek OpenStack lainnya juga. Dalam upaya ini, saya mengusulkan untuk menggunakan konfigurasi logging melalui file format ini dan menentukan file conf logging di opsi oslo.config
Mengadopsi oslo.log mungkin kandidat yang baik, tetapi tidak dicakup oleh upaya ini. Ini dapat dieksplorasi sebagai perbaikan di masa depan.
SECURITY_GROUP_RULES¶
SECURITY_GROUP_RULES
akan ditentukan oleh file YAML. File YAML dapat divalidasi oleh skema JSON di masa depan (di luar lingkup upaya ini)
all_tcp
, all_udp
dan all_icmp
adalah kata kunci yang disediakan, sehingga terlihat lebih baik untuk membagi tiga aturan pertama (all_tcp
menjadi all_icmp
) dan aturan lainnya yang tersisa. Aturan yang tersisa akan diambil dari file YAML. Untuk tiga aturan pertama, opsi boolean untuk mengontrol visibilitas mereka di formulir aturan grup keamanan akan diperkenalkan di oslo.config. Saya tidak yakin opsi ini diperlukan atau tidak, tetapi sebagai langkah pertama migrasi, masuk akal untuk menyediakan semua kompatibilitas.
Menangani pengaturan Django¶
Django (dan paket terkait Django) menyediakan banyak pengaturan. Bukan ide yang bagus untuk mengekspos semuanya melalui oslo.config. Apa yang harus kita paparkan?
Proposal di sini adalah untuk mengekspos hanya pengaturan yang openstack_dashboard harapkan untuk mengekspos ke deployer. Sebagian besar pengaturan Django digunakan secara internal di openstack_dashboard/settings.py
. Pengaturan yang diperlukan untuk plugin horizon sudah diekspos melalui pengaturan plugin, jadi tidak perlu memaparkannya. Jika deployer ingin mengkustomisasi pengaturan dasar Django, mereka masih dapat mengkonfigurasinya melalui local_settings.py
atau local_settings.d
.