[openstack-dev] VPC Proposal

Harshad Nakil hnakil at contrailsystems.com
Sun Feb 16 06:04:00 UTC 2014


Comments Inline

Regards
-Harshad


On Sat, Feb 15, 2014 at 3:18 PM, Martin, JC <jch.martin at 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 <hnakil at 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.martin at 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 <hnakil at 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.martin at 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 <rrugge at 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.martin at 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 at lists.openstack.org
> >>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> OpenStack-dev mailing list
> >>>>> OpenStack-dev at lists.openstack.org
> >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> OpenStack-dev mailing list
> >>>> OpenStack-dev at lists.openstack.org
> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>> _______________________________________________
> >>> OpenStack-dev mailing list
> >>> OpenStack-dev at lists.openstack.org
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140215/3b8dd8d2/attachment.html>


More information about the OpenStack-dev mailing list