JC, We have a complete implementation which I had submitted earlier. But since the code was too large the community decided to move forward in a phased approach. The plan is to provide close to complete compatibility in a multi-phase manner as mentioned in the blueprint. Phase 4 (internet gateway, VPN, NAT etc) was not added to the blueprint as that was dependent on VPNaas, FWaaS, NATaas.
Comments inline: On Feb 19, 2014, at 9:05 AM, Martin, JC <jch.mar...@gmail.com<mailto:jch.mar...@gmail.com>> wrote: Comments in line. JC On Feb 18, 2014, at 5:21 PM, Rudra Rugge <rru...@juniper.net<mailto:rru...@juniper.net>> wrote: Please see inline: On Feb 18, 2014, at 2:57 PM, Martin, JC <jch.mar...@gmail.com<mailto:jch.mar...@gmail.com>> wrote: Maybe I should explain this one a bit. Shared network: If a user has defined a shared network, and they used your API to create a VPC, the instances within the VPC will automatically get an interface on the shared network. I don't think that this is the expected behavior When a user launches a VM in a VPC (AWS) the user needs to specify a subnet (network in openstack terminology) for each of the interfaces. Hence the instances will only get interfaces on the passed subnets/networks. The network being shared or not is not relevant for the VM launch. AWS APIs need the subnet/network to be passed for a VM launch in VPC. Thanks, this makes sense. FIP in scope of VPC: I was not talking about the EIP for Internet access, sorry if it was confusing. Since you are not really describing how you create the external networks, it's not clear how you implement the multiple gateways (public and private) that AWS supports, and how you connects networks to routers and external networks. i.e. are the CIDRs used in the VPC, NAT'ED to be routed in the customer datacenter, in which case, there is a floating IP pool that is private to each private gateway and VPC (not the 'public' one). Gateways are built using Openstack neutron router resource. Networks are connected to the router interfaces. For internet access cloud administrator needs to provision a floating IP pool for the router to use. For CIDRs used in the VPC we need to implement a route-table extension which holds the prefix list. The prefix-list or route-table is attached to a subnet(AWS)/network(Openstack). All internal(private) routing is managed by the Openstack router. NAT and VPN are used as next-hops to exit the VPC. In these cases similar to AWS we need to launch NAT and VPN capable instances as supported by Openstack FWAAS and VPNAAS. I looked in the code referenced but did not find any router attachment call. Did I miss something ? Also, what about these calls: CreateInternetGateway, AttachInternetGateway, CreateCustomerGateway, … don't you need that define how the VPC attach outside ? [Rudra] We are going with a phased approach as I noted above. The code submitted is only for phase 1 of the blueprint. What about mapping the optional attributes too (e.g. InstanceTenancy) ? What's the point of providing only partial compatibility ? [Rudra] As mentioned above there is full compatibility available but we need to handle this in multiple phases. Rudra It would be useful for you to describe the pre-setup required to do make this works. The only pre-setup needed by the cloud admin is to provide a public pool for floating IP. Rudra JC On Feb 18, 2014, at 1:09 PM, Harshad Nakil <hna...@contrailsystems.com<mailto:hna...@contrailsystems.com>> wrote: 2. It does give full AWS compatibility (except for network ACL which was differed). Shared networks, FIP within scope of VPC is not some thing AWS provides. So it is not partial support. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
