June 20 23 2016 Berlin Germany Copper Configuration
June 20– 23, 2016 | Berlin, Germany
Copper: Configuration Policy Management in OPNFV Colorado Bryan Sullivan, AT&T
Copper. Huh. What is it good for? • In olden telco times, copper was the network backbone, the medium for service chaining, the essential configuration resource • In OPNFV, Copper means knowing that a NFV system will • Provide me what I want: topology, resources, behavior • Avoid what I don’t want: mistakes, risk, bad behavior
Making cents of Copper and Policy • “Configuration Policy” is a somewhat fuzzy concept • In Copper, we break it down into two main aspects • How VNFs and Services should be built and managed • How we stay aware of the current state of the infrastructure and network functions, and react to it as needed
Policy as How Things are Built and Behave • NFV comes down to two basic aspects • A) A collection of things that do stuff • B) How those things are deployed • While Copper is scoped for (B) broadly, OPNFV has launched projects with similar, yet special purpose needs • HA, Multisite, SFC, VNFFG, … • . . . and the more general aspects of “how things are built and behave” has been picked up by the Models project • So Copper in Brahmaputra and Colorado has focused primarily on Open. Stack Congress and “Policy as a Service”
Policy as What I need to Know • Congress is principally about knowing, and optionally reacting to the state of a service or resource • Congress uses datasource drivers to monitor the database tables of Open. Stack (or any other database-backed service) • This enables complex policies to be expressed as table joins • The scope of knowledge covers almost any aspect of infrastructure or service/VNF state that can be derived from monitored databases • Once known, other systems can react to the knowledge, or Congress can react by itself
Policy as What I Want to Avoid • Trusting/knowing that things were built per plan is one thing • But things will sometimes be done wrong or go wrong… management systems and admins will make mistakes, unforeseen errors will occur… • Other things are expected and need to be watched for / responded to • VNFMs may discover these things directly or thru Open. Stack APIs, and respond • In other cases Congress can detect the conditions and take direct action through a wide range of Open. Stack API hooks
Freedom to Know and React • Examples of Congress policies in Colorado tests • DMZ Placement Error • Pause a VM incorrectly launched in a DMZ network zone • Reserved Subnet • Delete a subnet created from a reserved range • SMTP Ingress • Flag VMs created with ingress open on TCP port 25 • These examples will be expanded once Congress integration is completed for Colorado • A library of policies will be created as part of the project, to aid users in policy implementation https: //git. opnfv. org/cgit/copper/tree/tests
Example: DMZ Server / Placement Error openstack congress policy rule create test "dmz_server(x) : nova: servers(id=x, status='ACTIVE'), neutronv 2: ports(id, device_id, status='ACTIVE'), neutronv 2: security_group_port_bindings(id, sg), neutronv 2: security_groups(sg, name='dmz')" --name dmz_server openstack congress policy rule create test "dmz_placement_error(id) : nova: servers(id, name, host. Id, status, tenant_id, user_id, image, flavor, az, hh), not glancev 2: tags(image, 'dmz'), dmz_server(id)" --name dmz_placement_error openstack congress policy rule create test "execute[nova: servers. pause(id)] : - dmz_placement_error(id), nova: servers(id, status='ACTIVE')" --name paused_dmz_placement_error • Rule 1 says “create a dmz_server table entry for any active VM associated to the DMZ security group” • Rule 2 finds DMZ VMs are running images not tagged for “allowed in DMZ” • Rule 3 says to pause the bad boys when found
Example: SMTP Ingress openstack congress policy rule create test "smtp_ingress(x) : nova: servers(id=x, status='ACTIVE'), neutronv 2: ports(port_id, status='ACTIVE'), neutronv 2: security_groups(sg, tenant_id, sgn, sgd), neutronv 2: security_group_port_bindings(port_id, sg), neutronv 2: security_group_rules(sg, rule_id, tenant_id, remote_group_id, 'ingress', ethertype, 'tcp', port_range_min, port_range_max, remote_ip), lt(port_range_min, 26), gt(port_range_max, 24)" -name smtp_ingress • This rule says “create an smtp_ingress table entry for any VM in a security group with TCP port 25 open for ingress”
Example: Reserved Subnet openstack congress policy rule create test "reserved_subnet_error(x) neutronv 2: subnets(id=x, cidr='10. 7. 1. 0/24')" --name rsv_subnet_adm openstack congress policy rule create test "reserved_subnet_error(x) neutronv 2: subnets(id=x, cidr='10. 7. 12. 0/24')" --name rsv_subnet_prv openstack congress policy rule create test "reserved_subnet_error(x) neutronv 2: subnets(id=x, cidr='10. 7. 13. 0/24')" --name rsv_subnet_stg openstack congress policy rule create test "reserved_subnet_error(x) neutronv 2: subnets(id=x, cidr='10. 7. 14. 0/24')" --name rsv_subnet_mgm openstack congress policy rule create test "execute[neutronv 2: delete_subnet(x)] : - reserved_subnet_error(x)" -name deleted_reserved_subnet_error • Rule 1 -4 rule says “create a reserved_subnet_error table entry for any subnet created with this CIDR” • Rule 5 says delete any subnet that shows up in the reserved_subnet_error table : : -
Are we there yet? • For Colorado, the JOID and Apex team have help us create direct installer support via a Ju. Ju Charm and Puppet Module • These are being upstreamed to Open. Stack … yay! • For JOID and Apex at least, Congress will be a part of the base install and available in all deployments. • For FUEL and Compass, installer support is planned as well • The Puppet Module should simplify this integration • Congress test cases will be included in the CI/CD program through the Func. Test project • Other OPNFV projects e. g. Doctor are planning to use Congress features in Colorado
Demos! • Links to Congress demos on OPNFV • (being created – links will be added)
- Slides: 13