/सिगरेट नोड
/ तरह की सुविधा
सीसी @ConnorDoyle @balajismaniam @nolancon

मैं बोर्ग से सीखने के आधार पर इस डिजाइन को सूचित करने में मदद कर सकता हूं। तो मुझे एक समीक्षक/अनुमोदक के रूप में गिनें।

मैं बोर्ग से सीखने के आधार पर इस डिजाइन को सूचित करने में मदद कर सकता हूं। तो मुझे एक समीक्षक/अनुमोदक के रूप में गिनें।

क्या यह सुविधा बोर्ग में कैसे काम करती है, इस पर कोई सार्वजनिक दस्तावेज है?

NUMA AFAIK के बारे में नहीं।

सोम को, फरवरी 11, 2019, सुबह 7:50 बजे जेरेमी एडर < नोटिफिकेशन @github.com ने लिखा:

मैं बोर्ग से सीखने के आधार पर इस डिजाइन को सूचित करने में मदद कर सकता हूं। तो मुझे गिनें
एक समीक्षक/अनुमोदक के रूप में।

क्या यह सुविधा बोर्ग में कैसे काम करती है, इस पर कोई सार्वजनिक दस्तावेज है?

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/kubernetes/enhancements/issues/693#issuecomment-462378195 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AGvIKPfanjb9Q5DxXAiBgv9C6Y809JX0ks5vMZFZgaJpZM4aE3uz
.

FYI करें @claurence

इस ट्रैकिंग समस्या और KEP (https://github.com/kubernetes/enhancements/pull/781) ने इसे v1.14 एन्हांसमेंट फ़्रीज़ और न ही विस्तारित समय सीमा के लिए समय पर नहीं बनाया। मैं सराहना करता हूं कि आपने समय सीमा से पहले इन्हें खोल दिया, लेकिन ऐसा लगता है कि उन्हें पर्याप्त समीक्षा या साइन ऑफ नहीं मिला। इसे अपवाद प्रक्रिया से गुजरना होगा।

जब तक हम यह तय नहीं कर लेते कि क्या यह अपवाद के लायक है, मैं इस वृद्धि से जुड़े सभी पीआर पर पकड़ बनाने के लिए इच्छुक हूं।

रेफरी: https://github.com/kubernetes/kubernetes/issues/72828

/सीसी @jiayingz @dchen1107

@lmdaly मैं देख रहा हूं कि आपके पास 1.14 अल्फा मील के पत्थर के रूप में विवरण में सूचीबद्ध हैं - चूंकि एक विलय लागू करने योग्य केईपी नहीं था, इस मुद्दे को 1.14 के लिए ट्रैक नहीं किया जा रहा है - अगर उस रिलीज में इसे शामिल करने के इरादे हैं तो कृपया एक अपवाद अनुरोध सबमिट करें।

@lmdaly मैं देख रहा हूं कि आपके पास 1.14 अल्फा मील के पत्थर के रूप में विवरण में सूचीबद्ध हैं - चूंकि एक विलय लागू करने योग्य केईपी नहीं था, इस मुद्दे को 1.14 के लिए ट्रैक नहीं किया जा रहा है - अगर उस रिलीज में इसे शामिल करने के इरादे हैं तो कृपया एक अपवाद अनुरोध सबमिट करें।

@claurence केईपी अब विलय कर दिया गया है (

डिजाइन और डब्ल्यूआईपी पीआरएस को पूरी तरह से पढ़ने के बाद, मुझे चिंता है कि वर्तमान कार्यान्वयन सामान्य नहीं है क्योंकि मूल टोपोलॉजी डिजाइन हमने https://github.com/kubernetes/enhancements/pull/781 में प्रस्तावित किया था

मैंने आगे की चर्चा के लिए यहां कुछ टिप्पणियां छोड़ी हैं: https://github.com/kubernetes/kubernetes/pull/74345#discussion_r264387724

वर्तमान कार्यान्वयन सामान्य नहीं है

उसके बारे में समान चिंता साझा करें :) दूसरों के बारे में कैसे, जैसे डिवाइस के बीच लिंक (GPU के लिए nvlinke)?

@resouer @ k82cn प्रारंभिक प्रस्ताव केवल सीपीयू प्रबंधक और डिवाइस प्रबंधक द्वारा किए गए निर्णयों को संरेखित करने के साथ संबंधित है ताकि यह सुनिश्चित किया जा सके कि सीपीयू के साथ उपकरणों की निकटता सुनिश्चित हो। इंटर-डिवाइस एफ़िनिटी को संतुष्ट करना प्रस्ताव का एक गैर-लक्ष्य था।

हालांकि, यदि वर्तमान कार्यान्वयन भविष्य में इंटर-डिवाइस आत्मीयता को जोड़ने से रोक रहा है, तो मुझे यह समझने में खुशी होगी कि यह कैसे कर रहा है, मुझे कार्यान्वयन को बदलने में खुशी हो रही है,

मुझे लगता है कि मैं वर्तमान कार्यान्वयन और इंटर-डिवाइस एफ़िनिटी का समर्थन करने की क्षमता के साथ मुख्य मुद्दा देख रहा हूं:

इंटर-डिवाइस एफ़िनिटी का समर्थन करने के लिए आपको आम तौर पर पहले यह पता लगाना होगा कि आप कौन से डिवाइस कंटेनर को आवंटित करना चाहते हैं _before_ यह तय करना कि आप किस सॉकेट एफ़िनिटी को कंटेनर रखना चाहते हैं।

उदाहरण के लिए, एनवीडिया जीपीयू के साथ, इष्टतम कनेक्टिविटी के लिए, आपको सबसे पहले सबसे कनेक्टेड एनवीलिंक्स के साथ जीपीयू के सेट को खोजने और आवंटित करने की आवश्यकता है _before_ यह निर्धारित करने के लिए कि उस सेट में कौन सी सॉकेट एफ़िनिटी है।

वर्तमान प्रस्ताव में मैं जो बता सकता हूं, उससे यह धारणा है कि ये ऑपरेशन रिवर्स ऑर्डर में होते हैं, यानी उपकरणों के आवंटन को करने से पहले सॉकेट एफ़िनिटी तय की जाती है।

यह जरूरी नहीं कि सच हो @klueska। यदि टोपोलॉजी संकेत पॉइंट-टू-पॉइंट डिवाइस टोपोलॉजी को एन्कोड करने के लिए बढ़ाए गए थे, तो डिवाइस मैनेजर सॉकेट एफ़िनिटी की रिपोर्ट करते समय इस पर विचार कर सकता था। दूसरे शब्दों में, क्रॉस डिवाइस टोपोलॉजी को डिवाइस मैनेजर के दायरे से बाहर लीक करने की आवश्यकता नहीं होगी। क्या यह संभव लगता है?

शायद मैं किसी तरह प्रवाह के बारे में उलझन में हूँ। मैं इसे इस तरह समझता हूं:

1) इनिशियलाइज़ेशन के समय, डिवाइस प्लगइन्स (न कि devicemanager ) खुद को topologymanager साथ पंजीकृत करते हैं ताकि यह बाद में उस पर कॉलबैक जारी कर सके।

2) जब एक पॉड सबमिट किया जाता है तो क्यूबलेट lifecycle.PodAdmitHandler पर topologymanager पर कॉल करता है।

3) lifecycle.PodAdmitHandler प्रत्येक पंजीकृत डिवाइस प्लगइन पर GetTopologyHints कॉल करता है

4) इसके बाद यह इन संकेतों को मिला कर पॉड से जुड़ा एक समेकित TopologyHint करता है

5) यदि उसने पॉड को स्वीकार करने का निर्णय लिया है, तो यह स्थानीय राज्य स्टोर में पॉड के लिए समेकित TopologyHint को संग्रहीत करते हुए lifecycle.PodAdmitHandler से सफलतापूर्वक लौटता है

6) भविष्य में किसी बिंदु पर, cpumanager और devicemanager GetAffinity(pod) को topology प्रबंधक पर TopologyHint संबंधित

7) cpumanager CPU आवंटित करने के लिए इस TopologyHint` का उपयोग करता है

8) devicemanager उपकरणों का एक सेट आवंटित करने के लिए इस TopologyHint` का उपयोग करता है

9) पॉड का प्रारंभ जारी है...

यदि यह सही है, तो मुझे लगता है कि मैं उस समय के बीच संघर्ष कर रहा हूं जब डिवाइस प्लगइन इसकी TopologyHints रिपोर्ट करता है और वह समय जब devicemanager वास्तविक आवंटन करता है।

यदि ये संकेत आवंटन के लिए "वरीयताओं" को एन्कोड करने के लिए हैं, तो मुझे लगता है कि आप जो कह रहे हैं वह संरचना अधिक है:

type TopologyHints struct {
    hints []struct {
        SocketID int
        DeviceIDs []int
    }
}

जहां हम न केवल सॉकेट एफ़िनिटी प्राथमिकताओं की एक सूची पास करते हैं, बल्कि उन सॉकेट एफ़िनिटी प्राथमिकताओं को कैसे आवंटित करने योग्य GPU प्राथमिकताओं के साथ जोड़ते हैं।

यदि आप इस दिशा में सोच रहे हैं, तो मुझे लगता है कि हम इसे काम कर सकते हैं, लेकिन हमें किसी तरह cpumanager और devicemanager बीच समन्वय करना होगा ताकि यह सुनिश्चित हो सके कि उन्होंने इसे "स्वीकार" किया है। उनका आवंटन करते समय संकेत दें।

क्या ऐसा कुछ है जो इसे पहले से ही छूट देता है?

@klueska

मुझे लगता है कि क्या होता है, आपके प्रवाह में कुछ _minor_ सुधार करना है:

1. इनिशियलाइज़ेशन के समय, डिवाइस प्लगइन्स खुद को devicemanager साथ पंजीकृत करते हैं ताकि यह बाद में उस पर कॉलबैक जारी कर सके।

2. क्यूबलेट में प्रत्येक टोपोलॉजी-जागरूक घटक पर lifecycle.PodAdmitHandler कॉल GetTopologyHints , वर्तमान में devicemanager और cpumanager ।

इस मामले में, क्यूबलेट में टोपोलॉजी-जागरूक के रूप में प्रतिनिधित्व किया जाएगा cpumanager और devicemanager । टोपोलॉजी प्रबंधक का उद्देश्य केवल टोपोलॉजी-जागरूक घटकों के बीच आवंटन का समन्वय करना है।

