[RA2 Ch04]: Networking part of Ch4 in RA2 #821

CsatariGergely · 2019-12-20T09:52:52Z

No description provided.

doc/ref_arch/kubernetes/chapters/chapter04.md

walterkozlowski · 2019-12-23T09:18:33Z

I agree we should not impose it. For instance, I would opt for Calico+Maltus for my implementation. But this should not be mandated but the use of CNI plugins should be. Walter Kozlowski Architecture & Strategy Principal Converged Cloud & Infrastructure Principal Networks and IT Telstra +61 407 724 612

________________________________ From: Manik Sidana <notifications@github.com> Sent: Monday, December 23, 2019 8:03:28 PM To: cntt-n/CNTT <CNTT@noreply.github.com> Cc: Kozlowski, Walter <Walter.Kozlowski@team.telstra.com>; Review requested <review_requested@noreply.github.com> Subject: Re: [cntt-n/CNTT] [RA2 Ch04]: Networking part of Ch4 in RA2 (#821) [External Email] This email was sent from outside the organisation – be cautious, particularly with links and attachments. @msidana commented on this pull request.

________________________________ In doc/ref_arch/kubernetes/chapters/chapter04.md<#821 (comment)>:

@@ -38,7 +38,10 @@

<a name="4.5"></a> ## 4.5 CNI plugins -> This chapter should describe which CNI plugins are part of the Rerefence Architecture. +The used CNI multiplexer/metapulgin must be [DANM](https://github.com/nokia/danm) with [Calico](https://github.com/projectcalico/cni-plugin) as the CNI what complies with the basic networking assumptions of Kubernetes. Question: Do we need to impose the use of Calico and DANM via this MUST clause ? There are other options as well like Multus+Calico, Cilium, CNI-Genie etc. Any criteria for shortlisting of DANM and calico specifically ? — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub<#821>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AMONQFYCR6Z7DQ3Z7ATV2K3Q2B5GBANCNFSM4J53N3UQ>.

tomkivlin

I'll mark as approved as once @msidana's comments are resolved I'm happy.

This change adds references to the different requirements from Ch01.

walterkozlowski

My comments have not been addressed either. I do not understand why Nokia's DAMN solution is mandated here, versus for example Maltus. We have to discuss and decide if we either mandate one set of CNI plug-ins (in that case Maltus is a much more common and implemented in many reference architectures), or we leave few options for implementation. I would opt to start with the most common, and simplest, which in my view would be Maltus with Flannel, and then start adding others. In any case, this is where perhaps we should have a discussion internally but also with the Kubernetes group?

msidana · 2019-12-30T04:43:53Z

My comments have not been addressed either. I do not understand why Nokia's DAMN solution is mandated here, versus for example Maltus. We have to discuss and decide if we either mandate one set of CNI plug-ins (in that case Maltus is a much more common and implemented in many reference architectures), or we leave few options for implementation. I would opt to start with the most common, and simplest, which in my view would be Maltus with Flannel, and then start adding others. In any case, this is where perhaps we should have a discussion internally but also with the Kubernetes group?

I agree with @walterkozlowski . I have nothing against DAMN or a particular solution but there should be a reasoning in the document on how and why we selected DANM/MULTUS. Once that is answered, we should also have a description of the REASON for selecting CALICO.

tomkivlin · 2019-12-30T09:34:25Z

doc/ref_arch/kubernetes/chapters/chapter04.md

+The used CNI multiplexer/metapulgin must be [DANM](https://github.com/nokia/danm)
+as it provides the possibility to use several other CNI plugins (`req.inf.ntw.16`) and provides an API based solution to administer the networks (`req.inf.ntw.10`) from a central point (`req.inf.ntw.11`).
+ [Calico](https://github.com/projectcalico/cni-plugin) must be used as the CNI what complies with the basic networking assumptions of Kubernetes based on the requirement `req.inf.ntw.02`.
+For the network of signalling connections the built in IPVLAN CNI of DANM must be used as it provides NAT-less connectivity (`req.inf.ntw.03`). For the user plane network(s) fullfilling requirement `req.inf.ntw.04` the [User Space CNI](https://github.com/intel/userspace-cni-network-plugin) must be used.


@CsatariGergely thanks for this - it's helpful. What would make this complete, for me, is for the reasons that the alternatives (i.e. Multus, Flannel, etc.) are able to meet the requirements, as that is the unanswered question left open here.

@tomkivlin is there anything still open here?

For Multus v DANM, yes. For the Calico part, I don't think it's as simple-a-comparison. For example, Flannel and Calico together (/canal) could deliver the requirements, yes? And there are other CNI plugins that also support NetworkPolicy such as Cilium and Weave Net.

TBH I don't think Canal is actively maintained by anyone, or is widely used
Agree Cilium could be an interesting alternative, however does its NP implementation work if your traffic is not in L7?

CsatariGergely · 2019-12-31T11:39:27Z

My comments have not been addressed either. I do not understand why Nokia's DAMN solution is mandated here, versus for example Maltus. We have to discuss and decide if we either mandate one set of CNI plug-ins (in that case Maltus is a much more common and implemented in many reference architectures), or we leave few options for implementation. I would opt to start with the most common, and simplest, which in my view would be Maltus with Flannel, and then start adding others. In any case, this is where perhaps we should have a discussion internally but also with the Kubernetes group?

I hoped, that my references to the requirements satisfied your comments. Would it be okay if I add a comparision table of DANM and Multus features in reference to the requirements? Can you please refer to the many reference architectures where Multus is implemented? I'm only aware of the KNI Blueprint family in Akraino what is similar to DANM's presence in the Akraino REC blueprint.

Due to requests in comments this change adds a comparision table of the relevant requirements and additional features of DANM and Multus.

petorre · 2020-01-02T11:42:50Z

Can you please refer to the many reference architectures where Multus is implemented? I'm only aware of the KNI Blueprint family in Akraino what is similar to DANM's presence in the Akraino REC blueprint.

In products from Red Hat, Ericsson and several other vendors.

CsatariGergely · 2020-01-02T16:51:29Z

Can you please refer to the many reference architectures where Multus is implemented? I'm only aware of the KNI Blueprint family in Akraino what is similar to DANM's presence in the Akraino REC blueprint.

In products from Red Hat, Ericsson and several other vendors.

I would rather call these vendor specific implementations and not reference architectures.

Levovar · 2020-01-06T11:39:22Z

doc/ref_arch/kubernetes/chapters/chapter04.md

+| Service based dicovery of all provisioned interfaces | Not supported | Supported |
+
+ [Calico](https://github.com/projectcalico/cni-plugin) must be used as the CNI what complies with the basic networking assumptions of Kubernetes based on the requirement `req.inf.ntw.02` due to it's capability to handle `NetworkPolicies`, what is missing from [Flannel](https://github.com/coreos/flannel-cni).
+For the network of signalling connections the built in IPVLAN CNI of DANM must be used as it provides NAT-less connectivity (`req.inf.ntw.03`). For the user plane network(s) fullfilling requirement `req.inf.ntw.04` the [User Space CNI](https://github.com/intel/userspace-cni-network-plugin) must be used.


IMO MACVLAN is as valid as IPVLAN, depends on whether CNF requires L2, or L3 unique addresses

Levovar · 2020-01-06T11:40:24Z

doc/ref_arch/kubernetes/chapters/chapter04.md

+
+ [Calico](https://github.com/projectcalico/cni-plugin) must be used as the CNI what complies with the basic networking assumptions of Kubernetes based on the requirement `req.inf.ntw.02` due to it's capability to handle `NetworkPolicies`, what is missing from [Flannel](https://github.com/coreos/flannel-cni).
+For the network of signalling connections the built in IPVLAN CNI of DANM must be used as it provides NAT-less connectivity (`req.inf.ntw.03`). For the user plane network(s) fullfilling requirement `req.inf.ntw.04` the [User Space CNI](https://github.com/intel/userspace-cni-network-plugin) must be used.
+


and I maintain that SR-IOV Device Plugin managed VFs are must haves :)

in anycase, userspace CNI in itself is nothing. we might need to elaborate which backend we want to use behind it: OVS-DPDK, or VPP

Levovar · 2020-01-06T11:58:18Z

Even me as DANM author am not a fan of hardcoding implementation choices into an arch spec :)
Though I sincerely believe my solution supports more features than the others, but each to its own. All have merits, and popularity definitely became a technical attribute in recent years. I'm sure at some point Multus will be able to copy the missing extra features too.

Food for thought for Multus operators tho: how do you make sure in a K8s environment equipped with Multus that no CNFs can overstep their boundaries?
Let's say IPVLAN/MACVLAN is also supported in the same environment, as outlined by this document. What's stopping me as a CNF from creating an IPVLAN/MACVLAN type CRD using any VNI, subnet, or host device I want?
Let's say host-device CNI is also supported. Same question: how do you stop the CNF from taking away a whole PF from the host network namespace? For example the one dedicated for infra traffic.
The only answer I could ever come up with is "well, I don't allow CNFs to access network management API at all via RBAC" but then your LCM operations got way more complex - possibly multiple Helm charts per every CNF, constant need for tenant and cluster admin intervention etc.

BTW do we have a requirement for these security issues? Something like "CNI shall be able to reject CNF requests related to protected network resources"

Addressing incoming comments this change adds the option to use MACVLAN CNI, lists the backend options for the User Space CNi and adds the SR-IOV Device Plugin to the SR-IOV related note.

walterkozlowski

Still requires discussion and changes in my view. We cannot mandate "must" one vendor proprietary CNI plug-in.

tomkivlin · 2020-01-09T13:55:10Z

Still requires discussion and changes in my view. We cannot mandate "must" one vendor proprietary CNI plug-in.

My proposal is this: rather than avoiding a merge until all potential options are listed, @CsatariGergely could you modify the wording to suggest future additions can be made, e.g. "Here are the CNI plugins that conform:" and list what you have now. We can then raise subsequent PRs to add to the list, rather than waiting until all the options are ready to list before merging. @walterkozlowski would that be ok with you?

tomkivlin

As suggested in previous comment, modify wording to imply future additions to a list can be made.

walterkozlowski · 2020-01-09T13:57:56Z

Tom Yes, this is a good way out of this a bit stalemate situation, I agree. Regs Walter From: Tom Kivlin <notifications@github.com> Sent: Friday, 10 January 2020 12:55 AM To: cntt-n/CNTT <CNTT@noreply.github.com> Cc: Kozlowski, Walter <Walter.Kozlowski@team.telstra.com>; Mention <mention@noreply.github.com> Subject: Re: [cntt-n/CNTT] [RA2 Ch04]: Networking part of Ch4 in RA2 (#821) [External Email] This email was sent from outside the organisation – be cautious, particularly with links and attachments. Still requires discussion and changes in my view. We cannot mandate "must" one vendor proprietary CNI plug-in. My proposal is this: rather than avoiding a merge until all potential options are listed, @CsatariGergely<https://github.com/CsatariGergely> could you modify the wording to suggest future additions can be made, e.g. "Here are the CNI plugins that conform:" and list what you have now. We can then raise subsequent PRs to add to the list, rather than waiting until all the options are ready to list before merging. @walterkozlowski<https://github.com/walterkozlowski> would that be ok with you? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#821>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AMONQFZEF2NULI2YCL64CHDQ44UD7ANCNFSM4J53N3UQ>.

tomkivlin · 2020-01-09T14:06:02Z

@walterkozlowski great. @CsatariGergely would you be ok to make the suggested change, or shall I?

CsatariGergely · 2020-01-09T14:13:04Z

@walterkozlowski is it okay if I add an editors note saying:
"> Editors note: The following chapter lists a set of CNI plugins compliant with the Reference Architecture. The list of compliant components might change in future releases." ?

As we were not able to agree on the set of CNI plugins this change adds a note that the list can be changed in the future.

tomkivlin · 2020-01-09T15:38:51Z

@walterkozlowski if you're able to approve this in your morning, we can look to merge, thanks.

msidana · 2020-01-09T15:45:14Z

@walterkozlowski is it okay if I add an editors note saying:
"> Editors note: The following chapter lists a set of CNI plugins compliant with the Reference Architecture. The list of compliant components might change in future releases." ?

Can we also remove the MUST here and change it to MAY, rephrasing The used CNI multiplexer/metapulgin must be DANM ..to something like CNI multiplexer/metapulgin like Multus, DANM etc may be used... so that the RA doesn't enforces a particular choice.

walterkozlowski · 2020-01-10T02:44:37Z

I agree with @msidana and I asked before for changing MUST to MAY in relation to use DAMN. @CsatariGergely can you please change it so we can approve it.

walterkozlowski · 2020-01-10T03:04:55Z

I have not approved as I have not seen any changes. Looks to me like still DAMN is mandated as MUST. AM I looking at the wrong spot? Regards Walter From: Tom Kivlin <notifications@github.com> Sent: Friday, 10 January 2020 2:39 AM To: cntt-n/CNTT <CNTT@noreply.github.com> Cc: Kozlowski, Walter <Walter.Kozlowski@team.telstra.com>; Mention <mention@noreply.github.com> Subject: Re: [cntt-n/CNTT] [RA2 Ch04]: Networking part of Ch4 in RA2 (#821) [External Email] This email was sent from outside the organisation – be cautious, particularly with links and attachments. @walterkozlowski<https://github.com/walterkozlowski> if you're able to approve this in your morning, we can look to merge, thanks. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#821>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AMONQF7IAA53ZM3WQX2Q4JTQ45AIZANCNFSM4J53N3UQ>.

This change switches the "must" statements regarding to CNI-s to "may" statements and adds a cladification text to the related editors note how this will be fixed in the next releases.

CsatariGergely · 2020-01-10T06:13:47Z

I have not approved as I have not seen any changes. Looks to me like still DAMN is mandated as MUST. AM I looking at the wrong spot? Regards Walter From: Tom Kivlin notifications@github.com Sent: Friday, 10 January 2020 2:39 AM To: cntt-n/CNTT CNTT@noreply.github.com Cc: Kozlowski, Walter Walter.Kozlowski@team.telstra.com; Mention mention@noreply.github.com Subject: Re: [cntt-n/CNTT] [RA2 Ch04]: Networking part of Ch4 in RA2 (#821) [External Email] This email was sent from outside the organisation – be cautious, particularly with links and attachments. @walterkozlowski https://github.com/walterkozlowski if you're able to approve this in your morning, we can look to merge, thanks. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#821?email_source=notifications&email_token=AMONQF7BWR7HSN4PLGOGK5LQ45AIZA5CNFSM4J53N3U2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIQXAUA#issuecomment-572616784>, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AMONQF7IAA53ZM3WQX2Q4JTQ45AIZANCNFSM4J53N3UQ.

I've added the editors note what we agreed on the meeting...

CsatariGergely · 2020-01-10T06:16:38Z

@walterkozlowski is it okay if I add an editors note saying:
"> Editors note: The following chapter lists a set of CNI plugins compliant with the Reference Architecture. The list of compliant components might change in future releases." ?

Can we also remove the MUST here and change it to MAY, rephrasing The used CNI multiplexer/metapulgin must be DANM ..to something like CNI multiplexer/metapulgin like Multus, DANM etc may be used... so that the RA doesn't enforces a particular choice.

As we already discussed it is the target of the RA to enforce a particular choice. For the current release I've softened the musts to mays for the CNI plugins, but in a later release we shall be able to agree on a set.

petorre · 2020-01-10T16:00:57Z

As we already discussed it is the target of the RA to enforce a particular choice. For the current release I've softened the musts to mays for the CNI plugins, but in a later release we shall be able to agree on a set.

I agree with this.
While prioritizing the choices into Must, we should look into already defined principles of Interoperability in relevant timeframe.

tomkivlin · 2020-01-10T16:25:42Z

Given the changes @CsatariGergely has made in line with requests from @walterkozlowski, myself and others, I will mark this as ready to be merged for the Snezka release. Of course subsequent Issues can be created and added to the RA2 Core Backlog (just use the Backlog label and the RA2 Core project when creating the issue, the rest is automated).

@collivier

* RA2 Ch4 - Host OS, Kubernetes, Container Runtime and Storage content (#874) * RA2 Ch04 Initial Content * Update chapter04.md * RA2 Ch4 - HA notes * RA2 Ch4 move content to Ch3 Host OS description * RA2 Ch4 - updates to 4.2, 4.3, 4.4 Updates to Host OS, Kubernetes, Runtimes sections * RA2 Ch4 - add more detail * RA2 Ch4 storage updates Storage updates, added OCI and changed status. * RA2 Ch3 - typo correction 4-1 --> 3-1 * RA2 Ch4 - typos and updates Typos and added note about etcd not running on worker nodes. * RA2 Ch4 - added note about kubeadm kubeadm driving Host OS versions * RA2 Ch4 - remove rkt Archived by CNCF * RA2 Ch4 - remove note about Kata/gVisor * RA2 Ch4 - update kubernetes version statement added content to row60 * Update to 4.2 and Table 4-1 - remove specific operating systems and focus on kernel versions. * RA2 Ch3 - typo correction row54 * RA2 Ch4 - remove linux 4+ as redundant * RA2 Ch4 - update to k8s version spec row54 * RA2 Ch4 - 4.2 changes row34/35 * RA2 Ch4 - merge conflict * [RA2 Ch04]: Networking part of Ch4 in RA2 (#821) * Initial commmit of the networking part of Ch4 in RA2 * Adding references to requirements This change adds references to the different requirements from Ch01. * Comparision between DANM and Multus added Due to requests in comments this change adds a comparision table of the relevant requirements and additional features of DANM and Multus. * Adding MACVLAN and User Space CNI backend options Addressing incoming comments this change adds the option to use MACVLAN CNI, lists the backend options for the User Space CNi and adds the SR-IOV Device Plugin to the SR-IOV related note. * Add an eitors note about the list of CNI plugins As we were not able to agree on the set of CNI plugins this change adds a note that the list can be changed in the future. * Must -> may for CNI-s This change switches the "must" statements regarding to CNI-s to "may" statements and adds a cladification text to the related editors note how this will be fixed in the next releases. * [RA-1 Ch02] update to handle multiple issues (#558) * [RA-1 Ch02] update to handle multiple issues PR covers Issues #266, #314, #339 and #435 * [RA-1 Ch02] Updated [RA-1 Ch02] Updated to resolve valuable feedback from multiple folks and @collivier suggested changes to Block storage and networking. Resolves Issues #266, #314, #339 and #435 * [RA-1 Ch02] Resolve Issues [RA-1 Ch02] Resolve Issues Changes to 'req.inf.com.08' and add 'req.inf.com.09' * [RA-1 Ch02] Resolve "remote Block Storage" Changed: | `req.inf.stg.01` | Storage | The Architecture **must** provide remote (not directly attached to the host) Block storage for VM Instances. | |--------|-------|------------------------| * [RA-1 Ch02} Resolve 2.3 Architecture introduction [RA-1 Ch02} Resolve 2.3 Architecture introduction as per @CsatariGergely * [RA-1 Ch02] Commented out req.sec.ntw.01/02 [RA-1 Ch02] Commented out req.sec.ntw.01 and req.sec.ntw.02 Co-authored-by: Rabi Abdel <45387599+rabiabdel@users.noreply.github.com> * [RA1 Ch08] Add gaps in openstack release ocata, pike and stein (#843) * [RI1 Ch08] Add gaps in openstack release ocata, pike and stein * Add API versions * Add features of pike and stein * Add upgrade check for Stein Fixes #842 * Add nova features * Fix JWT short form and remaining services * Update table of content * Move into RA-8 from RI-8 * Delete Deprecated Annex (#933) * [RI Ch07] Sridhar ch7 sec5and6 (#931) * Chapter-7: Section 5 and 6. Adding contents from Sections 5 and 6 of Chapter-7 Signed-off-by: Sridhar K. N. Rao <sridhar.rao@spirent.com> * Fixed Typos and removed wrong special chars. Signed-off-by: Sridhar K. N. Rao <sridhar.rao@spirent.com> Co-authored-by: Rabi Abdel <51988225+rabi-abdel@users.noreply.github.com> * [RC1] Fill all gaps already tracked as issues in CNTT (#918) * Fill all gaps already tracked as issues in CNTT Port VTP test cases to Xtesting [1] is key because the TC doesn't conform to the principles and requirements defined. #917 Signed-off-by: Cédric Ollivier <cedric.ollivier@orange.com> * Precise the gaps to avoid confusion Signed-off-by: Cédric Ollivier <cedric.ollivier@orange.com> * Add tab for the new TC Signed-off-by: Cédric Ollivier <cedric.ollivier@orange.com> * [RA-1 Ch04] Update Figure 4-1 (#927) * [RA-1 Ch04] Update Figure 4-1 [RA-1 Ch04] @iangardner22 Updated Figure 4-1 and added network descriptions (I am making the changes on behalf of @iangardner22) * [RA-1 Ch04] Upload latest version of Figure 4-1 [RA-1 Ch04] Upload latest version of Figure 4-1 * [RA-1 Ch04] Re upload of new Figure 4-1 [RA-1 Ch04] Re upload of new Figure 4-1 * [RA-1 Ch04] Delete Figure_4_1_OpenStack_Network_Layout_20200110 [RA-1 Ch04] Delete Figure_4_1_OpenStack_Network_Layout_20200110 -- will be updated with modified version * [RA-1 Ch04] Upload corrected version of Figure 4-1 * [WIP] [RI Ch07] Update Deployment Cookbook (#817) * Topology Diagram Description of lab topology, aligning with OPNFV Pharos. Signed-off-by: beierl <mbeierl@vmware.com> #406 * [RI1 Ch06]i Topology Diagram Description of lab topology, aligning with OPNFV Pharos. Signed-off-by: beierl <mbeierl@vmware.com> * [WIP] [RI Ch07] Update Deployment Cookbook #797 * Create path for Airship vs. future installers * Adds requirements Added section on hardware used and information about how to get VPN access and what routes are available. * Adds requirements Added section on hardware used and information about how to get VPN access and what routes are available. * Revert "Adds requirements" This reverts commit b25e762. * Changes to Ch 07 only Cleanup of chapter 6 in this PR so that it does not interfere with any other PR. * Changes to Ch 07 only Cleanup of chapter 6 in this PR so that it does not interfere with any other PR. Co-authored-by: Rabi Abdel <45387599+rabiabdel@users.noreply.github.com> * [RC] One missing word (nit) (#934) Signed-off-by: Cédric Ollivier <cedric.ollivier@orange.com> Co-authored-by: Tom Kivlin <52716470+tomkivlin@users.noreply.github.com> Co-authored-by: Gergely Csatari <gergely.csatari@nokia.com> Co-authored-by: Pankaj Goyal <52107136+pgoyal01@users.noreply.github.com> Co-authored-by: Deepanshu Bhatia <deep23bhatia@gmail.com> Co-authored-by: Mark Shostak (AT&T) <49962775+markshostak@users.noreply.github.com> Co-authored-by: Sridhar K N Rao <ngignir@gmail.com> Co-authored-by: Rabi Abdel <51988225+rabi-abdel@users.noreply.github.com> Co-authored-by: collivier <ollivier.cedric@gmail.com> Co-authored-by: Mark Beierl <mbeierl@vmware.com>

@collivier

* Preperatin for Snezka release * sync (#935) * RA2 Ch4 - Host OS, Kubernetes, Container Runtime and Storage content (#874) * RA2 Ch04 Initial Content * Update chapter04.md * RA2 Ch4 - HA notes * RA2 Ch4 move content to Ch3 Host OS description * RA2 Ch4 - updates to 4.2, 4.3, 4.4 Updates to Host OS, Kubernetes, Runtimes sections * RA2 Ch4 - add more detail * RA2 Ch4 storage updates Storage updates, added OCI and changed status. * RA2 Ch3 - typo correction 4-1 --> 3-1 * RA2 Ch4 - typos and updates Typos and added note about etcd not running on worker nodes. * RA2 Ch4 - added note about kubeadm kubeadm driving Host OS versions * RA2 Ch4 - remove rkt Archived by CNCF * RA2 Ch4 - remove note about Kata/gVisor * RA2 Ch4 - update kubernetes version statement added content to row60 * Update to 4.2 and Table 4-1 - remove specific operating systems and focus on kernel versions. * RA2 Ch3 - typo correction row54 * RA2 Ch4 - remove linux 4+ as redundant * RA2 Ch4 - update to k8s version spec row54 * RA2 Ch4 - 4.2 changes row34/35 * RA2 Ch4 - merge conflict * [RA2 Ch04]: Networking part of Ch4 in RA2 (#821) * Initial commmit of the networking part of Ch4 in RA2 * Adding references to requirements This change adds references to the different requirements from Ch01. * Comparision between DANM and Multus added Due to requests in comments this change adds a comparision table of the relevant requirements and additional features of DANM and Multus. * Adding MACVLAN and User Space CNI backend options Addressing incoming comments this change adds the option to use MACVLAN CNI, lists the backend options for the User Space CNi and adds the SR-IOV Device Plugin to the SR-IOV related note. * Add an eitors note about the list of CNI plugins As we were not able to agree on the set of CNI plugins this change adds a note that the list can be changed in the future. * Must -> may for CNI-s This change switches the "must" statements regarding to CNI-s to "may" statements and adds a cladification text to the related editors note how this will be fixed in the next releases. * [RA-1 Ch02] update to handle multiple issues (#558) * [RA-1 Ch02] update to handle multiple issues PR covers Issues #266, #314, #339 and #435 * [RA-1 Ch02] Updated [RA-1 Ch02] Updated to resolve valuable feedback from multiple folks and @collivier suggested changes to Block storage and networking. Resolves Issues #266, #314, #339 and #435 * [RA-1 Ch02] Resolve Issues [RA-1 Ch02] Resolve Issues Changes to 'req.inf.com.08' and add 'req.inf.com.09' * [RA-1 Ch02] Resolve "remote Block Storage" Changed: | `req.inf.stg.01` | Storage | The Architecture **must** provide remote (not directly attached to the host) Block storage for VM Instances. | |--------|-------|------------------------| * [RA-1 Ch02} Resolve 2.3 Architecture introduction [RA-1 Ch02} Resolve 2.3 Architecture introduction as per @CsatariGergely * [RA-1 Ch02] Commented out req.sec.ntw.01/02 [RA-1 Ch02] Commented out req.sec.ntw.01 and req.sec.ntw.02 Co-authored-by: Rabi Abdel <45387599+rabiabdel@users.noreply.github.com> * [RA1 Ch08] Add gaps in openstack release ocata, pike and stein (#843) * [RI1 Ch08] Add gaps in openstack release ocata, pike and stein * Add API versions * Add features of pike and stein * Add upgrade check for Stein Fixes #842 * Add nova features * Fix JWT short form and remaining services * Update table of content * Move into RA-8 from RI-8 * Delete Deprecated Annex (#933) * [RI Ch07] Sridhar ch7 sec5and6 (#931) * Chapter-7: Section 5 and 6. Adding contents from Sections 5 and 6 of Chapter-7 Signed-off-by: Sridhar K. N. Rao <sridhar.rao@spirent.com> * Fixed Typos and removed wrong special chars. Signed-off-by: Sridhar K. N. Rao <sridhar.rao@spirent.com> Co-authored-by: Rabi Abdel <51988225+rabi-abdel@users.noreply.github.com> * [RC1] Fill all gaps already tracked as issues in CNTT (#918) * Fill all gaps already tracked as issues in CNTT Port VTP test cases to Xtesting [1] is key because the TC doesn't conform to the principles and requirements defined. #917 Signed-off-by: Cédric Ollivier <cedric.ollivier@orange.com> * Precise the gaps to avoid confusion Signed-off-by: Cédric Ollivier <cedric.ollivier@orange.com> * Add tab for the new TC Signed-off-by: Cédric Ollivier <cedric.ollivier@orange.com> * [RA-1 Ch04] Update Figure 4-1 (#927) * [RA-1 Ch04] Update Figure 4-1 [RA-1 Ch04] @iangardner22 Updated Figure 4-1 and added network descriptions (I am making the changes on behalf of @iangardner22) * [RA-1 Ch04] Upload latest version of Figure 4-1 [RA-1 Ch04] Upload latest version of Figure 4-1 * [RA-1 Ch04] Re upload of new Figure 4-1 [RA-1 Ch04] Re upload of new Figure 4-1 * [RA-1 Ch04] Delete Figure_4_1_OpenStack_Network_Layout_20200110 [RA-1 Ch04] Delete Figure_4_1_OpenStack_Network_Layout_20200110 -- will be updated with modified version * [RA-1 Ch04] Upload corrected version of Figure 4-1 * [WIP] [RI Ch07] Update Deployment Cookbook (#817) * Topology Diagram Description of lab topology, aligning with OPNFV Pharos. Signed-off-by: beierl <mbeierl@vmware.com> #406 * [RI1 Ch06]i Topology Diagram Description of lab topology, aligning with OPNFV Pharos. Signed-off-by: beierl <mbeierl@vmware.com> * [WIP] [RI Ch07] Update Deployment Cookbook #797 * Create path for Airship vs. future installers * Adds requirements Added section on hardware used and information about how to get VPN access and what routes are available. * Adds requirements Added section on hardware used and information about how to get VPN access and what routes are available. * Revert "Adds requirements" This reverts commit b25e762. * Changes to Ch 07 only Cleanup of chapter 6 in this PR so that it does not interfere with any other PR. * Changes to Ch 07 only Cleanup of chapter 6 in this PR so that it does not interfere with any other PR. Co-authored-by: Rabi Abdel <45387599+rabiabdel@users.noreply.github.com> * [RC] One missing word (nit) (#934) Signed-off-by: Cédric Ollivier <cedric.ollivier@orange.com> Co-authored-by: Tom Kivlin <52716470+tomkivlin@users.noreply.github.com> Co-authored-by: Gergely Csatari <gergely.csatari@nokia.com> Co-authored-by: Pankaj Goyal <52107136+pgoyal01@users.noreply.github.com> Co-authored-by: Deepanshu Bhatia <deep23bhatia@gmail.com> Co-authored-by: Mark Shostak (AT&T) <49962775+markshostak@users.noreply.github.com> Co-authored-by: Sridhar K N Rao <ngignir@gmail.com> Co-authored-by: Rabi Abdel <51988225+rabi-abdel@users.noreply.github.com> Co-authored-by: collivier <ollivier.cedric@gmail.com> Co-authored-by: Mark Beierl <mbeierl@vmware.com> * resolve conflicts in Ch07 * Update README.md * erevert * update version number Co-authored-by: Rabi Abdel <45387599+rabiabdel@users.noreply.github.com> Co-authored-by: Tom Kivlin <52716470+tomkivlin@users.noreply.github.com> Co-authored-by: Gergely Csatari <gergely.csatari@nokia.com> Co-authored-by: Pankaj Goyal <52107136+pgoyal01@users.noreply.github.com> Co-authored-by: Deepanshu Bhatia <deep23bhatia@gmail.com> Co-authored-by: Mark Shostak (AT&T) <49962775+markshostak@users.noreply.github.com> Co-authored-by: Sridhar K N Rao <ngignir@gmail.com> Co-authored-by: collivier <ollivier.cedric@gmail.com> Co-authored-by: Mark Beierl <mbeierl@vmware.com>

Initial commmit of the networking part of Ch4 in RA2

02d018b

CsatariGergely requested review from rabiabdel and tomkivlin as code owners December 20, 2019 09:52

github-actions bot added Ch 04 labels Dec 20, 2019

CsatariGergely changed the title ~~Networking part of Ch4 in RA2~~ [RA2 Ch04]: Networking part of Ch4 in RA2 Dec 20, 2019

rabi-abdel requested review from deebhatia, TamasZsiros and walterkozlowski December 23, 2019 08:24

msidana reviewed Dec 23, 2019

View reviewed changes

doc/ref_arch/kubernetes/chapters/chapter04.md Outdated Show resolved Hide resolved

tomkivlin approved these changes Dec 24, 2019

View reviewed changes

tomkivlin added this to PR Review in progress in old-RA2 via automation Dec 24, 2019

tomkivlin added this to the Snezka milestone Dec 24, 2019

Adding references to requirements

0ede8b6

This change adds references to the different requirements from Ch01.

deebhatia approved these changes Dec 27, 2019

View reviewed changes

rabiabdel requested a review from msidana December 27, 2019 09:15

walterkozlowski requested changes Dec 30, 2019

View reviewed changes

tomkivlin suggested changes Dec 30, 2019

View reviewed changes

Comparision between DANM and Multus added

3a9a4f2

Due to requests in comments this change adds a comparision table of the relevant requirements and additional features of DANM and Multus.

Levovar reviewed Jan 6, 2020

View reviewed changes

CsatariGergely requested review from tomkivlin and walterkozlowski January 7, 2020 10:32

Adding MACVLAN and User Space CNI backend options

2b66d1d

Addressing incoming comments this change adds the option to use MACVLAN CNI, lists the backend options for the User Space CNi and adds the SR-IOV Device Plugin to the SR-IOV related note.

walterkozlowski requested changes Jan 9, 2020

View reviewed changes

tomkivlin suggested changes Jan 9, 2020

View reviewed changes

Add an eitors note about the list of CNI plugins

0b2d9ee

As we were not able to agree on the set of CNI plugins this change adds a note that the list can be changed in the future.

CsatariGergely requested a review from walterkozlowski January 9, 2020 15:10

tomkivlin approved these changes Jan 9, 2020

View reviewed changes

Must -> may for CNI-s

ecabecf

This change switches the "must" statements regarding to CNI-s to "may" statements and adds a cladification text to the related editors note how this will be fixed in the next releases.

tomkivlin added Force Merged Forced Merge due to lack of activities online approved and removed Force Merged Forced Merge due to lack of activities labels Jan 10, 2020

rabiabdel approved these changes Jan 10, 2020

View reviewed changes

rabiabdel added the Force Merged Forced Merge due to lack of activities label Jan 10, 2020

cntt-n merged commit b9efeaf into master Jan 10, 2020

old-RA2 automation moved this from PR Review in progress to Done Jan 10, 2020

cntt-n deleted the 642-networking-in-ra2-ch4 branch January 10, 2020 17:13

tomkivlin added the Archive Archive Item label Feb 11, 2020

project-bot bot moved this from Done to Archive in old-RA2 Feb 11, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[RA2 Ch04]: Networking part of Ch4 in RA2 #821

[RA2 Ch04]: Networking part of Ch4 in RA2 #821

CsatariGergely commented Dec 20, 2019

walterkozlowski commented Dec 23, 2019 via email

tomkivlin left a comment

walterkozlowski left a comment

msidana commented Dec 30, 2019

tomkivlin Dec 30, 2019

CsatariGergely Jan 7, 2020

tomkivlin Jan 7, 2020

Levovar Jan 7, 2020

CsatariGergely commented Dec 31, 2019

petorre commented Jan 2, 2020

CsatariGergely commented Jan 2, 2020

Levovar Jan 6, 2020

Levovar Jan 6, 2020

Levovar commented Jan 6, 2020

walterkozlowski left a comment

tomkivlin commented Jan 9, 2020

tomkivlin left a comment

walterkozlowski commented Jan 9, 2020 via email

tomkivlin commented Jan 9, 2020

CsatariGergely commented Jan 9, 2020

tomkivlin commented Jan 9, 2020

msidana commented Jan 9, 2020

walterkozlowski commented Jan 10, 2020

walterkozlowski commented Jan 10, 2020 via email

CsatariGergely commented Jan 10, 2020

CsatariGergely commented Jan 10, 2020

petorre commented Jan 10, 2020

tomkivlin commented Jan 10, 2020


		[Calico](https://github.com/projectcalico/cni-plugin) must be used as the CNI what complies with the basic networking assumptions of Kubernetes based on the requirement `req.inf.ntw.02` due to it's capability to handle `NetworkPolicies`, what is missing from [Flannel](https://github.com/coreos/flannel-cni).
		For the network of signalling connections the built in IPVLAN CNI of DANM must be used as it provides NAT-less connectivity (`req.inf.ntw.03`). For the user plane network(s) fullfilling requirement `req.inf.ntw.04` the [User Space CNI](https://github.com/intel/userspace-cni-network-plugin) must be used.

[RA2 Ch04]: Networking part of Ch4 in RA2 #821

[RA2 Ch04]: Networking part of Ch4 in RA2 #821

Conversation

CsatariGergely commented Dec 20, 2019

walterkozlowski commented Dec 23, 2019 via email

tomkivlin left a comment

Choose a reason for hiding this comment

walterkozlowski left a comment

Choose a reason for hiding this comment

msidana commented Dec 30, 2019

tomkivlin Dec 30, 2019

Choose a reason for hiding this comment

CsatariGergely Jan 7, 2020

Choose a reason for hiding this comment

tomkivlin Jan 7, 2020

Choose a reason for hiding this comment

Levovar Jan 7, 2020

Choose a reason for hiding this comment

CsatariGergely commented Dec 31, 2019

petorre commented Jan 2, 2020

CsatariGergely commented Jan 2, 2020

Levovar Jan 6, 2020

Choose a reason for hiding this comment

Levovar Jan 6, 2020

Choose a reason for hiding this comment

Levovar commented Jan 6, 2020

walterkozlowski left a comment

Choose a reason for hiding this comment

tomkivlin commented Jan 9, 2020

tomkivlin left a comment

Choose a reason for hiding this comment

walterkozlowski commented Jan 9, 2020 via email

tomkivlin commented Jan 9, 2020

CsatariGergely commented Jan 9, 2020

tomkivlin commented Jan 9, 2020

msidana commented Jan 9, 2020

walterkozlowski commented Jan 10, 2020

walterkozlowski commented Jan 10, 2020 via email

CsatariGergely commented Jan 10, 2020

CsatariGergely commented Jan 10, 2020

petorre commented Jan 10, 2020

tomkivlin commented Jan 10, 2020