Harshad, Thanks, What happens when I create two VPC ? Beside the project private networks, what is isolated ?
What do you call DC admin ? I know two administrators : - Cloud administrators - VPC admnistrator Are you saying that VPCs cannot have their own external gateways and NAT pools ? Also, maybe more importantly, why try to build an AWS API before the function is available in openstack ? Why not wait to do it properly before defining the API mapping ? JC On Feb 15, 2014, at 8:47 AM, Harshad Nakil <hna...@contrailsystems.com> wrote: > 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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