इसके लिए:

लेकिन हमें यह सुनिश्चित करने के लिए cpumanager और devicemanager के बीच किसी तरह समन्वय स्थापित करने की आवश्यकता होगी कि वे अपना आवंटन करते समय उसी संकेत को "स्वीकार" करते हैं।

यह वही है जिसे हासिल करने के लिए topologymanager खुद पेश किया गया था। पहले के मसौदों में से एक से,

क्रॉस NUMA असाइनमेंट से बचने के लिए इन घटकों को समन्वयित करना चाहिए। इस समन्वय से संबंधित समस्याएं पेचीदा हैं; क्रॉस डोमेन अनुरोध जैसे "असाइन किए गए एनआईसी के समान NUMA नोड पर एक विशेष कोर" में सीएनआई और सीपीयू प्रबंधक दोनों शामिल हैं। यदि CPU प्रबंधक पहले चयन करता है, तो वह NUMA नोड पर एक उपलब्ध NIC के बिना एक कोर का चयन कर सकता है और इसके विपरीत।

समझा।

तो devicemanager और cpumanager दोनों GetTopologyHints() को लागू करते हैं और साथ ही GetAffinity() कॉल करते हैं, किसी भी अंतर्निहित डिवाइस प्लगइन्स के साथ topologymanager से दिशा बातचीत से परहेज करते हैं . कोड को और अधिक बारीकी से देखने पर, मैं देखता हूं कि devicemanager केवल TopologyHints भरने में मदद करने के लिए प्लगइन्स को नियंत्रण सौंपता है, जो अंत में वैसे भी अधिक समझ में आता है।

हालांकि मैंने उठाए गए मूल प्रश्न/मुद्दे पर वापस जाना ....

एनवीडिया के दृष्टिकोण से, मुझे लगता है कि हम इस प्रस्तावित प्रवाह के साथ सब कुछ काम कर सकते हैं, यह मानते हुए कि भविष्य में पॉइंट-टू-पॉइंट लिंक जानकारी की रिपोर्ट करने के लिए TopologyHints संरचना (और परिणामस्वरूप डिवाइस प्लगइन इंटरफ़ेस) में अधिक जानकारी जोड़ी गई है। .

हालांकि, मैं एक साथ शुरू लगता है कि SocketMask विज्ञापन सॉकेट आत्मीयता के लिए प्राथमिक डेटा संरचना के रूप में विस्तार करने की हमारी क्षमता को सीमित कर सकता TopologyHints मौजूदा इंटरफेस को तोड़ने के बिना भविष्य में साथ बिंदु से बिंदु जानकारी। प्राथमिक कारण यह है कि (कम से कम एनवीडिया जीपीयू के मामले में) पसंदीदा सॉकेट इस बात पर निर्भर करता है कि अंत में कौन से जीपीयू वास्तव में आवंटित किए जाने वाले हैं।

उदाहरण के लिए, इष्टतम कनेक्टिविटी वाले पॉड को 2 GPU आवंटित करने का प्रयास करते समय, नीचे दिए गए चित्र पर विचार करें:

(2, 3) और (6, 7) दोनों के GPU संयोजनों में 2 NVLINK हैं और एक ही PCIe बस में रहते हैं। इसलिए पॉड को 2 GPU आवंटित करने का प्रयास करते समय उन्हें समान उम्मीदवार माना जाना चाहिए। किस संयोजन के आधार पर चुना जाता है, हालांकि, एक अलग सॉकेट स्पष्ट रूप से पसंद किया जाएगा क्योंकि (2, 3) सॉकेट 0 से जुड़ा है और (6, 7) सॉकेट 1 से जुड़ा है।

इस जानकारी को किसी भी तरह TopologyHints संरचना में एन्कोड करने की आवश्यकता होगी ताकि devicemanager अंत में इन वांछित आवंटनों में से एक को निष्पादित कर सके (यानी जो भी topologymanager संकेतों को समेकित करता है नीचे तक)। इसी तरह, पसंदीदा डिवाइस आवंटन और पसंदीदा सॉकेट के बीच निर्भरता को TopologyHints में एन्कोड करने की आवश्यकता होगी ताकि cpumanager सही सॉकेट से सीपीयू आवंटित कर सके।

इस उदाहरण के लिए एनवीडिया जीपीयू के लिए विशिष्ट एक संभावित समाधान कुछ ऐसा दिखाई देगा:

type TopologyHint struct {
    SocketID int
    DeviceIDs []int
}

type TopologyHints []TopologyHint

devicemanagerhints := &TopologyHints{
    {SocketID: 0, DeviceIDs: []int{2, 3}},
    {SocketID: 1, DeviceIDs: []int{6, 7}},
}

cpumanagerhints := &TopologyHints{
    {SocketID: 1},
}

जहां topologymanager इन संकेतों को {SocketID: 1, DeviceIDs: []int{6, 7}} को पसंदीदा संकेत के रूप में वापस करने के लिए समेकित करेगा जब devicemanager और cpumanager बाद में GetAffinity() कॉल करें।

हालांकि यह सभी त्वरक के लिए एक सामान्य पर्याप्त समाधान प्रदान कर सकता है या नहीं भी कर सकता है, SocketMask को TopologyHints संरचना में बदलकर कुछ और संरचित के साथ निम्नलिखित की तरह हमें प्रत्येक व्यक्तिगत संकेत को और अधिक फ़ील्ड के साथ विस्तारित करने की अनुमति देगा भविष्य:

ध्यान दें कि GetTopologyHints() अब भी वापसी TopologyHints , जबकि GetAffinity() एक भी वापस जाने के लिए संशोधित किया गया है TopologyHint बजाय TopologyHints ।

type TopologyHint struct {
    SocketID int
}

type TopologyHints []TopologyHint

&TopologyHints{
    {SocketID: 0},
    {SocketID: 1},
}

type HintProvider interface {
    GetTopologyHints(pod v1.Pod, container v1.Container) TopologyHints
}

type Store interface {
    GetAffinity(podUID string, containerName string) TopologyHint
}

विचार?

@klueska शायद मुझे कुछ याद आ रहा है, लेकिन मुझे एनवी लिंक जीपीयू के लिए डिवाइस आईडी की आवश्यकता नहीं है जो टोपोलॉजी मैनेजर तक पॉप्युलेट हो।

यदि डिवाइस प्लगिन एपीआई को @ConnorDoyle के सुझाव के

आपके उदाहरण में devicemanagerhints वह जानकारी हो सकती है जिसे डिवाइस प्लग इन ने डिवाइसमैनेजर को वापस भेजा था। डिवाइस मैनेजर फिर सॉकेट की जानकारी को टोपोलॉजीमैनेजर को वापस भेजता है जैसा कि अभी है और टोपोलॉजीमैनेजर चुने हुए सॉकेट हिंट को स्टोर करता है।

आवंटन पर, डिवाइस प्रबंधक वांछित सॉकेट आवंटन प्राप्त करने के लिए GetAffinity को कॉल करता है (मान लें कि इस मामले में सॉकेट 1 है), इस जानकारी का उपयोग करके और डिवाइस प्लगइन द्वारा वापस भेजी गई जानकारी का उपयोग करके, यह देख सकता है कि सॉकेट 1 पर इसे डिवाइस असाइन करना चाहिए ( 6,7) क्योंकि वे NV लिंक डिवाइस हैं।

क्या इसका कोई मतलब है या क्या कुछ ऐसा है जो मुझे याद आ रहा है?

मेरे साथ इसे स्पष्ट करने के लिए समय निकालने के लिए धन्यवाद। मैंने @ConnorDoyle के मूल सुझाव की गलत व्याख्या की

यदि टोपोलॉजी संकेत पॉइंट-टू-पॉइंट डिवाइस टोपोलॉजी को एन्कोड करने के लिए बढ़ाए गए थे, तो डिवाइस मैनेजर सॉकेट एफ़िनिटी की रिपोर्ट करते समय इस पर विचार कर सकता था।

मैंने इसे सीधे बिंदु-से-बिंदु जानकारी के साथ TopologyHints संरचना का विस्तार करने के रूप में पढ़ा।

ऐसा लगता है कि आप यह सुझाव दे रहे हैं कि devicemanager को पॉइंट-टू-पॉइंट जानकारी प्रदान करने के लिए केवल डिवाइस प्लगइन एपीआई को विस्तारित करने की आवश्यकता है, ताकि यह इस जानकारी का उपयोग SocketMask को सूचित करने के लिए कर सके। TopologyHints संरचना में सेट करने के लिए जब भी GetTopologyHints() कहा जाता है।

मुझे लगता है कि यह तब तक काम करेगा, जब तक कि डिवाइस प्लगइन के एपीआई एक्सटेंशन हमें उपरोक्त मेरे उदाहरण में उल्लिखित जानकारी के समान जानकारी देने के लिए डिज़ाइन किए गए हैं और devicemanager को पॉड प्रवेश और डिवाइस के बीच इस जानकारी को संग्रहीत करने के लिए बढ़ाया गया है। आवंटन समय।

अभी हमारे पास एनवीडिया में एक कस्टम समाधान है जो हमारे kubelet को अनिवार्य रूप से वही करने के लिए पैच करता है जो आप सुझाव दे रहे हैं (सिवाय इसके कि हम डिवाइस प्लगइन्स के लिए कोई निर्णय नहीं लेते हैं - devicemanager GPU को जागरूक किया गया है और टोपोलॉजी-आधारित GPU आवंटन निर्णय स्वयं लेता है)।

हम केवल यह सुनिश्चित करना चाहते हैं कि जो भी दीर्घकालिक समाधान किया गया है वह हमें भविष्य में इन कस्टम पैच को हटाने की अनुमति देगा। और अब जब मेरे पास इस बात की बेहतर तस्वीर है कि यहां प्रवाह कैसे काम करता है, तो मुझे ऐसा कुछ भी नहीं दिखता जो हमें अवरुद्ध करे।

सब कुछ स्पष्ट करने के लिए समय निकालने के लिए फिर से धन्यवाद।

नमस्ते @lmdaly , मैं 1.15 के लिए एन्हांसमेंट लीड हूं। क्या यह सुविधा 1.15 में अल्फा/बीटा/स्थिर चरणों में स्नातक होने जा रही है? कृपया मुझे बताएं ताकि इसे ठीक से ट्रैक किया जा सके और स्प्रेडशीट में जोड़ा जा सके।

