Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Support EC2 VPC style APIs on top of Quantum|
|Product:||Red Hat OpenStack||Reporter:||Perry Myers <pmyers>|
|Component:||openstack-neutron||Assignee:||Steven Hardy <shardy>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Ofer Blaut <oblaut>|
|Version:||2.0 (Folsom)||CC:||chrisw, jkt, nyechiel, sbaker, shardy|
|Fixed In Version:||Doc Type:||Enhancement|
|Doc Text:||Story Points:||---|
|Last Closed:||2014-04-03 09:45:06 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
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  but I can't find any blueprint who seems relevant to this request at this point. Any idea how to proceed here? Thanks, Nir  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.