EIP will be allocated from public pools. So in effect public pools and shared networks are only DC admin functions. Not available to VPC users. There is a implicit external gateway. When one creates NAT instance or VPN instance, external interfaces of these interfaces come from the shared network which can be configured by the DC admin.
Regards -Harshad > On Feb 14, 2014, at 10:07 PM, "Martin, JC" <jch.mar...@gmail.com> wrote: > > Harshad, > > I'm not sure to understand what you mean by : >> However many of these concepts are not exposed to a AWS customers and >> the API work well. > > So for example in : > > http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html#VPC_EIP_EC2_Differences > > When it says : > "When you allocate an EIP, it's for use only in a VPC." > > Are you saying that the behavior of your API would be consistent without > scoping the external networks to a VPC and using the public pool instead ? > > I believe that your api may work for basic features on a small deployments > with only one VPC, but as soon as you have complex setups with external > gateways that need to be isolated, I'm not sure that it will provide parity > anyway with what EC2 provides. > > > Maybe I missed something. > > > JC > >> On Feb 14, 2014, at 7:35 PM, Harshad Nakil <hna...@contrailsystems.com> >> wrote: >> >> Hi JC, >> >> You have put it aptly. Goal of the blueprint is to present facade for >> AWS VPC API as the name suggest. >> As per your definition of VPC, shared network will have issues. >> However many of these concepts are not exposed to a AWS customers and >> the API work well. >> While we work incrementally towards your definition of VPC we can >> maintain API compatibility to AWS API that we are proposing. As we are >> subset of your proposal and don't expose all features within VPC. >> >> Regards >> -Harshad >> >> >>> On Feb 14, 2014, at 6:22 PM, "Martin, JC" <jch.mar...@gmail.com> wrote: >>> >>> Rudra, >>> >>> I do not agree that the current proposal provides the semantic of a VPC. If >>> the goal is to only provide a facade through the EC2 API, it may address >>> this, but unless you implement the basic features of a VPC, what good is it >>> doing ? >>> >>> I do believe that the work can be done incrementally if we agree on the >>> basic properties of a VPC, for example : >>> - allowing projects to be created while using resources defined at the VPC >>> level >>> - preventing resources not explicitly defined at the VPC level to be used >>> by a VPC. >>> >>> I do not see in the current proposal how resources are scoped to a VPC, and >>> how, for example, you prevent shared network to be used within a VPC, or >>> how you can define shared networks (or other shared resources) to only be >>> scoped to a VPC. >>> >>> I think we already raised our concern to you several months ago, but it did >>> not seem to have been addressed in the current proposal. >>> >>> thanks, >>> >>> JC >>> >>>> On Feb 14, 2014, at 3:50 PM, Rudra Rugge <rru...@juniper.net> wrote: >>>> >>>> Hi JC, >>>> >>>> We agree with your proposed model of a VPC resource object. Proposal you >>>> are making makes sense to us and we would like to collaborate further on >>>> this. After reading your blueprint two things come to mind. >>>> >>>> 1. VPC vision for Openstack? (Your blueprint is proposing this vision) >>>> 2. Providing AWS VPC api compatibility with current constrains of >>>> openstack structure. >>>> >>>> The blueprint that we proposed targets #2. >>>> It gives a way to implement "AWS VPC api" compatible API. This helps >>>> subset of customers to migrate their workloads from AWS to openstack based >>>> clouds. In our implementation we tied VPC to project. That was easiest way >>>> to keep isolation with current structure. We agree that what you are >>>> proposing is more generic. One to way is to implement our current proposal >>>> to have one VPC to one project mapping. As your blueprint matures we will >>>> move VPC to multiple project mapping. >>>> >>>> We feel that instead of throwing away all the work done we can take an >>>> incremental approach. >>>> >>>> Regards, >>>> Rudra >>>> >>>> >>>>> On Feb 14, 2014, at 11:09 AM, Martin, JC <jch.mar...@gmail.com> wrote: >>>>> >>>>> >>>>> There is a Blueprint targeted for Icehouse-3 that is aiming to implement >>>>> the AWS VPC api. I don't think that this blueprint is providing the >>>>> necessary constructs to really implement a VPC, and it is not taking into >>>>> account the domains, or proposed multi tenant hierarchy. In addition, I >>>>> could not find a discussion about this topic leading to the approval. >>>>> >>>>> For this reason, I wrote an 'umbrella' blueprint to hopefully start the >>>>> discussion on how to really implement VPC, and eventually split it into >>>>> multiple real blueprints for each area. >>>>> >>>>> Please, provide feedback on the following document, and on the best way >>>>> to move this forward. >>>>> >>>>> https://wiki.openstack.org/wiki/Blueprint-VPC >>>>> >>>>> Thanks, >>>>> >>>>> JC. >>>>> _______________________________________________ >>>>> OpenStack-dev mailing list >>>>> 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 >>> >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> 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 > > > _______________________________________________ > OpenStack-dev mailing list > 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