एक बार कोडिंग शुरू हो जाने पर, कृपया इस मुद्दे में सभी प्रासंगिक k/k PRs को सूचीबद्ध करें ताकि उन्हें ठीक से ट्रैक किया जा सके।

इस फीचर का अपना फीचर गेट होगा, और यह अल्फा होगा।

/ मील का पत्थर 1.15

@derekwaynecarr : प्रदान किया गया मील का पत्थर इस भंडार के लिए मान्य नहीं है। इस भंडार में मील के पत्थर: [ keps-beta , keps-ga , v1.14 , v1.15 ]

मील का पत्थर साफ़ करने के लिए /milestone clear का उपयोग करें।

/मील का पत्थर v1.15

/असाइन @lmdaly

https://github.com/kubernetes/kubernetes/issues/72828

कोड पीआरएस

@lmdaly
https://github.com/kubernetes/kubernetes/issues/72828
मेरी टीम और मैं नुमा संवेदनशील एप्लिकेशन के लिए टोपोलॉजी मैनेजर के परीक्षण पर विचार करते हैं।
तो, हमारे कुछ प्रश्न हैं।
पीआर के ऊपर, क्या ये टोपोलॉजी मैनेजर के लिए पूर्ण प्रभाव हैं?
और क्या यह अभी परीक्षण या स्थिर है?

@ बीजी-चुन हम एनवीडिया में भी ऐसा ही कर रहे हैं। हमने इन डब्ल्यूआईपी पीआर को अपने आंतरिक स्टैक में खींच लिया है और इसके चारों ओर सीपीयू/जीपीयू के लिए एक टोपोलॉजी-जागरूक आवंटन रणनीति बनाई है। ऐसा करते हुए, हमने कुछ मुद्दों का खुलासा किया और इन पीआर पर कुछ विशिष्ट प्रतिक्रिया दी।

अधिक जानकारी के लिए कृपया यहां चर्चा सूत्र देखें:
https://kubernetes.slack.com/archives/C0BP8PW9G/p1556371768035800

अरे, @lmdaly मैं v1.15 डॉक्स रिलीज़ शैडो हूं।

मैं देख रहा हूँ कि आप 1.15 रिलीज़ के लिए इस एन्हांसमेंट के अल्फ़ा संस्करण को लक्षित कर रहे हैं। क्या इसके लिए किसी नए दस्तावेज़ (या संशोधन) की आवश्यकता है?

बस एक दोस्ताना अनुस्मारक हम गुरुवार, 30 मई तक k/वेबसाइट (शाखा देव-1.15) के खिलाफ पीआर की तलाश कर रहे हैं। यह बहुत अच्छा होगा यदि यह पूर्ण दस्तावेज़ीकरण की शुरुआत है, लेकिन प्लेसहोल्डर पीआर भी स्वीकार्य है। अगर आपका कोई प्रश्न हैं, तो मुझे से पूछें! मैं

@lmdaly बस एक दोस्ताना अनुस्मारक हम गुरुवार, 30 मई तक के/वेबसाइट (शाखा देव

हाय @lmdaly । कोड फ्रीज गुरुवार, मई 30th 2019 @ EOD PST है । रिलीज में जाने वाले सभी संवर्द्धन परीक्षण सहित कोड-पूर्ण होने चाहिए, और दस्तावेज़ पीआर खुले होने चाहिए।

सभी मर्ज किए गए हैं या नहीं यह देखने के लिए https://github.com/kubernetes/kubernetes/issues/72828 देख रहे होंगे।

यदि आप जानते हैं कि यह फिसल जाएगा, तो कृपया उत्तर दें और हमें बताएं। धन्यवाद!

@daminisatya मैंने डॉक्टर पीआर को आगे बढ़ाया है। https://github.com/kubernetes/website/pull/14572

मुझे बताएं कि क्या यह सही तरीके से किया गया है और अगर कुछ अतिरिक्त आइटम करने की आवश्यकता है। याद दिलाने के लिए शुक्रिया!

धन्यवाद @lmdaly

हाय @lmdaly , आज 1.15 रिलीज चक्र के लिए कोड फ्रीज है। अभी भी कुछ k/k PRs हैं जिन्हें अभी तक आपके ट्रैकिंग समस्या https://github.com/kubernetes/kubernetes/issues/72828 से मर्ज नहीं किया गया है 1.15 एन्हांसमेंट ट्रैकिंग शीट में जोखिम के रूप में चिह्नित किया जा रहा है। क्या आज ईओडी पीएसटी द्वारा इनका विलय करने का उच्च विश्वास है? इस बिंदु के बाद, केवल रिलीज-अवरुद्ध मुद्दों और पीआर को अपवाद के साथ मील के पत्थर में अनुमति दी जाएगी।

/ मील का पत्थर स्पष्ट

हाय @lmdaly @derekwaynecarr , मैं 1.16 एन्हांसमेंट लीड हूं। क्या यह सुविधा 1.16 में अल्फा/बीटा/स्थिर चरणों में स्नातक होने जा रही है? कृपया मुझे बताएं ताकि इसे 1.16 ट्रैकिंग स्प्रेडशीट में जोड़ा जा सके। यदि स्नातक नहीं हो रहा है, तो मैं इसे मील के पत्थर से हटा दूंगा और ट्रैक किए गए लेबल को बदल दूंगा।

एक बार कोडिंग शुरू हो जाने पर या यदि यह पहले से ही है, तो कृपया इस मुद्दे में सभी प्रासंगिक k/k PRs को सूचीबद्ध करें ताकि उन्हें ठीक से ट्रैक किया जा सके।

माइलस्टोन तिथियां एन्हांसमेंट फ़्रीज़ 7/30 और कोड फ़्रीज़ 8/29 हैं।

शुक्रिया।

@ kacole2 अनुस्मारक के लिए धन्यवाद। यह सुविधा 1.16 में अल्फा के रूप में जाएगी।

पीआर की चल रही सूची यहां पाई जा सकती है: https://github.com/kubernetes/kubernetes/issues/72828

धन्यवाद!

सहमत हूं कि यह 1.16 के लिए अल्फा में उतरेगा, हम पहले से 1.15 के लिए विलय किए गए केप में शुरू किए गए और कैप्चर किए गए प्रयास को बंद कर देंगे।

हाय @lmdaly , मैं

क्या इस एन्हांसमेंट के लिए किसी नए दस्तावेज़ (या संशोधन) की आवश्यकता है?

बस एक दोस्ताना अनुस्मारक हम k/वेबसाइट (शाखा देव-1.16) के खिलाफ शुक्रवार, 23 अगस्त तक पीआर की तलाश कर रहे हैं। यह बहुत अच्छा होगा यदि यह पूर्ण दस्तावेज़ीकरण की शुरुआत है, लेकिन प्लेसहोल्डर पीआर भी स्वीकार्य है। अगर आपका कोई प्रश्न हैं, तो मुझे से पूछें!

धन्यवाद!

Documentation PR: https://github.com/kubernetes/website/pull/15716

@lmdaly क्या टोपोलॉजी मैनेजर उपयोगकर्ताओं को दिए गए पॉड के लिए NUMA कॉन्फ़िगरेशन बताने के लिए कोई जानकारी या एपीआई प्रदान करेगा?

@mJace कुबेक्टल के माध्यम से दिखाई देने वाली

@lmdaly हाँ, kubectl describe अच्छा है। या संबंधित जानकारी वापस करने के लिए कुछ एपीआई।
चूंकि हम पॉड के लिए कुछ टोपोलॉजी संबंधी जानकारी प्रदान करने के लिए एक सेवा विकसित कर रहे हैं, जैसे पॉड के लिए सीपीयू पिनिंग स्थिति, और इसके पास-थ्रू वीएफ के लिए नुमा नोड।
और कुछ मॉनिटर टूल जैसे वेव स्कोप कुछ फैंसी काम करने के लिए एपीआई को कॉल कर सकते हैं।
उदाहरण के लिए, व्यवस्थापक बता सकता है कि VNF उचित numa कॉन्फ़िगरेशन के अंतर्गत है या नहीं।

बस यह जानना पसंद है कि क्या टोपोलॉजी मैनेजर इस हिस्से को कवर करेगा।
या अगर कोई काम है तो हम कर सकते हैं अगर टोपोलॉजी मैनेजर इस तरह की कार्यक्षमता का समर्थन करने की योजना बना रहा है।

@mJace ठीक है, इसलिए वर्तमान में टोपोलॉजी मैनेजर के लिए ऐसा कोई एपीआई नहीं है। मुझे नहीं लगता कि इसके लिए कोई प्राथमिकता है, क्योंकि सीपीयू और डिवाइस मैनेजर के साथ पॉड्स को वास्तव में जो सौंपा गया है, उसमें दृश्यता नहीं है।

इसलिए मुझे लगता है कि इस पर चर्चा शुरू करना अच्छा होगा और देखें कि हम उपयोगकर्ताओं को किस तरह का दृष्टिकोण दे सकते हैं।

मैंने देखा, मैंने सोचा था कि सीपीयू और डिवाइस मैनेजर इस जानकारी को देखने में सक्षम है।

हो सकता है कि यह जानकारी प्रदान करने के लिए कैडवाइजर की अच्छी भूमिका हो।
क्योंकि मूल रूप से कैडवाइजर को ps ls द्वारा कंटेनर की जानकारी जैसे PID, आदि मिलती है।
और यह ठीक उसी तरह है जैसे हम कंटेनर की टोपोलॉजी से संबंधित जानकारी की जांच करते हैं।
मैं इसे कैडवाइजर में लागू करूंगा और इसके लिए एक जनसंपर्क तैयार करूंगा।

मैंने कैडवाइजर में एक संबंधित मुद्दा बनाया है।
https://github.com/google/cadvisor/issues/2290

/ असाइन करें

+1 से @mJace कैडवाइजर प्रस्ताव।

CPU Manager और Topology Manager साथ कंटेनर के अंदर डीपीडीके लिब का उपयोग करने के लिए, कंटेनर के सीपीयू एफ़िनिटी को पार्स करना और फिर इसे डीपीडीके लिब में पास करना, दोनों डीपीडीके लिब के थ्रेड पिनिंग के लिए आवश्यक हैं।

अधिक विवरण के लिए, यदि कंटेनर के cgroup cpuset सबसिस्टम में cpus की अनुमति नहीं है, तो cpus पर प्रक्रिया को पिन करने के लिए sched_setaffinity पर कॉल को फ़िल्टर कर दिया जाएगा।
DPDK lib का इस्तेमाल करता है pthread_setaffinity_np धागा पिन करने के लिए, और pthread_setaffinity_np की एक धागा स्तर के आवरण है sched_setaffinity ।
और Kubernetes का CPU प्रबंधक कंटेनर के cgroup cpuset सबसिस्टम पर विशेष cpus सेट करता है।

@ बीजी-चुन मैं एक अलग उद्देश्य की सेवा के रूप में कैडवाइजर परिवर्तन को समझता हूं: निगरानी। आपकी आवश्यकता के लिए '/ proc/self/status' से 'Cpus_Allowed' या 'Cpus_Allowed_List' को पार्स करके कंटेनर के अंदर से असाइन किए गए CPU को पढ़ना संभव है। क्या वह तरीका आपके काम आएगा?

/ Proc / * / की तरह की स्थिति में @ConnorDoyle जानकारी Cpus_Allowed से प्रभावित होता है sched_setaffinity । इसलिए, यदि एप्लिकेशन कुछ सेट करता है, तो यह सीग्रुप के cpuset नियंत्रक द्वारा वास्तव में अनुमत चीज़ों का सबसेट होगा।

@kad , मैं कंटेनर के भीतर लॉन्चर के लिए सीपीयू आईडी मानों को डीपीडीके प्रोग्राम में पास करने के लिए एक तरीका

@कॉनरडॉयल
आपके सुझाव के लिए धन्यवाद, मैं इस पर विचार करूंगा।
मेरी योजना डीपीडीके-कंटेनर को विशेष सीपीयू आवंटन जानकारी बताने के लिए छोटे-आराम-एपीआई सर्वर को तैनात कर रही थी।

परिवर्तनों के संबंध में, मैंने अभी तक कैडवाइजर परिवर्तन नहीं देखा, मुझे केवल प्रस्ताव दिखाई दे रहा है।
प्रस्ताव का कहना है able to tell if there is any cpu affinity set for the container. लक्ष्य में और to tell if there is any cpu affinity set for the container processes. भविष्य के काम में।

प्रस्ताव को पढ़ने के बाद, मैंने सोचा कि यह बहुत अच्छा होगा यदि कैडवाइजर सीपीयू पिनिंग जानकारी को पार्स करने में सक्षम है और क्यूबलेट इसे कंटेनर में एक पर्यावरण चर जैसे status.podIP , metadata.name , और limits.cpu ।
यही मुख्य कारण है कि मैंने +1 छोड़ दिया।

@bg-chun आप मेरा पहला जनसंपर्क cadvisor पर देख सकते हैं
https://github.com/google/cadvisor/pull/2291

मैंने कुछ इसी तरह का कार्य पूरा किया है।
https://github.com/mJace/numacc
लेकिन वास्तव में यह सुनिश्चित नहीं है कि इसे कैडवाइजर में लागू करने का सही तरीका क्या है?
इसलिए मैं केवल एक नई सुविधा के साथ पीआर बनाता हूं -> पीएसआर दिखाएं।

लेकिन वास्तव में यह सुनिश्चित नहीं है कि इसे कैडवाइजर में लागू करने का सही तरीका क्या है?

हो सकता है कि हम उस प्रस्ताव के तहत इस पर चर्चा कर सकें? यदि आप गुरुओं को लगता है कि इस सुविधा की आवश्यकता है :)

