Comments Inline Regards -Harshad
On Sat, Feb 15, 2014 at 3:18 PM, Martin, JC <jch.mar...@gmail.com> wrote: > Harshad, > > Thanks, What happens when I create two VPC ? Beside the project private > networks, what is isolated ? > Since VPC is mapped to project. All the isolation provided by the project is available. > > What do you call DC admin ? I know two administrators : > - Cloud administrators > - VPC admnistrator > I mean cloud administrator > > Are you saying that VPCs cannot have their own external gateways and NAT > pools ? > Yes conceptually as far as AWS API compatibility is concerned. > > 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 ? > Actually as fas as AWS API is concerned we have all the proper building blocks in openstack. I agree with problem as defined by you and will require more fundamental changes. Meanwhile many users will benefit from AWS VPC api compatibility. > > 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 >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev