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