1.16 के लिए @lmdaly कोड फ्रीज गुरुवार 8/29 को है। हम शेष k/k पीआर के लिए https://github.com/kubernetes/kubernetes/issues/72828 पर नज़र रखेंगे।

@ kacole2 इस सुविधा के लिए सभी आवश्यक

अरे वहाँ @lmdaly - 1.17 एन्हांसमेंट यहाँ ले जाते हैं। मैं चेक इन करना चाहता था और देखना चाहता था कि क्या आपको लगता है कि यह एन्हांसमेंट 1.17 में अल्फा/बीटा/स्थिर हो जाएगा?

वर्तमान रिलीज शेड्यूल है:

• सोमवार, सितंबर 23 - रिलीज़ चक्र शुरू होता है
• मंगलवार, अक्टूबर 15, ईओडी पीएसटी - एन्हांसमेंट फ़्रीज़
• गुरुवार, नवंबर 14, ईओडी पीएसटी - कोड फ़्रीज़
• मंगलवार, 19 नवंबर - डॉक्स को पूरा किया जाना चाहिए और उनकी समीक्षा की जानी चाहिए
• सोमवार, 9 दिसंबर - कुबेरनेट्स 1.17.0 जारी किया गया

यदि आप ऐसा करते हैं, तो कृपया इस मुद्दे में सभी प्रासंगिक k/k PRs को सूचीबद्ध करें ताकि उन्हें ठीक से ट्रैक किया जा सके। मैं

धन्यवाद!

/ मील का पत्थर स्पष्ट

@lmdaly क्या आरडीएमए चर्चा के साथ सीधे GPU का लिंक है?

@nicolaev , हम इस उपयोग के मामले को भी देख रहे हैं। हमने यह कैसे करना है, इस पर कुछ आंतरिक सोच शुरू की, लेकिन हम इस पर सहयोग करना पसंद करेंगे।

@ moshe010 @nickolaev @lmdaly , हम भी आरडीएमए और जीपीयू डायरेक्ट से संबंधित इस उपयोग के मामले को देख रहे हैं। हम इसमें सहयोग करना चाहेंगे। इसके इर्द-गिर्द एक सूत्र/चर्चा शुरू करना संभव है?

नमस्कार! मेरे पास NTM और अनुसूचक के बारे में एक प्रश्न है। जैसा कि मैं समझता हूं, अनुसूचक NUMAs के बारे में नहीं जानता है और उस पर नोड पसंद कर सकता है वांछित NUMA पर कोई संसाधन (सीपीयू, मेमोरी और डिवाइस) नहीं है। तो टोपोलॉजी मैनेजर उस नोड पर संसाधन आवंटन से इंकार कर देगा। क्या यह सच है?

@nicolaev @Deepthidharwar , मैं उपयोग के मामलों के साथ google doc शुरू करूंगा और हम चर्चा को आगे

मैं इस फीचर को देखकर वाकई बहुत खुश हूं। हमें सिंगल NUMA नोड में CPU, Hugepage, SRIOV-VFs और अन्य हार्डवेयर रिसोर्स की भी आवश्यकता है।
लेकिन डिवाइस प्लगइन द्वारा विशाल पृष्ठ को स्केलर संसाधन के रूप में महसूस नहीं किया जाता है, क्या इस सुविधा को k8s में विशाल पृष्ठ सुविधा को बदलने की आवश्यकता है?
@iamneha

@ConnorDoyle बस पुष्टि करने के लिए, इस सुविधा को सीपीयू मैनेजर और डिवाइस मैनेजर दोनों से टोपोलॉजी संकेतों की आवश्यकता है? मैंने इसे 1.16 पर परीक्षण किया और काम नहीं किया, ऐसा लगता है कि यह केवल सीपीयू प्रबंधक से संकेत मिला है लेकिन डिवाइस की ओर से कोई संकेत नहीं है।

@ConnorDoyle यहाँ कुछ और विवरण है:
https://gist.githubusercontent.com/jianzzha/c2a66a2514c178cca76a432029ff3387/raw/264f13dfcd06f1f80c48c113aa235fab7c33d81e/hyper%2520threading%2520enabled

@jianzzha , आप किस डिवाइस प्लगइन का उपयोग कर रहे हैं? उदाहरण के लिए यदि आप SR-IOV डिवाइस प्लगइन का उपयोग करते हैं तो आपको यह सुनिश्चित करने की आवश्यकता है कि यह NUMA नोड को रिपोर्ट करता है देखें [1]

[1] https://github.com/intel/sriov-network-device-plugin/commit/000db15405f3ce3b7c2f9feb180c3051aa3f7aea।

@andyzheung विशाल पृष्ठ एकीकरण पर वर्तमान में चर्चा की जा रही है और पिछले दो सप्ताह में सिग-नोड बैठक में प्रस्तुत किया गया है। यहां कुछ प्रासंगिक लिंक दिए गए हैं:

https://docs.google.com/presentation/d/1H5xhCjgCZJjdTm-mGUFwqoz8XmoVd8xTCwJ1AfVR_54/edit?usp=sharing
https://github.com/kubernetes/enhancements/pull/1245
https://github.com/kubernetes/enhancements/pull/1199

@jianzzha डिवाइस प्लगइन के बारे में संकेत नहीं दे रहा है। क्या आपके प्लग इन को उन उपकरणों के बारे में NUMA जानकारी की रिपोर्ट करने के लिए अपडेट किया गया है, जिनकी वह गणना करता है? इसे डिवाइस संदेश में इस फ़ील्ड को जोड़ने की आवश्यकता है https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/apis/deviceplugin/v1beta1/api.proto#L100

धन्यवाद दोस्तों। फिक्स्ड और अब काम करता है।

@klueska
एनवीडिया-जीपीयू-डिवाइस-प्लगइन के संबंध में..
मैं टोपोलॉजी मैनेजर के लिए एनवीडिया-जीपीयू-डिवाइस-प्लगइन को अपडेट करने के लिए केवल एक सक्रिय पीआर (डब्ल्यूआईपी) देख सकता हूं।
क्या उपरोक्त पीआर के साथ टोपोलॉजी संकेत प्रदान करने के लिए एनवीडिया-जीपीयू-डिवाइस-प्लगइन अपडेट किया जाएगा? या क्या मुझे कुछ याद आ रहा है?

@ बीजी-चुन हाँ यह होना चाहिए। बस लेखक को पिंग किया। अगर वह अगले दिन या उसके बाद वापस नहीं आता है, तो मैं खुद प्लगइन को अपडेट कर दूंगा।

@ बीजी-चुन @klueska मैंने पैच अपडेट किया है।

