Get me a network From boot to woot! Matt Riedemann Armando - - PowerPoint PPT Presentation

Get me a network

From boot to woot!

Matt Riedemann

Huawei N-O-P Nova PTL

Armando Migliaccio

SUSE M-N-O Neutron PTL

Agenda

• Rationale
• Proposed solution
• Community effort
• Testing
• Future work
• Demo
• Q&A

Rationale

Rationale

Rationale

• Cloud user wants a VM connected to the Internet

○ Neutron requires an intimate knowledge about networking ○ Must create a private logical network (for isolation) ■ Create a subnet (for IP address management) ○ Must create a router (to get external connectivity) ■ Uplink the router to a well known external network ■ Downlink the router on the previously created subnet

Rationale

• Cloud user wants a VM connected to the Internet

○ Neutron requires an intimate knowledge about networking ○ Must create a private logical network (for isolation) ■ Create a subnet (for IP address management) ○ Must create a router (to get external connectivity) ■ Uplink the router to a well known external network ■ Downlink the router on the previously created subnet

Proposed solution

• What if these steps were fully automated?

Proposed solution

• What if these steps were fully automated?
• That is what get-me-a-network does
• The operator performs a one-time setup
• The user will get the network provisioned on the boot of the first VM

• What if these steps were fully automated?
• That is what get-me-a-network does
• The operator performs a one-time setup
• The user will get the network provisioned on the boot of the first VM

Proposed solution

• On server create
• Nova and Neutron work together to figure out what to do
• If the user has no network, one will be provisioned and the VM will be given

external connectivity

• Any other boot request will piggyback on the first and the network is reused
• NOTE: VMs are not given floating IP automatically

Proposed solution

Community effort: timeline

• Liberty
• May 2015 - Design discussion at Vancouver summit
• July 2015 - Neutron spec merges
• Aug 2015 - Neutron implementation starts (but stalls)
• Mitaka
• January 2016 - Neutron implementation resumes (Neutron cores at Nova mid-cycle)
• March 2016 - Neutron Feature completes
• Newton
• May 2016 - Nova spec merges
• Aug 2016 - Nova feature completes
• Sep 2016 - Integration testing completes

• Some initial pushback
• Consensus and blueprint specification
• http://specs.openstack.org/openstack/neutron-specs/specs/mitaka/get-me-a-network.html
• The building blocks
• Subnet pools to provide automatic IPAM
• Default external networks

Community effort: timeline

Community effort: Neutron

• The workflow
• During the initial cloud setup, the operator:
• creates default subnet pool(s) (ie. the IP space(s) to allocate subnets from)
• creates a default external network (ie. the route to the Internet)
• During the boot phase, Neutron (atomically):
• Fetches an IP space from the default pool
• Creates a network, subnet(s), router and uplink
• Returns the UUID of the allocated network to Nova

Community effort: Nova

• Blueprint specification
• https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/get-me-a-net

work.html

• Considerations
• Handling “none” for explicit no network allocation
• Mixed-level computes
• What the request format should look like (usual networks dict vs enums)
• The REST API is explicit, but the CLI provides a sane default (auto)
• Nova runs the “dry-run” check in Neutron to make sure everything is setup
• The “dry-run” option was not part of the original Neutron implementation
• Nova does not retry; Neutron auto-allocated-topology is idempotent

Community effort: Nova

• The workflow
• POST /servers with microversion >= 2.37 and networks=”auto” in the body
• nova-api checks if all nova-compute services are new enough to handle this
• nova-api validates that if no network is already available to the project, one can be

automatically allocated

• nova-compute: if a network is available to the project, use it, otherwise if asked to

auto-allocate a network, attempt that by calling Neutron

• If this succeeds, a port is created on the new network
• If this fails, the server build is aborted (no retries), a fault is recorded and the

instance is put into ERROR state

Testing

• Test cases to expose concurrency and locking issues
• Multiple users to compete on subnet pool access
• Multiple requests coming from same user performing ‘first boot’
• e.g. nova boot --flavor m1.small --image centos73 --nic auto --min-count 3
• This stresses the idempotency of the auto-allocated-topology extension in

Neutron

Future work

• Get Floating IP automatically allocated
• Initially ruled out
• To avoid consuming precious “IPv4”
• To allow IPv6-only environments seamlessly
• Control external gateway modes
• Enabling/Disabling SNAT
• Provision any kind of topology
• Provider networks (vlan) vs logical networks (vxlan)

Q&A