a7903e971d
Attributes needed to support nesting of container
domains in OpenStack VMs are being added.
A new extension to the network resource which allows providing
the Kubernetes instance and the list of VLANs is being added. The
extension adds the following information:
apic:nested_domain_name - name of the Kubernetes domain; empty string if no nesting
apic:nested_domain_type - specific string used in APIC
apic:nested_domain_infra_vlan - this is 4093 for Kubernetes/OpenShift
apic:nested_domain_service_vlan -
apic:nested_domain_node_network_vlan -
apic:nested_domain_allowed_vlans - {'vlans_list': <[...,...]>,
'vlan_ranges': <[{'start': <>, 'end': <>},
{'start': <>, 'end': <>},...]>}
The allowed VLANs specify the VLAN IDs used for tagging
Kubernetes pod and node traffic. The vlan_list can be used
for enumerating non-contiguous ranges, and/or the vlan_ranges
can be used for one one or more contiguos ranges.
Example CLI:
neutron net-create nn1 --apic:nested-domain-name kube \
--apic:nested-domain-type k8s \
--apic:nested_domain_infra_vlan 4093 \
--apic:nested_domain_node_network_vlan 3000 \
--apic:nested_domain_service_vlan 1000 \
--apic:nested_domain_allowed_vlans \
"{'vlans_list': [2, 3], \
'vlan_ranges': [{'start': 10, 'end': 12}]}"
Any VMs configured for host a nested domain also require
a "nested_host_vlan" configuration specified in the
"aim_mapping" section. This value is set to 4094 by default
but can be overridden to any VLAN that does not overlap
with any other VLAN used in the system. This VLAN is locally
significant and is only used so that the VM's traffic
intended for the neutron network is not dropped by the Opflex
agent configured flows.
Change-Id: Icb4ca8f4addb0f886450393c44c08d81ebfcea3c
|
||
|---|---|---|
| devstack | ||
| doc/source | ||
| etc | ||
| gbpservice | ||
| tools | ||
| .coveragerc | ||
| .gitignore | ||
| .gitreview | ||
| .testr.conf | ||
| babel.cfg | ||
| CONTRIBUTING.rst | ||
| HACKING.rst | ||
| LICENSE | ||
| MANIFEST.in | ||
| openstack-common.conf | ||
| README.rst | ||
| requirements.txt | ||
| run_tests.sh | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements.txt | ||
| TESTING.rst | ||
| tox.ini | ||
Group Based Policy (GBP) provides declarative abstractions for achieving scalable intent-based infrastructure automation.
GBP complements the OpenStack networking model with the notion of policies that can be applied between groups of network endpoints. As users look beyond basic connectivity, richer network services with diverse implementations and network properties are naturally expressed as policies. Examples include service chaining, QoS, path properties, access control, etc.
GBP allows application administrators to express their networking requirements using a Group and a Policy Rules-Set abstraction. The specifics of policy rendering are left to the underlying pluggable policy driver.
GBP model also supports a redirect operation that makes it easy to abstract and consume complex network service chains and graphs.
Checkout the GBP wiki page for more detailed information: <https://wiki.openstack.org/wiki/GroupBasedPolicy>
The latest code is available at: <http://git.openstack.org/cgit/openstack/group-based-policy>.
GBP project management (blueprints, bugs) is done via Launchpad: <https://launchpad.net/group-based-policy>
For help using or hacking on GBP, you can send mail to <mailto:openstack-dev@lists.openstack.org>.
Acronyms used in code for brevity:
- PT: Policy Target
- PTG: Policy Target Group
- PR: Policy Rule
- PRS: Policy Rule Set
- L2P: L2 Policy
- L3P: L3 Policy
- NSP: Network Service Policy
- EP: External Policy
- ES: External Segment
- SC: Service Chain
- SP: Service Profile