@klueska @carmark
अद्यतन करने और नोटिस के लिए धन्यवाद।
मैं अपने कार्यक्षेत्र में उपयोगकर्ताओं के लिए sr-iov-plugin अद्यतन और gpu-प्लगइन अद्यतन पेश करूँगा।

मैं अगली रिलीज के लिए एक वृद्धि का प्रस्ताव दूंगा।
यह मूल रूप से "टोपोलॉजी संरेखण केवल तभी होता है जब पॉड गारंटीकृत क्यूओएस" प्रतिबंध में होता है।
यह प्रतिबंध इस समय मेरे लिए टोपोलॉजी मैनेजर को अनुपयोगी बना देता है, क्योंकि मैं K8s से अनन्य CPU के लिए पूछना नहीं चाहता, हालाँकि मैं कई पूलों से आने वाले कई उपकरणों के सॉकेट को संरेखित करना चाहूंगा (जैसे GPU + SR) -आईओवी वीएफ आदि)
इसके अलावा क्या होगा यदि मेरा कार्यभार स्मृति के प्रति संवेदनशील नहीं है, या इसके मेम उपयोग (गारंटी क्यूओएस का एक अन्य मानदंड) को प्रतिबंधित नहीं करना चाहता है।
भविष्य में जब उम्मीद है कि बड़े पृष्ठ भी संरेखित होंगे तो यह प्रतिबंध और भी अधिक सीमित आईएमओ महसूस करेगा।

क्या "संरेखणीय" संसाधनों को व्यक्तिगत रूप से संरेखित करने के खिलाफ कोई तर्क है? निश्चित रूप से, चलो केवल सीपीयू प्रबंधक से संकेत इकट्ठा करते हैं यदि अनन्य सीपीयू का उपयोग किया जाता है, लेकिन स्वतंत्र रूप से डिवाइस मैनेजर से संकेत इकट्ठा करते हैं यदि उपयोगकर्ता को सॉकेट की जानकारी वाले डिवाइस की आवश्यकता होती है, या मेमोरी मैनेजर से जब उपयोगकर्ता विशाल पेज आदि मांगता है।

या तो यह, या यदि पॉड स्टार्टअप के दौरान अनावश्यक अतिरिक्त गणना भार एक चिंता का विषय है, तो शायद संरेखण होता है या नहीं, यह नियंत्रित करने के लिए मूल पॉड-स्तरीय कॉन्फ़िगरेशन ध्वज वापस लाया जा सकता है (जिसे मैं कार्यान्वयन के दौरान स्क्रैप होते देखकर आश्चर्यचकित था)

मैं अगली रिलीज के लिए एक वृद्धि का प्रस्ताव दूंगा।
यह मूल रूप से "टोपोलॉजी संरेखण केवल तभी होता है जब पॉड गारंटीकृत क्यूओएस" प्रतिबंध में होता है।

1.17 के लिए हमारी TODO सूची में यह आइटम नंबर 8 है:
https://docs.google.com/document/d/1YTUvezTLGmVtEF3KyLOX3FzfSDw9w0zB-s2Tj6PNzLA/edit#heading =h.xnehh6metosd

क्या "संरेखणीय" संसाधनों को व्यक्तिगत रूप से संरेखित करने के खिलाफ कोई तर्क है? निश्चित रूप से, चलो केवल सीपीयू प्रबंधक से संकेत इकट्ठा करते हैं यदि अनन्य सीपीयू का उपयोग किया जाता है, लेकिन स्वतंत्र रूप से डिवाइस मैनेजर से संकेत इकट्ठा करते हैं यदि उपयोगकर्ता को सॉकेट की जानकारी वाले डिवाइस की आवश्यकता होती है, या मेमोरी मैनेजर से जब उपयोगकर्ता विशाल पेज आदि मांगता है।

क्या आप प्रस्तावित करते हैं कि क्यूबलेट को चुनने के लिए एक तंत्र होना चाहिए कि किस संसाधन को संरेखित करना है और किन लोगों को संरेखित नहीं करना है (यानी मैं अपने सीपीयू और जीपीयू आवंटन को संरेखित करना चाहता हूं, लेकिन मेरे विशाल पृष्ठ आवंटन नहीं)। मुझे नहीं लगता कि कोई भी इसका एकमुश्त विरोध करेगा, लेकिन अगर हम नोड स्तर पर एक ध्वज के रूप में संरेखण निर्दिष्ट करना जारी रखते हैं, तो चुनिंदा रूप से यह तय करने के लिए कि कौन से संसाधनों को संरेखित करना है और किस पर संरेखित नहीं करना है, यह अत्यधिक बोझिल हो सकता है।

या तो यह, या यदि पॉड स्टार्टअप के दौरान अनावश्यक अतिरिक्त गणना भार एक चिंता का विषय है, तो शायद संरेखण होता है या नहीं, यह नियंत्रित करने के लिए मूल पॉड-स्तरीय कॉन्फ़िगरेशन ध्वज वापस लाया जा सकता है (जिसे मैं कार्यान्वयन के दौरान स्क्रैप होते देखकर आश्चर्यचकित था)

इसके साथ पॉड स्पेक को अपडेट करने के प्रस्ताव को वारंट करने के लिए पॉड-स्तरीय ध्वज के लिए पर्याप्त समर्थन नहीं था। मेरे लिए इस निर्णय को पॉड स्तर पर धकेलना समझ में आता है क्योंकि कुछ पॉड्स को संरेखण की आवश्यकता होती है/चाहते हैं और कुछ नहीं करते हैं, लेकिन हर कोई सहमत नहीं था।

+1 टोपोलॉजी संरेखण पर क्यूओएस वर्ग प्रतिबंध को हटाने के लिए (मैंने इसे सूची में जोड़ा: स्माइली :)। मुझे समझ में नहीं आया कि @Levovar प्रति-संसाधन के आधार पर टोपोलॉजी को सक्षम करने के लिए कह रहा है, बस हमें किसी दिए गए कंटेनर द्वारा उपयोग किए जाने वाले सभी संरेखित संसाधनों को संरेखित करना चाहिए।

जहां तक ​​मुझे याद है, केईपी में टोपोलॉजी में ऑप्ट-इन करने के लिए पॉड-स्तरीय क्षेत्र कभी नहीं था। पहली जगह में इसे पेश नहीं करने का औचित्य अनन्य कोर को निहित छोड़ने के लिए एक ही तर्क था - कुबेरनेट्स एक परियोजना के रूप में नोड-स्तरीय प्रदर्शन प्रबंधन के संदर्भ में पॉड स्पेक को उदारतापूर्वक व्याख्या करने के लिए स्वतंत्र होना चाहता है। मुझे पता है कि समुदाय के कुछ सदस्यों के लिए रुख असंतोषजनक है, लेकिन हम हमेशा इस विषय को फिर से उठा सकते हैं। कुछ के लिए उन्नत सुविधाओं को सक्षम करने बनाम अधिकांश उपयोगकर्ताओं के लिए संज्ञानात्मक भार को संशोधित करने के बीच एक स्वाभाविक तनाव है।

आईएमओ डिजाइन के शुरुआती चरणों में कम से कम एक पॉड-स्तरीय ध्वज था यदि मेरी याददाश्त अच्छी तरह से मेरी सेवा करती है, लेकिन यह लगभग 1.13 था: डी
मैं व्यक्तिगत रूप से हर समय सभी संसाधनों को संरेखित करने की कोशिश करने के साथ ठीक हूं, लेकिन "दिनों में वापस" आमतौर पर सुविधाओं के खिलाफ एक समुदाय धक्का-मुक्की होती थी, जो स्टार्टअप या सभी पॉड्स के शेड्यूलिंग निर्णय में देरी का परिचय देती थी, भले ही उन्हें वास्तव में वृद्धि की आवश्यकता है, या नहीं।

तो मैं बस उन चिंताओं को "पूर्व-पता" करने की कोशिश कर रहा था, मेरे दिमाग में दो विकल्प आ रहे थे: कुछ मानदंडों के आधार पर संसाधन समूहों के संरेखण को पूर्व-गेट करें (सीपीयू के लिए परिभाषित करना आसान है, दूसरों के लिए कठिन); या कुछ कॉन्फ़िगरेशन ध्वज पेश करें।

हालांकि, अगर कोई सामान्य वृद्धि के खिलाफ अब कोई धक्का नहीं है तो मैं इसके साथ पूरी तरह से शांत हूं :)

@mrbobbytables हम TopologyManager से beta पहुंचने की योजना बना रहे हैं। ट्रैकिंग समस्या यहाँ है: https://github.com/kubernetes/kubernetes/issues/83479

@ बीजी-चुन @klueska मैंने पैच अपडेट किया है।

पैच मर्ज किया गया:
https://github.com/NVIDIA/k8s-device-plugin/commit/cc0aad87285b573127add4e487b13434a61ba0d6

पैच के साथ नई रिलीज़ बनाई गई:
https://github.com/NVIDIA/k8s-device-plugin/releases/tag/1.0.0-beta2

v1.17 . के लिए ट्रैकिंग बीटा

बहुत बढ़िया, धन्यवाद @derekwaynecarr । मैं इसे शीट में जोड़ दूंगा :)
/चरण बीटा

@lmdaly

मैं v1.17 डॉक्स शैडो में से एक हूं।
क्या इस एन्हांसमेंट (या v1.17 के लिए नियोजित कार्य) के लिए किसी नए दस्तावेज़ (या मौजूदा दस्तावेज़ों में संशोधन) की आवश्यकता है? यदि नहीं, तो क्या आप कृपया 1.17 एन्हांसमेंट ट्रैकर शीट को अपडेट कर सकते हैं (या मुझे बताएं और मैं ऐसा करूंगा)

यदि ऐसा है, तो केवल एक मित्रवत अनुस्मारक हम k/वेबसाइट (शाखा देव-1.17) के विरुद्ध शुक्रवार, 8 नवंबर तक पीआर की तलाश कर रहे हैं, यह इस समय केवल एक प्लेसहोल्डर पीआर हो सकता है। अगर आपका कोई प्रश्न हैं, तो मुझे से पूछें!

धन्यवाद!

@ VineethReddy02 हाँ हमने 1.17 के लिए दस्तावेज़ीकरण अद्यतन की योजना बनाई है, यदि आप ट्रैकर शीट को अद्यतन कर सकते हैं तो यह बहुत अच्छा होगा!

हम उस पीआर को इससे पहले खोलना सुनिश्चित करेंगे, रिमाइंडर के लिए धन्यवाद।

