Difference between revisions of "Blueprint-VPC"
(→Use cases) |
|||
| Line 1: | Line 1: | ||
| − | The goal of this blueprint | + | The goal of this document is to provide an umbrella blueprint defining how to add support for VPC in Openstack. |
| + | |||
| + | A VPC is defined as an entity providing resources access boundaries with the goal of building a logically isolated infrastructure assigned to a tenant. | ||
| + | |||
| + | There are multiple options to implement this entity, either as a formal node in the openstack container hierarchy (domain, projects), or as a tag used to define access policies. | ||
=== Relationship with other blueprint === | === Relationship with other blueprint === | ||
| − | : Hierarchical Multitenancy [1] | + | |
| − | : AWS VPC API support [2] | + | : Hierarchical Multitenancy [1] defines a hierarchical model for resource ownership and containment |
| + | : AWS VPC API support [2] aims at providing an EC2 VPC equivalent API on openstack | ||
=== Use cases === | === Use cases === | ||
| Line 12: | Line 17: | ||
: Within the VPC, the administrator can : | : Within the VPC, the administrator can : | ||
| − | : 1.1 - | + | : 1.1 - create a shared network. A shared network in the VPC is equivalent to a Neutron public network (it's a public network with a restricted scope). |
: 1.2 - create a transit or external network that can be connected to a remote datacenter through, for MPLS or a VPN or to the internet. | : 1.2 - create a transit or external network that can be connected to a remote datacenter through, for MPLS or a VPN or to the internet. | ||
| − | : 1.3 - define specific flavors, images or other openstack resources restricted to be used within this VPC. | + | : 1.3 - define specific flavors, images or other openstack resources restricted to be used within this VPC (e.g. DNS Zone, LB Resources, ...). |
| + | : 1.4 - define quota for resources available to a given VPC. | ||
: 2 - The domain administrator can delegate the management of the VPC to a user or group of the domain | : 2 - The domain administrator can delegate the management of the VPC to a user or group of the domain | ||
| Line 52: | Line 58: | ||
# In this model, the VPC is not really a first class object, but a group of policies. | # In this model, the VPC is not really a first class object, but a group of policies. | ||
# Some open issues : specification of metadata at the VPC level, user experience. | # Some open issues : specification of metadata at the VPC level, user experience. | ||
| + | |||
| + | |||
| + | === Resulting Blueprints ==== | ||
| + | |||
| + | The implementation of the VPC will require multiple blueprints in the various projects to cover the full functionality. | ||
| + | After discussion, we will provide in this section the related blueprints. | ||
---- | ---- | ||
Revision as of 01:17, 14 February 2014
The goal of this document is to provide an umbrella blueprint defining how to add support for VPC in Openstack.
A VPC is defined as an entity providing resources access boundaries with the goal of building a logically isolated infrastructure assigned to a tenant.
There are multiple options to implement this entity, either as a formal node in the openstack container hierarchy (domain, projects), or as a tag used to define access policies.
Contents
Relationship with other blueprint
- Hierarchical Multitenancy [1] defines a hierarchical model for resource ownership and containment
- AWS VPC API support [2] aims at providing an EC2 VPC equivalent API on openstack
Use cases
- 1 - The administrator of a domain can create a VPC composed of network resources. A generic VPC can look like:
- Within the VPC, the administrator can :
- 1.1 - create a shared network. A shared network in the VPC is equivalent to a Neutron public network (it's a public network with a restricted scope).
- 1.2 - create a transit or external network that can be connected to a remote datacenter through, for MPLS or a VPN or to the internet.
- 1.3 - define specific flavors, images or other openstack resources restricted to be used within this VPC (e.g. DNS Zone, LB Resources, ...).
- 1.4 - define quota for resources available to a given VPC.
- 2 - The domain administrator can delegate the management of the VPC to a user or group of the domain
- 3 - A user of a domain, can create a project within a given VPC. Within this project, the user can
- 3.1. create a private network using the VPC external or shared network as the next hop. VMs can get a floating IP from the shared or external network
- 3.2 create a VM within a project attached to a shared network exposed by the VPC.
Resource Model
The above model is showing a relationship between VPC and Project assuming a containment relationship. However, as shown below, depending on the implementation, it could be a more loose relationship.
Implementation options
Project Based
- create a VPC administrative project - this could be a project owned by a domain admin.
- Create network objects in above mentioned project to build the VPC topology.
- (optionally: see [3]) update project creation flow by allowing the scoping of project to a given VPC (tagging project with specific VPC)
- update network selection or definition of "share network" to restrict to only tenant private networks or VPC shared networks
Hierarchical Container
- Implement VPC as a container similar to a project that can be used to contain resources and projects. This could use the concepts defined in [1], as long as we can have more than admin and project as levels in the hierarchy.
- Domain admin would create a VPC as a domain level object.
- Domain admin can add role of VPC admin to user and delegate VPC management to this VPC admin
- in Neutron : The shared network semantic has to be updated to allow the scoping of shared networks to a VPC .
- in Glance : Sharing of image has to be extended enable the sharing across projects within the VPC.
- in Cinder : same as glance.
- allow the specification of metadata associated with the VPC to capture for example the DNS Zone associated with the VPC.
Policy Based
- Similar to Amazon AWS [4]
- Use the project as a container for VPC level resource
- Construct a set of policies to implement isolation and sharing characteristics like [4].
- In this model, the VPC is not really a first class object, but a group of policies.
- Some open issues : specification of metadata at the VPC level, user experience.
Resulting Blueprints =
The implementation of the VPC will require multiple blueprints in the various projects to cover the full functionality. After discussion, we will provide in this section the related blueprints.
[1] https://wiki.openstack.org/wiki/HierarchicalMultitenancy
[2] https://wiki.openstack.org/wiki/Blueprint-aws-vpc-support
[3] if a project is not scoped to a VPC (tagged with the VPC id), the resource created within a project can use any of the Shared VPC Networks within the user scope (e.g. domain scope).
[4] http://docs.aws.amazon.com/IAM/latest/UserGuide/ExampleIAMPolicies.html
