PTG (تجمع فريق المشروع) هو حدث تلتقي فيه فرق التطوير لمناقشة المهام والحالات والخطط الحالية. انبثقت PTG عن قمة OpenStack السائدة قبل بضع سنوات.
تم عقد PTG لأول مرة عبر الإنترنت من خلال Zoom و Jitsi Meet. ومع ذلك ، فإن الجمع بين الصورة والصوت في الاجتماع جعل هذا التغيير غير ملحوظ تمامًا ، خاصة على خلفية اجتماعات الفريق المعتادة الآن عبر IRC.
استمرت جلسات النيوترون لمدة ثلاث ساعات من الثلاثاء إلى الجمعة. يتم نشر محضر الاجتماع الرئيسي على OpenStack Etherpad وعلى القائمة البريدية لـ OpenStack. تم تشكيل جدول أعمال الحدث بناءً على مقترحات مطوري Neutron ، وتم إعداد جدول الاجتماع من قبل رئيسه PTL (قائد فريق المشروع) لفريق Neutron Slawek Kaplonski.
في هذا المقال سأتحدث عن 3 مواضيع أعتقد أنها تستحق الاهتمام ، وتتطلب القليل من الشرح.
OVN
كان هناك الكثير من الحديث حول OVN على PTG هذا ، وهذا ليس مفاجئًا لأن معظم أعضاء الفريق الأساسي يمثلون RedHat ، المساهم الرئيسي في OVN.
ما هو OVN؟
- المحاكاة الافتراضية لشبكة L2 / L3 مفتوحة المصدر لـ Open vSwitch (OVS):
- مفاتيح المنطق
- أجهزة التوجيه المنطقية IPv4 و IPv6
- L2 / L3 / L4 ACLs (مجموعات الأمان)
- تراكبات أنفاق متعددة (Geneve و STT و VXLAN)
- موازنات الحمل المنطقي
- بوابات L2 المنطقية الفيزيائية القائمة على TOR
- بوابات L2 / L3 المنطقية القائمة على البرامج
- يعمل على نفس منصات OVS:
- لينكس
- حاويات
- DPDK
- التكامل مع:
- أوبن ستاك نيوترون
- سرب عامل الميناء
- كوبرنيتيس
هندسة OVN
“OVN في 75 كلمة.
يتم تشغيل الشبكة الافتراضية المفتوحة بواسطة مشروع OVS وتطويرها بواسطة فريق OVS الأصلي. هذا القرار هو محاولة لإعادة تصميم مستوى التحكم ML2 / OVS على أساس سنوات من الخبرة. إنه مخصص للاستخدام مع OpenStack و Kubernetes. تم بناء OVN على بنية جديدة تخلت عن مفهوم وكلاء Python الذين يتفاعلون مع خدمة Neutron API عبر RabbitMQ لصالح C daemons التي تتواصل عبر OpenFlow و OVSDB. " - Slawek Kaplonsky ، نيوترون PTL.
في البداية ، تم تطوير برنامج تشغيل Neutron OVN كمشروع منفصل في استاد Neutron - شبكات - ovn ، وفي الإصدار ، تم تضمين Ussuri في مستودع Neutron الرئيسي.
وبالتالي ، فإن هذا الحل يلغي المشكلة الرئيسية لـ ML2 / OVS - RabbitMQ ، وهي ميزة إضافية لا شك فيها ، وبشكل عام "هدف تصميم OVN هو الحصول على تنفيذ بجودة الإنتاج يمكن أن يعمل على نطاق واسع". ومع ذلك ، هل يدعم OVN الوظائف المتاحة عند استخدام ML2 / OVS؟ يبدو أن هذا ليس صحيحًا تمامًا ، والذي أصبح أحد موضوعات المناقشة على PTG. نتيجة لذلك ، تم تسليط الضوء على العديد من الفجوات (تتوفر قائمة كاملة في صفحة المشروع). بادئ ذي بدء ، لاحظ المطورون غياب أو عدم اكتمال الدعم للشبكات الموجهة ، وبعض ميزات جودة الخدمة ، و BGP ومناطق التوافر. على الرغم من أن فريق OVN مستعد للقيام بكل ما سبق ، فقد أقروا خلال الاجتماع بأن هذا لم يكن أولوية بالنسبة لهم في السابق - لأن المصالح الداخلية كانت أكثر أهمية. بالإضافة إلى ذلك ، فإن تطوير ML2 / OVS ، بالطبع ،لا يتوقف ، مما يعني أنه قد تظهر مسافات جديدة.
ومع ذلك ، في رأيي ، فإن المشكلة الرئيسية في OVN هي أنه لم يتم استخدامه على نطاق واسع حتى الآن ولم يتم اختباره على المنشآت الكبيرة. بالإضافة إلى ذلك ، هناك بعض الأسئلة حول الإتاحة العالية:
- أحد المكونات الرئيسية ، ovn-northd ، يدعم حاليًا فقط وضع HA النشط / السلبي ، نشط / نشط لا يزال في الخطط فقط
- عنصر مركزي آخر ، ovsdb-server ، يدعم فقط الوضع النشط / الخامل
من المحتمل أن تكون النقطة الأخيرة قديمة بالفعل ، حيث تمت إضافة دعم مجموعة ovsdb (استنادًا إلى خوارزمية Raft) منذ OVS 2.9 ، ولكن ليس من الواضح ما إذا كان قد تم اختبار ذلك في الإصدار باستخدام OVN و OpenStack. على سبيل المثال ، لم يتم إغلاق التذكرة المرتبطة في Openstack-ansible بعد.
ومما يثير القلق أيضًا أن OVN تستخدم أنفاق Geneve بدلاً من شبكات VxLAN ، مما يؤثر على إعدادات MTU (رؤوس Geneve أكبر من VxLANs) ودعم معالجة النفق المسرع للأجهزة.
مهما كان الأمر ، فإن المشروع يكتسب زخمًا سريعًا ويبدو أنه في بعض الإصدارات ، يجب أن يصبح OVN مكونًا إضافيًا أساسيًا للنيوترون. علاوة على ذلك ، خلال PTG ، وافق مطورو الفريق الأساسي على جعل OVN هو المكون الإضافي الافتراضي لـ DevStack.
إلى أين ستؤدي هذه التغييرات:
- OpenStack Neutron CI,
- ML2/OVS ( )
- Neutron CI , ML2/Linuxbridge ML2/OVS – ,
- , core OVN
فيما يتعلق بالنقطة الأخيرة ، نشرت Neutron PTL الرسالة التالية: "يعتقد فريق Neutron أن OVN ومحرك Neutron OVN مبنيان على بنية حديثة توفر أساسًا أفضل لحل أبسط وأكثر كفاءة. نحن نشهد زيادة في المشاركة في kubernetes-ovn ، مما يؤدي إلى توسيع مجتمع OVN الأساسي ، ونود أن يستفيد OpenStack من هذا الاستثمار في OVN من Kubernetes أيضًا.
في الوقت الحالي ، يحتوي برنامج تشغيل Neutron OVN على فجوات في الوظائف المدعومة مقارنةً بـ ML2 / OVS ، ومع ذلك ، يحاول فريقنا سد هذه الفجوات ، ونعتقد أن هذا المحرك سيكون مستقبل Neutron ، وبالتالي نريد أن نجعله الواجهة الخلفية الافتراضية لـ Neutron ML2 DevStack ".
حتى الآن ، كان رد الفعل على هذه الأخبار إيجابيًا إلى حد ما ، على الرغم من أنه لا تزال هناك شكوك حول الانتقال من أنفاق VxLAN إلى Geneve ، وطرق الانتقال من ML2 OVS إلى ML2 OVN ، بالإضافة إلى الأداء والوظائف المدعومة.
تطبيق EngineFacade الجديد
EngineFacade هو إطار عمل فوق sqlalchemy يدمج منطق قاعدة البيانات المستخدم في جميع مشاريع OpenStack. منذ عدة إصدارات ، خضعت لإعادة بناء ديون ، مما أدى إلى ظهور ما يسمى بـ "واجهة المحرك الجديدة". كانت الخطوة التالية هي تكييف هذا الإطار مع OpenStack.
في رأيي ، تم تضمين هذا الموضوع في جدول أعمال PTG نظرًا لحقيقة أن العمل عليه كان يتأخر لعدة إصدارات ولم يكتمل بعد. أسباب هذا التطور للأحداث هي كمية كبيرة من التغييرات الضرورية ، بعض المشاكل غير التافهة في عملية التكيف ، وكما يبدو لي ، الافتقار إلى الحافز ، وبالتالي نقص الموارد البشرية. في الواقع ، لماذا نغير شيئًا يعمل بالفعل ولا يعطي حتى مجموعة من الأخطاء؟ تم تحديد إجابة مفصلة إلى حد ما على هذا السؤال في مواصفات مايك باير. سأحاول هنا تقديم ملخص موجز للاعتبارات الداعمة لـ EngineFacade حتى لا تضطر إلى قراءة هذا النص الطويل:
- يوفر EngineFacade القديم واجهات برمجة تطبيقات منخفضة المستوى بدلاً من واجهات برمجة التطبيقات عالية المستوى المصممة لحالة استخدام معينة ، لذلك يعد هذا في الأساس مصنعًا وليس واجهة. كنتيجة ل:
- EngineFacade OpenStack
- , ,
- EngineFacade // : reader writer, , .
يبدو الأمر بسيطًا ومنطقيًا ، فما هي مشكلة تكيف EngineFacade؟ لأكون صادقًا ، لم أخوض في التفاصيل كثيرًا ، ولكن يبدو أن السبب الرئيسي للمشكلات هو أنه في بعض السيناريوهات المعقدة ، تم إساءة استخدام EngineFacade القديم في Neutron وعمل (!) ، و EngineFacade الجديد يحاول فعل كل شيء بشكل صحيح ، ولكن ومع ذلك ، فإنه يكسر نصوص العمل (في رأيي ، مشكلة نموذجية إلى حد ما عند العمل مع رمز قديم). من الواضح ، في هذه الحالة ، يجب عليك أولاً تصحيح منطق هذه النصوص.
في الواقع ، لم يتبق الكثير لتحريره - فقط تصحيح واحد ، ووافق الفريق الأساسي على حل هذه المشكلة بشكل مشترك. بالطبع ، يمكن لأي شخص مهتم المساعدة في التحليل والمراجعة!
نيوترون ليب
تم تخصيص العديد من الموضوعات لـ neutron-lib. بادئ ذي بدء ، اسمحوا لي أن أذكركم بما هو الحال بالنسبة لأولئك الذين لا يشاركون بشكل كبير في تطوير النيوترون. أولاً ، نيوترون ليس مشروعًا واحدًا - في الواقع ، إنه يتكون من عدة مستودعات تعمل في مناطق مختلفة من شبكة OpenStack تحت الاسم العام Neutron Stadium ، و "neutron" هو واحد فقط ، وإن كان مشروعًا كبيرًا. باقي المشاريع هي ما يسمى بالخدمات المتقدمة (على سبيل المثال ، neutron-lbaas ، -fwaas ، -vpnaas ، -dynamic-routing ، إلخ.) والمكونات الإضافية للمورد / الطرف الثالث (على سبيل المثال network-midonet ، -odl ، -ovn). تتضمن هذه القائمة المشاريع التي تم تطويرها بواسطة Neutron PTL والفريق الأساسي والتي تشارك بشكل مباشر فيها على أساس يومي. ولتحقيق ذلك ، فإنهم يضمنون اتباع المبادئ العامة وقواعد العمل في جميع أنحاء الاستاد في جميع جوانب التطوير - الهيكل ،التطوير ، نمط الكود ، الاختبار ، التوثيق ، إلخ. لنكون صادقين ، هذا ليس صحيحًا تمامًا اليوم ، ولا يزال العبء الرئيسي يقع على كاهل المشرفين على المشروع.
قبل إنشاء neutron-lib ، استوردت جميع مشاريع الشبكات جميع الكود المشترك - الثوابت والواجهات (فئات القاعدة المجردة) والوظائف المساعدة والمزيد - من المستودع الرئيسي للنيوترون. أي تغييرات على مثل هذا الرمز في النيوترون يمكن أن تكسر المشاريع التابعة. بعد ذلك ، في إصدار Ocata ، تم إطلاق مبادرة neutron-lib لحل هذه المشكلة: يجب الآن تخزين جميع الرموز الشائعة في مستودع منفصل ويجب إصدارها. وبشكل أكثر تحديدًا ، تمت صياغة الأهداف على النحو التالي:
- إزالة تبعية المشاريع الفرعية من نيوترون (أي إزالة الواردات المباشرة من النيوترون في المشاريع الفرعية)
- قم بأداء واجبك في Neutron عن طريق إعادة بناء الكود أو إعادة تصميم بنية النمط دون المستوى الأمثل في أقسام النيوترون-ليب المناسبة
في الواقع ، يبدو أن neutron-lib خيارًا مربحًا للجانبين: يجب أن يكون كل من النيوترون الرئيسي وخدمات مشاريع الطرف الثالث باللون الأسود نتيجة لذلك. ماذا حصل؟
نقص بالدعم
لا يمكن أن يوجد مشروع مفتوح المصدر بدون دعم المساهمين والمشرفين - الأشخاص المستعدين لاستثمار وقتهم في العمل في المشروع. بالنسبة إلى neutron-lib ، كان هناك نقص في هؤلاء المتطوعين ، ونتيجة لذلك توقف المنطق الأصلي عن العمل ، أي بحيث يتم تخزين جميع الشفرات الشائعة هنا والتي يمكن استيرادها بدلاً من استيراد النيوترون. غادر المشرف الرئيسي neutron-lib (boden) المشروع منذ بعض الوقت. خلال PTG ، تم تقديم اقتراح للتخلي عن فكرة نقل كل الكود المشترك إلى neutron-lib ، أو حتى نقل كود neutron-lib إلى نيوترون. لم يتم تمرير هذا الاقتراح لسببين:
- لا يزال النيوترون-ليب مستخدمًا على نطاق واسع
- يحمل neutron-lib بعض القيمة لأنه يسلط الضوء على الواجهات القياسية التي لا يمكن تغييرها حتى لا تنكسر عدة مشاريع في وقت واحد
بعد المناقشة ، يظل neutron-lib دون تغيير ، لكن سياسة نقل رمز النيوترون وإيقافه بحاجة إلى التحديث.
بالطبع ، يجب مشاركة كل الكود الجديد بين نيوترون ونيوترون ليب ، إن أمكن. وهذا يقودنا إلى المشكلة الثانية.
مشكلة الاختبار
قضية أخرى تتعلق بالاختبار أثناء التطوير. إذا أدخل جزء من رقعة في النيوترون رمزًا مشتركًا جديدًا أو يغير الكود المشترك الحالي ، فيجب إرساله إلى neutron-lib بواسطة القواعد. هذا يجعل الجزء النيوتروني من الرقعة يعتمد على هذه التغيرات الليبية. ومع ذلك ، يتم حاليًا اختبار تصحيحات النيوترونات على نسخة الإصدار من neutron-lib للتحقق من أنها تعمل مع أحدث إصدار. نتيجة لذلك ، لن تجتاز هذه البقع الاختبارات في CI.
الذهاب إلى اختبار جميع بقع النيوترون مع رمز نيوتروني ليب من المعالج له أيضًا بعض العيوب. على سبيل المثال ، ليس هناك ما يضمن أن معالج النيوترون سيعمل مع أحدث إصدار من النيوترونات ، وهو ما يستخدمه المستخدمون النهائيون.
فيما يلي طرق معالجة هذه المشكلة (بفضل Bence Romsics على الملخص الممتاز):
- , , neutron-lib , neutron .
- , :
- , “foo” neutron-lib, . neutron , “_foo” TODO , , neutron-lib.
- neutron-lib , neutron, _foo “import _foo” “from neutron-lib import foo”.
- بالإضافة إلى ذلك ، يمكنك إجراء فحوصات منفصلة على CI باستخدام كل من المعالج وأحدث إصدار من neutron-lib. لكن واحد منهم فقط يمكنه التصويت. ستؤدي مضاعفة عدد المهام ببساطة إلى وضع عبء إضافي كبير على البنية التحتية لـ OpenStack CI.
تم تقديم ثلاثة اقتراحات خلال مناقشة PTG:
- استخدام معالج نيوترون ليب من أجل "فحص CI" ؛ استخدم نسخة الإصدار neutron-lib لـ "Gate CI" - ومع ذلك ، إذا اجتازت رقعة النيوترون فحوصات "Check CI" وتعطلت في "Gate CI" ، فسيبدو الأمر غريبًا
- لا تغير أي شيء: من الأفضل إجراء اختبارات على نسخة إصدار نيوترون ليب. على سبيل المثال ، يتم ذلك الآن لـ OSC (OpenStackClient)
- قم بتشغيل الاختبارات باستخدام معالج neutron-lib وإضافة مهمة دورية للاختبارات باستخدام إصدار neutron-lib
الحل النهائي: قم بإنشاء قضية جديدة غير متعلقة بالتصويت في "Check CI" باستخدام neutron-lib من الفرع الرئيسي. بشكل أساسي ، يبقى كل شيء كما هو ، ولكن سيكون من الممكن التحقق من أن الميزة التي تتضمن تغييرات في النيوترون والنيوترون-ليب تمر عبر CI قبل إرسالها إلى الفرع الرئيسي.
آمل أن تكون هذه المقالة مفيدة وساعدتك على فهم أفضل لمكان ولماذا يتجه نيوترون.
شكرآ لك على أهتمامك!