इसके लिए प्रलेखन पर नज़र रखने का मुद्दा यहाँ है: https://github.com/kubernetes/kubernetes/issues/83482

https://github.com/kubernetes/enhancements/pull/1340
दोस्तों, मैंने टोपोलॉजी मैनेजर के लिए एक अंतर्निर्मित नोड लेबल ( beta.kubernetes.io/topology ) जोड़ने के लिए केईपी अपडेट पीआर खोला।
लेबल नोड की नीति को उजागर करेगा।
मुझे लगता है कि जब एक ही क्लस्टर में कई नीतियों वाले नोड होते हैं, तो यह विशेष नोड के लिए एक पॉड को शेड्यूल करने में मददगार होगा।
क्या मैं समीक्षा के लिए कह सकता हूं?

नमस्ते @lmdaly @derekwaynecarr

1.17 एन्हांसमेंट टीम से जेरेमी यहां . क्या आप कृपया उन k/k PRs को सूचीबद्ध कर सकते हैं जो इसके लिए उड़ान में हैं ताकि हम उन्हें ट्रैक कर सकें? मुझे लगता है कि #83492 को मर्ज कर दिया गया था, लेकिन कुछ और संबंधित मुद्दे हैं जो समग्र ट्रैकिंग आइटम से लटके हुए हैं। हम 14 नवंबर को कोड फ़्रीज़ को बंद कर रहे हैं, इसलिए हम यह जानना चाहेंगे कि इससे पहले यह कैसा चल रहा है! बहुत बहुत धन्यवाद!

@jeremyrickard ऊपर बताए अनुसार 1.17 के लिए यह ट्रैकिंग समस्या है: https://github.com/kubernetes/enhancements/issues/693#issuecomment -538123786

@lmdaly @derekwaynecarr

एक अनुकूल अनुस्मारक हम शुक्रवार, 8 नवंबर तक k/वेबसाइट (शाखा देव-1.17) के विरुद्ध डॉक्स के लिए प्लेसहोल्डर पीआर की तलाश कर रहे हैं। इस समय सीमा के लिए हमारे पास सिर्फ 2 दिन और हैं।

डॉक्स पीआर यहाँ btw है: https://github.com/kubernetes/website/pull/17451

@klueska मुझे कुछ काम 1.18 से

कोई बात नहीं, मैं https://github.com/kubernetes/kubernetes/issues/85093 में देखता हूं कि आप 1.18 में बीटा में कूदने जा रहे हैं, 1.17 के भाग के रूप में नहीं। क्या आप चाहते हैं कि हम इसे 1.17 मील के पत्थर @klueska के हिस्से के रूप में अल्फा संस्करण में एक बड़े बदलाव के रूप में ट्रैक करें? या सिर्फ स्नातक को 1.18 तक के लिए टाल दें?

/मील का पत्थर v1.18

अरे @klueska

1.18 एन्हांसमेंट टीम चेक इन कर रही है! क्या आप अभी भी इसे 1.18 में बीटा में स्नातक करने की योजना बना रहे हैं? यदि आपके KEP को किसी अपडेट की आवश्यकता है, तो एन्हांसमेंट फ़्रीज़ 28 जनवरी को होगा, जबकि कोड फ़्रीज़ 5 मार्च को होगा।

आपको धन्यवाद!

हां।

@klueska अद्यतन के लिए धन्यवाद! ट्रैकिंग शीट को अपडेट करना।

@klueska जब हम इस रिलीज़ के लिए KEPs की समीक्षा कर रहे थे, हमने देखा कि यह परीक्षण योजनाएँ गायब है। रिलीज़ में बीटा में स्नातक होने के लिए, इसमें परीक्षण योजनाओं को जोड़ने की आवश्यकता होगी। मैं इसे अभी के लिए मील के पत्थर से हटाने जा रहा हूं, लेकिन हम इसे वापस जोड़ सकते हैं यदि आप एक अपवाद अनुरोध दर्ज करते हैं और परीक्षण योजनाओं को उसके KEP में जोड़ते हैं। देर से नोटिस के लिए खेद है।

/ मील का पत्थर स्पष्ट

@vpickard कृपया ऊपर देखें

@vpickard कृपया ऊपर देखें

@klueska सिर

https://github.com/kubernetes/kubernetes/pull/87645

@jeremyrickard क्या कोई परीक्षण योजना टेम्प्लेट है जिसे आप मुझे संदर्भ के लिए इंगित कर सकते हैं?

@vpickard आप इस पर एक नज़र

https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/20190530-pv-health-monitor.md#test -plan
तथा
https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/20200120-skip-permission-change.md#test -plan

इकाई परीक्षणों और e2e परीक्षणों का अवलोकन शामिल करें।

यदि आपके पास टेस्ट ग्रिड में कुछ भी दिखाई देता है, तो इसे शामिल करना बहुत अच्छा होगा।

अपवाद स्वीकृत किया गया था।

/मील का पत्थर v1.18

@jeremyrickard परीक्षण योजना विलय: https://github.com/kubernetes/enhancements/pull/1527

नमस्ते @klueska @vpickard , बस एक दोस्ताना अनुस्मारक है कि कोड फ़्रीज़ गुरुवार 5 मार्च से प्रभावी होगा।

क्या आप कृपया सभी k/k PR या किसी अन्य PR को लिंक कर सकते हैं जिन्हें इस वृद्धि के लिए ट्रैक किया जाना चाहिए?

धन्यवाद :)

नमस्ते @palnabarun

1.18 के लिए यहां ट्रैकिंग समस्या:
https://github.com/kubernetes/kubernetes/issues/85093

वर्तमान खुले पीआर:
https://github.com/kubernetes/kubernetes/pull/87758 (स्वीकृत, फ़्लैकिंग परीक्षण)
https://github.com/kubernetes/kubernetes/pull/87759 (डब्ल्यूआईपी)
https://github.com/kubernetes/kubernetes/pull/87650 (समीक्षा की गई, अनुमोदन की आवश्यकता है)

https://github.com/kubernetes/kubernetes/pull/87645 (e2e परीक्षण पीआर, अनुमोदन की आवश्यकता है)

@vpickard क्या आप मेरे द्वारा छूटे गए किसी भी e2e

धन्यवाद

पीआर और अम्ब्रेला मुद्दे को यहां जोड़ने के लिए धन्यवाद @nolancon । मैंने पीआर को ट्रैकिंग शीट में जोड़ दिया है।

हाय @palnabarun , @nolancon ,

E2E परीक्षणों से संबंधित कुछ अतिरिक्त खुले पीआर:
https://github.com/kubernetes/test-infra/pull/16062 (समीक्षा और अनुमोदन की आवश्यकता है)
https://github.com/kubernetes/test-infra/pull/16037 (समीक्षा और अनुमोदन की आवश्यकता है)

अतिरिक्त अपडेट के लिए धन्यवाद @vpickard । :)

हैलो @lmdaly मैं v1.18 डॉक्स शैडो में से एक हूं।
क्या इस एन्हांसमेंट (या v1.18 के लिए नियोजित कार्य) के लिए किसी नए दस्तावेज़ (या मौजूदा दस्तावेज़ों में संशोधन) की आवश्यकता है? यदि नहीं, तो क्या आप कृपया 1.18 एन्हांसमेंट ट्रैकर शीट को अपडेट कर सकते हैं (या मुझे बताएं और मैं ऐसा करूंगा)

यदि ऐसा है, तो केवल एक मित्रवत अनुस्मारक हम k/वेबसाइट (शाखा देव-1.18) के लिए शुक्रवार, 28 फरवरी तक पीआर की तलाश कर रहे हैं, यह इस समय केवल प्लेसहोल्डर पीआर हो सकता है। अगर आपका कोई प्रश्न हैं, तो मुझे से पूछें!

हाय @irvifa , सिर उठाने के लिए धन्यवाद। मैंने कुछ मामूली बदलावों के साथ कुबेरनेट्स/वेबसाइट#19050 यहां एक जनसंपर्क खोला है। यह पीआर अभी के लिए डब्ल्यूआईपी है, बीटा में जाने के मानदंड पूरे होने के बाद मैं इसे डब्ल्यूआईपी से हटा दूंगा (ऊपर के पीआरएस अभी भी समीक्षा के अधीन हैं)।
धन्यवाद।

हाय @nolancon आपकी त्वरित प्रतिक्रिया के लिए धन्यवाद, मैं अब स्थिति को प्लेसहोल्डर पीआर में बदल देता हूं .. धन्यवाद!

@palnabarun FYI करें, मैंने समीक्षा प्रक्रिया को आसान बनाने के लिए इस PR https://github.com/kubernetes/kubernetes/pull/87759 को दो PR में विभाजित कर दिया है। दूसरा यहाँ है https://github.com/kubernetes/kubernetes/pull/87983 और इसे भी ट्रैक करने की आवश्यकता होगी। धन्यवाद।

@nolancon अपडेट के लिए धन्यवाद।

मैं देख रहा हूं कि कुछ जनसंपर्क का विलय होना अभी बाकी है। मैं देखना चाहता था कि क्या आपको पीआर के समीक्षकों और अनुमोदनकर्ताओं को प्राप्त करने में रिलीज टीम से मदद की ज़रूरत है। किसी भी चीज की आवश्यकता होने पर हमें बताएं।

FYI करें, हम 5 मार्च को

@nolancon अपडेट के लिए धन्यवाद।

मैं देख रहा हूं कि कुछ जनसंपर्क का विलय होना अभी बाकी है। मैं देखना चाहता था कि क्या आपको पीआर के समीक्षकों और अनुमोदनकर्ताओं को प्राप्त करने में रिलीज टीम से मदद की ज़रूरत है। किसी भी चीज की आवश्यकता होने पर हमें बताएं।

FYI करें, हम 5 मार्च को

@palnabarun एक और अपडेट, https://github.com/kubernetes/kubernetes/pull/87983 अब बंद हो गया है और इसे ट्रैक करने की आवश्यकता नहीं है। आवश्यक परिवर्तन मूल पीआर में शामिल हैं https://github.com/kubernetes/kubernetes/pull/87759 जो समीक्षाधीन है।

@nolancon कूल। मैं आपके द्वारा ऊपर साझा किए गए अम्ब्रेला ट्रैकर मुद्दे को भी ट्रैक कर रहा हूं। :)

