Bug 894815

Summary: Support EC2 VPC style APIs on top of Quantum
Product: Red Hat OpenStack Reporter: Perry Myers <pmyers>
Component: openstack-neutronAssignee: Steven Hardy <shardy>
Status: CLOSED CURRENTRELEASE QA Contact: Ofer Blaut <oblaut>
Severity: medium Docs Contact:
Priority: medium    
Version: 2.0 (Folsom)CC: chrisw, jkt, nyechiel, sbaker, shardy
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-04-03 13:45:06 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Perry Myers 2013-01-13 19:48:35 UTC
Support EC2 VPC style APIs on top of Quantum

Comment 1 Perry Myers 2013-06-20 15:47:04 UTC
shardy, are you driving this as part of Heat requirements?

Comment 2 Steven Hardy 2013-06-20 16:02:56 UTC
(In reply to Perry Myers from comment #1)
> shardy, are you driving this as part of Heat requirements?

Yes, we have already got some support for AWS-compatible VPC resources, and also a set of openstack native Quantum resources.

Currently we have:

AWS::EC2::VPCGatewayAttachment
AWS::EC2::NetworkInterface
AWS::EC2::VPC
AWS::EC2::InternetGateway

and

OS::Quantum::Net
OS::Quantum::FloatingIP
OS::Quantum::FloatingIPAssociation
OS::Quantum::Router
OS::Quantum::RouterInterface
OS::Quantum::RouterGateway
OS::Quantum::Port
OS::Quantum::Subnet

In general, we're guiding users to the Quantum resources over the AWS-compatible ones where possible, as they provide more complete interfaces to Quantum functionality.

Comment 3 Perry Myers 2013-06-20 18:29:07 UTC
Ok, so... What remains to be done on this bug?  Are there missing APIs that need implemented in Neutron?  Are there blueprints or other LP bugs that we need to track here?

Comment 4 Steven Hardy 2013-06-20 21:39:09 UTC
Well if the aim of this bug is to fully support AWS VPC resources in Heat (which from the description/title I'm not sure it is?) then we need to do a gap analysis of our VPC resources wrt the AWS docs.

I'm pretty sure the reason we've guided users to the Quantum native resources is because there were some VPC resource features which did not map to Quantum/Neutron so are unimplmented.

Putting Steve Baker on Cc as he has been recently involved with (and was the original author of many of) the Quantum/VPC resources and may have more details.

Comment 6 Nir Yechiel 2014-04-01 11:18:34 UTC
Hi Steven,

Can you provide any update on this bug?


Thanks,
Nir

Comment 7 Steven Hardy 2014-04-01 12:56:36 UTC
(In reply to Nir Yechiel from comment #6)
> Hi Steven,
> 
> Can you provide any update on this bug?

To be honest, I'm not sure what is required of upstream to close this, as mentioned in comment #2 we already have at least partial coverage of the VPC functionality via our CFN compatible resources, and quite good coverage of the underlying Neutron API's.

As of Icehouse, we support the following native Neutron resources:

'OS::Neutron::Firewall'
'OS::Neutron::FirewallPolicy'
'OS::Neutron::FirewallRule'
'OS::Neutron::FloatingIP'
'OS::Neutron::FloatingIPAssociation'
'OS::Neutron::HealthMonitor'
'OS::Neutron::Pool'
'OS::Neutron::PoolMember'
'OS::Neutron::LoadBalancer'
'OS::Neutron::MeteringLabel'
'OS::Neutron::MeteringRule'
'OS::Neutron::Net'
'OS::Neutron::NetworkGateway'
'OS::Neutron::Port'
'OS::Neutron::ProviderNet'
'OS::Neutron::Router'
'OS::Neutron::RouterInterface'
'OS::Neutron::RouterGateway'
'OS::Neutron::SecurityGroup'
'OS::Neutron::Subnet'
'OS::Neutron::VPNService'
'OS::Neutron::IPsecSiteConnection'
'OS::Neutron::IKEPolicy'
'OS::Neutron::IPsecPolicy'

And these CFN compatible ones:

AWS::EC2::VPCGatewayAttachment
AWS::EC2::NetworkInterface
AWS::EC2::VPC
AWS::EC2::InternetGateway

Perhaps pmyers can clarify - what is the requirement here, for virtual networking functionality via heat, or an EC2 compatible API which provides access to the functionality (in which case I guess this needs to be handled via the nova ec2 API or a neutron API?)

Comment 8 Perry Myers 2014-04-01 18:25:33 UTC
The former, the requirement was to provide virtual networking functionality via Heat.

Given that, I think this bug should be closed and instead QE can focus on any blueprints that were implemented around this in the Icehouse timeframe.  This bz was a placeholder and probably should be closed as a dup of a relevant RFE that is linked to an upstream blueprint.

Comment 9 Nir Yechiel 2014-04-02 12:37:22 UTC
(In reply to Perry Myers from comment #8)
> The former, the requirement was to provide virtual networking functionality
> via Heat.
> 
> Given that, I think this bug should be closed and instead QE can focus on
> any blueprints that were implemented around this in the Icehouse timeframe. 
> This bz was a placeholder and probably should be closed as a dup of a
> relevant RFE that is linked to an upstream blueprint.

Virtual networking functionality sounds a little bit wide. There are heat blueprint like these [1] but I can't find any blueprint who seems relevant to this request at this point. Any idea how to proceed here?

Thanks,
Nir


[1] 
https://blueprints.launchpad.net/heat/+spec/neutron-metering-resources
https://blueprints.launchpad.net/heat/+spec/neutron-net-resource-add-provider-network

Comment 10 Perry Myers 2014-04-03 13:45:06 UTC
Since this request was made by me specifically, and was very nebulous to begin with (it was meant to be a high level concept tracker not a concrete feature request really), I'm going to close this one as I personally feel that this requirement has been met by the existing functionality shardy already describes as being present in Heat.