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 OpenStack 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 OpenStack (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 OpenStack APIs, and respond In other cases Congress can detect the conditions and take direct action through a wide range of OpenStack 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

Example: DMZ Server / 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 openstack congress policy rule create test "dmz_server(x) :- nova:servers(id=x,status='ACTIVE'), neutronv2:ports(id, device_id, status='ACTIVE'), neutronv2:security_group_port_bindings(id, sg), neutronv2:security_groups(sg,name='dmz')" --name dmz_server openstack congress policy rule create test "dmz_placement_error(id) :- nova:servers(id,name,hostId,status,tenant_id,user_id,image,flavor,az,hh), not glancev2: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

Example: SMTP Ingress openstack congress policy rule create test "smtp_ingress(x) :- nova:servers(id=x,status='ACTIVE'), neutronv2:ports(port_id, status='ACTIVE'), neutronv2:security_groups(sg, tenant_id, sgn, sgd), neutronv2:security_group_port_bindings(port_id, sg), neutronv2: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) :- neutronv2:subnets(id=x, cidr=' /24')" --name rsv_subnet_adm openstack congress policy rule create test "reserved_subnet_error(x) :- neutronv2:subnets(id=x, cidr=' /24')" --name rsv_subnet_prv openstack congress policy rule create test "reserved_subnet_error(x) :- neutronv2:subnets(id=x, cidr=' /24')" --name rsv_subnet_stg openstack congress policy rule create test "reserved_subnet_error(x) :- neutronv2:subnets(id=x, cidr=' /24')" --name rsv_subnet_mgm openstack congress policy rule create test "execute[neutronv2: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 JuJu Charm and Puppet Module These are being upstreamed to OpenStack … 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 FuncTest 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)