नमस्ते @nolancon , यह एक अनुस्मारक है कि हम 5 मार्च को

कोड फ़्रीज़ द्वारा, सभी प्रासंगिक पीआर को मर्ज कर दिया जाना चाहिए अन्यथा आपको एक अपवाद अनुरोध दर्ज करने की आवश्यकता होगी।

हाय @nolancon ,

आज ईओडी कोड फ्रीज है ।

क्या आपको लगता है कि समय सीमा तक https://github.com/kubernetes/kubernetes/pull/87650 की समीक्षा की जाएगी?

यदि नहीं, तो कृपया अपवाद अनुरोध दर्ज करें ।

हाय @nolancon ,

आज ईओडी कोड फ्रीज है ।

क्या आपको लगता है कि Kubernetes/kubernetes#87650 की समय सीमा तक समीक्षा की जाएगी?

यदि नहीं, तो कृपया अपवाद अनुरोध दर्ज करें ।

नमस्ते @palnabarun , पिछले कुछ दिनों में बहुत प्रगति हुई है और हमें विश्वास है कि कोड फ्रीज होने से पहले सब कुछ स्वीकृत और विलय हो जाएगा। यदि नहीं, तो मैं अपवाद अनुरोध दर्ज करूंगा।

बस स्पष्ट करने के लिए, ईओडी से आपका मतलब शाम 5 बजे या मध्यरात्रि पीएसटी है? धन्यवाद

बस स्पष्ट करने के लिए, ईओडी से आपका मतलब शाम 5 बजे या मध्यरात्रि पीएसटी है? धन्यवाद

शाम 5 बजे पीएसटी।

पीआर स्वीकृत है लेकिन एक मील का पत्थर गायब है जिसे सिग-नोड को विलय में जोड़ने की आवश्यकता है। मैंने उन्हें स्लैक में पिंग किया है, उम्मीद है कि यह अनस्टक हो जाएगा और आपको अपवाद की आवश्यकता नहीं है। =)

ऐसा लगता है कि इसके लिए सभी पीआर मर्ज हो गए हैं (और समय सीमा से स्वीकृत), मैंने अपनी एन्हांसमेंट ट्रैकिंग शीट को अपडेट कर दिया है। :मुस्कुराओ:

/ मील का पत्थर स्पष्ट

(इस एन्हांसमेंट इश्यू को v1.18 माइलस्टोन से हटाना क्योंकि माइलस्टोन पूरा हो गया है)

हाय @nolancon @lmdaly , यहां 1.19 के लिए एन्हांसमेंट शैडो। 1.19 में इसके लिए कोई योजना?

1.19 के लिए एकमात्र नियोजित वृद्धि यह है:
https://github.com/kubernetes/enhancements/pull/1121

शेष कार्य आवश्यकतानुसार कोड रिफैक्टरिंग/बग फिक्स पर होगा।

क्या इस मुद्दे के स्वामी को @lmdaly के बजाय मुझे बदलने के लिए वैसे भी है?

धन्यवाद, मैं संपर्क अपडेट करूंगा।

/मील का पत्थर v1.19

/असाइन @klueska
/अनअसाइन @lmdaly

यहाँ आपके पास है, केविन https://prow.k8s.io/command-help

हाय केविन। हाल ही में केईपी प्रारूप बदल गया है, और पिछले सप्ताह #1620 को भी मिला दिया गया है, जिससे केईपी टेम्पलेट में उत्पादन तैयारी समीक्षा प्रश्नों को जोड़ा गया है। यदि संभव हो, तो कृपया अपने KEP को पुन: स्वरूपित करने के लिए समय निकालें और टेम्प्लेट में जोड़े गए प्रश्नों के उत्तर भी दें। उन सवालों के जवाब सुविधा का उपयोग करने और समस्या निवारण करने वाले ऑपरेटरों के लिए सहायक होंगे (विशेष रूप से इस स्तर पर निगरानी टुकड़ा)। धन्यवाद!

@klueska ^^

@derekwaynecarr @klueska @johnbelamaric
मैं 1.19 रिले पर नई टोपोलॉजी नीति जोड़ने की भी योजना बना रहा हूं।
लेकिन इसे अभी तक मालिक और अनुरक्षक द्वारा समीक्षा नहीं मिली।
(यदि 1.19 में बनाना कठिन लगता है, तो कृपया मुझे बताएं।)

• केईपी अपडेट पीआर: https://github.com/kubernetes/enhancements/pull/1752
• क्यूबलेट के लिए पीआर: WIP

हाय @klueska 👋 1.19 डॉक्स यहाँ छाया! क्या 1.19 के लिए नियोजित इस एन्हांसमेंट कार्य के लिए दस्तावेज़ों में नए या संशोधन की आवश्यकता है?

अनुकूल अनुस्मारक कि यदि दस्तावेज़ों में नए/संशोधन की आवश्यकता है, तो k/वेबसाइट (शाखा dev-1.19 ) के विरुद्ध एक प्लेसहोल्डर पीआर शुक्रवार, जून 12 तक आवश्यक है।

हाय @klueska आशा है कि आप अच्छा कर रहे हैं, यह देखने के लिए फिर से जांच कर रहे हैं कि इसके लिए दस्तावेज़ों की आवश्यकता है या नहीं। क्या आप इस बात की पुष्टि कर सकते है?

हाय @ अन्नाजंग। 2 एन्हांसमेंट लंबित हैं जिनके लिए दोनों को दस्तावेज़ परिवर्तनों की आवश्यकता होगी:

1121

1752

हम अभी भी तय कर रहे हैं कि क्या ये इसे 1.19 कर देंगे या 1.20 पर धकेल दिया जाएगा। यदि हम उन्हें 1.19 तक रखने का निर्णय लेते हैं, तो मैं 12 जून तक दस्तावेज़ों के लिए एक प्लेसहोल्डर पीआर बनाना सुनिश्चित करूँगा।

महान! अपडेट के लिए धन्यवाद, मैं तदनुसार ट्रैकिंग शीट को अपडेट करूंगा! प्लेसहोल्डर पीआर बन जाने के बाद कृपया मुझे बताएं। आपको धन्यवाद!

@lmdaly @ConnorDoyle
मुझे आशा है कि पूछने और कुछ प्रतिक्रिया देने के लिए यहां सही जगह है।

मैं अपने k8s क्लस्टर v1.17 पर TopologyManager और CPUManager चालू करता हूं।
और उनकी नीति best-effort और static
यहाँ मेरे पॉड के संसाधन हैं

      resources:
        requests:
          cpu: 2
          intel.com/sriov_pool_a: '1'
        limits:
          cpu: 2
          intel.com/sriov_pool_a: '1'

sriov_pool_a का पीएफ NUMA नोड 0 में है, इसलिए मुझे उम्मीद है कि मेरा पॉड NUMA नोड 0 के सीपीयू पर भी चलना चाहिए।
लेकिन मैंने पाया कि मेरे पॉड की प्रक्रिया NUMA नोड 1 के सीपीयू पर चल रही है।
साथ ही, taskset -p <pid> के परिणाम के अनुसार कोई सीपीयू एफ़िनिटी मास्क सेट नहीं है।

क्या वहाँ कुछ गड़बड़ है? मुझे उम्मीद है कि कंटेनर में नूमा नोड 0 के सीपीयू के लिए सीपीयू एफ़िनिटी मास्क सेट होना चाहिए।

क्या कोई उदाहरण या परीक्षण है जो मैं यह जानने के लिए कर सकता हूं कि मेरा TopoloyManager ठीक से काम कर रहा है या नहीं?

@annajung प्लेसहोल्डर डॉक्स पीआर जोड़ा गया: https://github.com/kubernetes/website/pull/21607

हाय @klueska ,

सोमवार को के-देव को भेजे गए ईमेल पर अनुवर्ती कार्रवाई के लिए, मैं आपको बताना चाहता हूं कि कोड फ़्रीज़ को गुरुवार, 9 जुलाई तक बढ़ा दिया गया है। आप संशोधित कार्यक्रम यहां देख सकते हैं: https://github.com/kubernetes/sig-release/tree/master/releases/release-1.19
हम उम्मीद करते हैं कि उस समय तक सभी पीआर का विलय हो जाएगा। यदि आपके कोई सवाल हैं तो कृपया मुझे बताएं। मैं

श्रेष्ठ,
कर्स्टन

हाय @klueska , आने वाली अगली समय सीमा का एक अनुकूल अनुस्मारक।
कृपया अपने प्लेसहोल्डर दस्तावेज़ पीआर को पॉप्युलेट करना और सोमवार, 6 जुलाई तक समीक्षा के लिए तैयार करना याद रखें।

धन्यवाद @annajung । चूंकि कोड फ्रीज अब 9 जुलाई को स्थानांतरित कर दिया गया है, क्या डॉक्स तिथि को भी आगे बढ़ाने का कोई मतलब है? क्या होता है यदि हम दस्तावेज़ बनाते हैं, लेकिन सुविधा इसे समय पर नहीं बनाती है (या दस्तावेज़ीकरण के सुझाव के मुकाबले इसे थोड़ा अलग रूप में बनाता है)?

हाय @klueska , यह एक अच्छी बात है! नई रिलीज की तारीख के साथ सभी डॉक्स की समय सीमा भी एक सप्ताह बढ़ा दी गई है, लेकिन मुझे लगता है कि आपके पास एक वैध बिंदु है। मुझे रिलीज़ के लिए डॉक्स लीड से संपर्क करने दें और आपसे संपर्क करें! इस बारे में बताने के लिए शुक्रिया!

हाय @klueska , इसे हमारे ध्यान में लाने के लिए फिर से धन्यवाद। रिलीज के लिए डॉक्स की तारीखों के साथ मिश्रण किया गया है। जैसा कि आपने उल्लेख किया है, "पीआर समीक्षा के लिए तैयार" कोड फ्रीज के बाद आना चाहिए और पिछले रिलीज में होना चाहिए।

