This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 894815 - Support EC2 VPC style APIs on top of Quantum
Support EC2 VPC style APIs on top of Quantum
Status: CLOSED CURRENTRELEASE
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-neutron (Show other bugs)
2.0 (Folsom)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Steven Hardy
Ofer Blaut
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-01-13 14:48 EST by Perry Myers
Modified: 2016-04-26 13:56 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-04-03 09:45:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Perry Myers 2013-01-13 14:48:35 EST
Support EC2 VPC style APIs on top of Quantum
Comment 1 Perry Myers 2013-06-20 11:47:04 EDT
shardy, are you driving this as part of Heat requirements?
Comment 2 Steven Hardy 2013-06-20 12:02:56 EDT
(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 14:29:07 EDT
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 17:39:09 EDT
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 07:18:34 EDT
Hi Steven,

Can you provide any update on this bug?


Thanks,
Nir
Comment 7 Steven Hardy 2014-04-01 08:56:36 EDT
(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 14:25:33 EDT
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 08:37:22 EDT
(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 09:45:06 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.