हालांकि, रिलीज टीम के साथ बात करने के बाद, हमने "पीआर रेडी फॉर रिव्यू" को एक सॉफ्ट डेडलाइन बनाकर इस 1.19 रिलीज की तारीखों को यथावत रखने का फैसला किया है। डॉक्स टीम लचीली होगी और आपके/अन्य लोगों के साथ काम करेगी, जिन्हें यह सुनिश्चित करने के लिए अतिरिक्त समय की आवश्यकता हो सकती है कि डॉक्स कोड के साथ समन्वयित हैं। जबकि "पीआर समीक्षा के लिए तैयार" समय सीमा लागू नहीं की जाएगी, "पीआर की समीक्षा की गई और मर्ज करने के लिए पढ़ा गया" होगा।

आशा है कि यह आपकी चिंताओं का उत्तर देने में मदद करता है! कृपया मुझे बताएं कि क्या आपके कोई और प्रश्न हैं!

इसके अलावा, तारीखों का सिर्फ एक दोस्ताना अनुस्मारक:
"दस्तावेज़ की समय सीमा - समीक्षा के लिए तैयार पीआर" 6 जुलाई तक है
"दस्तावेज़ पूर्ण - सभी पीआर की समीक्षा की गई और विलय के लिए तैयार" 16 जुलाई तक देय है

हाय @klueska :wave: -- 1.19 एन्हांसमेंट्स लीड यहाँ,

क्या आप कृपया यहां सभी कार्यान्वयन पीआर से लिंक कर सकते हैं, ताकि रिलीज टीम उन्हें ट्रैक कर सके? :थोड़ा_मुस्कुराता_चेहरा:

शुक्रिया।

@palnabarun
पीआर ट्रैकिंग https://github.com/kubernetes/enhancements/pull/1121 यहां पाई जा सकती है:
https://github.com/kubernetes/kubernetes/pull/92665

दुर्भाग्य से एन्हांसमेंट #1752 इसे रिलीज़ में शामिल नहीं करेगा, इसलिए इसे ट्रैक करने के लिए कोई पीआर नहीं है।

हाय @klueska : wave:, मैं देख रहा हूं कि दोनों https://github.com/kubernetes/enhancements/pull/1752 बीटा स्नातक आवश्यकताओं को बढ़ाता है और वे इसे रिलीज़ में शामिल नहीं करेंगे, क्या हम मान सकते हैं कि 1.19 में और कोई परिवर्तन अपेक्षित नहीं हैं?

शुक्रिया। :थोड़ा_मुस्कुराता_चेहरा:

कोड फ़्रीज़ गुरुवार, 9 जुलाई ईओडी पीएसटी से शुरू होता है

@palnabarun यह #92665 पर फॉलो-ऑन पीआर है जो आज या कल उतरना चाहिए: https://github.com/kubernetes/kubernetes/pull/92794

उसके बाद इस रिलीज़ के लिए कोई और पीआर नहीं होना चाहिए, अनपेक्षित बग लंबित हैं।

विस्मयकारी! अद्यतन करने के लिए धन्यवाद। :+1:

हम https://github.com/kubernetes/kubernetes/pull/92794 पर नजर रखेंगे

@annajung https://github.com/kubernetes/website/pull/21607 अब समीक्षा के लिए तैयार है।

बधाई हो @klueska kubernetes/kubernetes#92794 अंत में विलय हो गया है, मैं तदनुसार ट्रैकिंग शीट को अपडेट करूंगा

/ मील का पत्थर स्पष्ट

(इस एन्हांसमेंट इश्यू को v1.19 माइलस्टोन से हटाना क्योंकि माइलस्टोन पूरा हो गया है)

नमस्ते @klueska

संवर्द्धन यहां लीड। क्या इसके लिए 1.20 में स्नातक करने की कोई योजना है?

धन्यवाद!
कर्स्टन

इसके स्नातक होने की कोई योजना नहीं है, लेकिन एक पीआर है जिसे इस वृद्धि से संबंधित 1.20 के लिए ट्रैक किया जाना चाहिए:
https://github.com/kubernetes/kubernetes/pull/92967

हालांकि यह 1.20 में स्नातक नहीं हो रहा है, कृपया इस मुद्दे से संबंधित पीआर को लिंक करना जारी रखें जैसा आपने अभी किया है।

@kikisdeliveryservice क्या आप कृपया प्रक्रिया को समझने में मदद कर सकते हैं। टोपोलॉजी मैनेजर फीचर 1.20 में ग्रेजुएशन नहीं कर रहा है, लेकिन इसमें नया फीचर जोड़ा जाएगा और अभी इस पर काम किया जा रहा है: https://github.com/kubernetes/enhancements/pull/1752 k/k: https://github. कॉम/कुबेरनेट्स/कुबेरनेट्स/पुल/92967. क्या यह कुछ ऐसा है जिसे हमें रिलीज टीम के साथ ट्रैक करने की आवश्यकता है? यह 1.20 के लिए डॉक्स अपडेट को ट्रैक करना आसान बना सकता है या शायद कुछ और जिसे ट्रैक किया जा रहा है।

परिवर्तन योगात्मक है इसलिए इसे बीटा 2 या कुछ और कहने का कोई कारण नहीं है।

संबंधित बम्प पीआर जो वास्तविकता को दर्शाता है कि अतिरिक्त सुविधा 1.19 में शिप नहीं की गई थी: https://github.com/kubernetes/enhancements/pull/1950

टोपोलॉजी मैनेजर वेब डॉक्यूमेंटेशन पीआर को स्कोप फीचर को शामिल करने के लिए अपडेट करता है: https://github.com/kubernetes/website/pull/24781

मेरा मानना ​​​​है कि इसे 1.20 के साथ ट्रैक किया जा सकता है और जरूरी नहीं कि इसे स्नातक करने की आवश्यकता हो। @kikisdeliveryservice कृपया झंकार करें यदि यह सही नहीं है। मैं 1.20 रिलीज के हिस्से के रूप में साझा किए गए k/वेबसाइट को तब तक ट्रैक करूंगा जब तक कि मैं अन्यथा नहीं सुनता।

नमस्ते @SergeyKanzhelev

इतिहास को देखें तो वास्तव में ऐसा नहीं है। मुझे बताया गया था कि यह ऊपर स्नातक नहीं होगा, जो ठीक है और इस केईपी को ट्रैक क्यों नहीं किया गया है। हालाँकि, इस एन्हांसमेंट (एन्हांसमेंट टीम के लिए अनजान) को हाल ही में @k-wiatrzyk द्वारा 1.20 के लिए बीटा (https://github.com/kubernetes/enhancements/pull/1950) के रूप में पुनः लक्षित किया गया था।

यदि आप रिलीज़ प्रक्रिया का लाभ उठाना चाहते हैं: एन्हांसमेंट ट्रैकिंग, रिलीज़ माइलस्टोन का एक हिस्सा होने के नाते और डॉक्स टीम द्वारा इसे ट्रैक करना/दस्तावेज़ों को 1.20 रिलीज़ में शामिल करना, एक एन्हांसमेंट अपवाद अनुरोध ASAP दायर किया जाना चाहिए।

सुविधा पहले से ही (पूर्व-मौजूदा) केईपी (वृद्धि की समय सीमा से पहले) में विलय कर दी गई थी।
https://github.com/kubernetes/enhancements/pull/1752

इसके कार्यान्वयन पर पीआर पहले से ही मील के पत्थर का हिस्सा है।
https://github.com/kubernetes/kubernetes/pull/92967

मुझे पता नहीं था कि और कुछ करना बाकी है।

हमें किसके साथ अपवाद दर्ज करने की आवश्यकता है, और वास्तव में किसके लिए?

हाय @klueska जिस जनसंपर्क का आप संदर्भ दे रहे हैं, उसे जून में 1.19 में https://github.com/bg-chun/enhancements/blob/f3df83cc997ff49bfbb59414545c3e4002796f19/keps/sig-node/0035-20190130- टोपोलॉजी -manager.md#बीटा -v119

1.20 के लिए एन्हांसमेंट की समय सीमा 6 अक्टूबर थी, लेकिन परिवर्तन, बीटा को 1.20 पर ले जाना और 1.19 के संदर्भ को हटाकर 3 दिन पहले https://github.com/kubernetes/enhancements/pull/1950 के माध्यम से विलय कर दिया गया था।

आप यहां अपवाद अनुरोध भेजने के लिए निर्देश पा सकते हैं: https://github.com/kubernetes/sig-release/blob/master/releases/EXCEPTIONS.md

क्षमा करें, मैं अभी भी असमंजस में हूं कि हम किसके लिए अपवाद दर्ज करेंगे।
मुझे यह करने में खुशी हो रही है, मुझे यकीन नहीं है कि इसमें क्या शामिल किया जाए।

"नोड टोपोलॉजी मैनेजर" फीचर पहले ही 1.18 में बीटा में बदल चुका है।
यह 1.20 में जीए में स्नातक नहीं हो रहा है (यह बीटा में रह रहा है)।

1.20 (यानी कुबेरनेट्स/कुबेरनेट्स#92967) के लिए पीआर का विलय किया जाना टोपोलॉजी मैनेजर के लिए मौजूदा कोड में सुधार है, लेकिन यह अल्फा/बीटा/जीए आदि के रूप में अपनी स्थिति के संदर्भ में "टक्कर" से संबंधित नहीं है।

मैंने एक अपवाद मेल भेजा है क्योंकि समय सीमा आज है (बस मामले में): https://groups.google.com/g/kubernetes-sig-node/c/lsy0fO6cBUY/m/_ujNkQtCCQAJ

@kikisdeliveryservice @klueska @annajung
अपवाद के लिए कॉल को मंजूरी दी गई थी, आप यहां पुष्टिकरण पा सकते हैं: https://groups.google.com/g/kubernetes-sig-release/c/otE2ymBKeMA/m/ML_HMQO7BwAJ

धन्यवाद @k-wiatrzyk & @klueska ने ट्रैकिंग शीट को अपडेट किया।

सीसी: @ अन्नाजंग

अरे @k-wiatrzyk @klueska

ऐसा लगता है कि Kubernetes/kubernetes#92967 स्वीकृत हो गया है, लेकिन एक रिबेस की आवश्यकता है।

बस एक अनुस्मारक कि कोड फ़्रीज़ 2 दिनों में गुरुवार, नवंबर 12 पर आ रहा है। सभी पीआर को उस तिथि तक मर्ज कर दिया जाना चाहिए, अन्यथा एक अपवाद की आवश्यकता है।

श्रेष्ठ,
कर्स्टन

पीआर विलय, अद्यतन पत्रक - याय! : मुस्कान_बिल्ली: