[openstack-dev] [Nova][Neutron][Keystone] Where to implement VPC API
Hi, There was some discussion a while back around the VPC implementation in Openstack. There is a proposal to implement the AWS VPC features in Nova EC2 APIs, but this makes sense for the EC2 compatible API only and may not be appropriate for an Openstack specify one. I would like to know what is the recommendation for the implementation of APIs that are orchestrating between keystone, nova, Neutron, designate, … What project should it be hosted into, or should it be a separate project ? Thanks, JC ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] VPC Proposal
Comments in line. JC On Feb 18, 2014, at 5:21 PM, Rudra Rugge rru...@juniper.net wrote: Please see inline: On Feb 18, 2014, at 2:57 PM, Martin, JC jch.mar...@gmail.com wrote: Maybe I should explain this one a bit. Shared network: If a user has defined a shared network, and they used your API to create a VPC, the instances within the VPC will automatically get an interface on the shared network. I don't think that this is the expected behavior When a user launches a VM in a VPC (AWS) the user needs to specify a subnet (network in openstack terminology) for each of the interfaces. Hence the instances will only get interfaces on the passed subnets/networks. The network being shared or not is not relevant for the VM launch. AWS APIs need the subnet/network to be passed for a VM launch in VPC. Thanks, this makes sense. FIP in scope of VPC: I was not talking about the EIP for Internet access, sorry if it was confusing. Since you are not really describing how you create the external networks, it's not clear how you implement the multiple gateways (public and private) that AWS supports, and how you connects networks to routers and external networks. i.e. are the CIDRs used in the VPC, NAT'ED to be routed in the customer datacenter, in which case, there is a floating IP pool that is private to each private gateway and VPC (not the 'public' one). Gateways are built using Openstack neutron router resource. Networks are connected to the router interfaces. For internet access cloud administrator needs to provision a floating IP pool for the router to use. For CIDRs used in the VPC we need to implement a route-table extension which holds the prefix list. The prefix-list or route-table is attached to a subnet(AWS)/network(Openstack). All internal(private) routing is managed by the Openstack router. NAT and VPN are used as next-hops to exit the VPC. In these cases similar to AWS we need to launch NAT and VPN capable instances as supported by Openstack FWAAS and VPNAAS. I looked in the code referenced but did not find any router attachment call. Did I miss something ? Also, what about these calls: CreateInternetGateway, AttachInternetGateway, CreateCustomerGateway, … don't you need that define how the VPC attach outside ? What about mapping the optional attributes too (e.g. InstanceTenancy) ? What's the point of providing only partial compatibility ? It would be useful for you to describe the pre-setup required to do make this works. The only pre-setup needed by the cloud admin is to provide a public pool for floating IP. Rudra JC On Feb 18, 2014, at 1:09 PM, Harshad Nakil hna...@contrailsystems.com wrote: 2. It does give full AWS compatibility (except for network ACL which was differed). Shared networks, FIP within scope of VPC is not some thing AWS provides. So it is not partial support. ___ 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
Re: [openstack-dev] VPC Proposal
There was a lot of emails on that thread, but I am not seeing the discussion converging. I would like to reiterate my concerns: - We are trying to implement an API on a feature that is not supported by openstack - As a result, the implementation is overloading existing construct without implementing full AWS capabilities and semantic (e.g. Shared network isolation from VPC, or Floating IP scoping to VPC). - Dependent blueprints are not implemented and have been deferred, resulting in the broken implementation (e.g. https://blueprints.launchpad.net/neutron/+spec/policy-extensions-for-neutron) - this feature is only available through EC2 API, which is likely going to result in another implementation for general use. - users adopting the VPC model proposed through EC2 API will be stuck in an upgrade mess when the proper implementation comes along. - There are new constructs in work that are better suited for implementing this concept properly (Multi tenant hierarchy and domains). As you can guess, I'm not really a fan, but it seems that only few individuals are concerned. I would think that this topic would create more interest, specially on the network side. Maybe because of the subject tags. I will therefore copy this email with the Neutron tag. JC On Feb 17, 2014, at 10:10 PM, Rudra Rugge rru...@juniper.net wrote: I am not sure on how to dig out the archives. There were a couple of emails exchanged with Salvatore on the thread pertaining to the extensions we were referring to as part of this blueprint. There are a few notes on the whiteboard of the blueprint as well. Regards, Rudra On 2/17/14, 1:28 PM, jc Martin jch.mar...@gmail.com wrote: Thanks, Do you have the links for the discussions ? Thanks, JC Sent from my iPhone On Feb 17, 2014, at 11:29 AM, Rudra Rugge rru...@juniper.net wrote: JC, BP has been updated with the correct links. I have removed the abandoned review #3. Please review #1 and #2. 1. https://review.openstack.org/#/c/40071/ This is the active review. There is one comment by Sean regarding adding a knob when Neutron is not used. That will be addressed with the next path. 2. https://review.openstack.org/#/c/53171 This is the active review for tempest test cases as requested by Joe Gordon. Currently abandoned until #1 goes through. 3. https://review.openstack.org/#/c/53171 This review is not active. It was accidentally submitted with a new change-id. Regards, Rudra On 2/16/14, 9:25 AM, Martin, JC jch.mar...@gmail.com wrote: Harshad, I tried to find some discussion around this blueprint. Could you provide us with some notes or threads ? Also, about the code review you mention. which one are you talking about : https://review.openstack.org/#/c/40071/ https://review.openstack.org/#/c/49470/ https://review.openstack.org/#/c/53171 because they are all abandoned. Could you point me to the code, and update the BP because it seems that the links are not correct. Thanks, JC On Feb 16, 2014, at 9:04 AM, Allamaraju, Subbu su...@subbu.org wrote: Harshad, Thanks for clarifying. We started looking at this as some our customers/partners were interested in get AWS API compatibility. We have this blueprint and code review pending for long time now. We will know based on this thread wether the community is interested. But I assumed that community was interested as the blueprint was approved and code review has no -1(s) for long time now. Makes sense. I would leave it to others on this list to chime in if there is sufficient interest or not. To clarify, a clear incremental path from an AWS compatible API to an OpenStack model is not clear. In my mind AWS compatible API does not need new openstack model. As more discussion happen on JC's proposal and implementation becomes clear we will know how incremental is the path. But at high level there two major differences 1. New first class object will be introduced which effect all components 2. more than one project can be supported within VPC. But it does not change AWS API(s). So even in JC(s) model if you want AWS API then we will have to keep VPC to project mapping 1:1, since the API will not take both VPC ID and project ID. As more users want to migrate from AWS or IaaS providers who want compete with AWS should be interested in this compatibility. IMHO that's a tough sell. Though an AWS compatible API does not need an OpenStack abstraction, we would end up with two independent ways of doing similar things. That would OpenStack repeating itself! Subbu ___ 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
[openstack-dev] Hierarchical Multitenancy and resource ownership
I see a lot of good things happening on the hierarchical multi tenancy proposal that Vish made a while back. However, the focus so far is on roles and quota but could not find any discussion related to resource ownership. Is the plan to allow the creation of resources within any level of the hierarchy or is the plan to allow the visibility of the resources up to a level in the hierarchy ? or both ? For example, if I have : - orga.vpca.projecta - orga.vpca.projectb and I want to share a resource like a network between projecta and projectb, should the network be owned by vpca or should it be owned by projecta or projectb, or a vpca.admin project and then shared to all children of vpca ? I think either would work, and both maybe required. Opinions ? JC ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] VPC Proposal
Joe, See my comments in line. On Feb 18, 2014, at 12:26 PM, Joe Gordon joe.gord...@gmail.com wrote: On Tue, Feb 18, 2014 at 10:03 AM, Martin, JC jch.mar...@gmail.com wrote: There was a lot of emails on that thread, but I am not seeing the discussion converging. I would like to reiterate my concerns: - We are trying to implement an API on a feature that is not supported by openstack I don't see it that way. I see this BP as converting neutron calls into AWS VPC calls with a little glue (which can be seen here https://wiki.openstack.org/wiki/Blueprint-aws-vpc-support). But I am no networking expert, so take that with a large grain of salt. If we had the supporting constructs, I would be in favor of implementing the AWS VPC features. - As a result, the implementation is overloading existing construct without implementing full AWS capabilities and semantic (e.g. Shared network isolation from VPC, or Floating IP scoping to VPC). A partial implementation is better then no implementation, that being said if we want to overhaul OpenStack's VPC capabilities I think the partial implementation would have to be thrown out. I agree too. However, given the choice, I would have preferred that we first augment the neutron network access and sharing model before the building the API. It stills qualify as partial implementation, but at least in the right order. - Dependent blueprints are not implemented and have been deferred, resulting in the broken implementation (e.g. https://blueprints.launchpad.net/neutron/+spec/policy-extensions-for-neutron) That is a requirement for phase 3, and shouldn't matter for phase 1 and 2. And only phase 1 is up for review. My point is that it does matter a it gives users the feeling that they get parity in term of isolation but they are not because of the missing isolation and sharing constructs. - this feature is only available through EC2 API, which is likely going to result in another implementation for general use. - users adopting the VPC model proposed through EC2 API will be stuck in an upgrade mess when the proper implementation comes along. This point concerns me the most, can you elaborate. First, while AWS does not support projects they do support, trough IAM, very flexible policies for VPC resources access, see http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_IAM.html If we wanted to reproduce this in openstack, we could map this to levels in the multi tenant hierarchy that Vish is proposing. However, because this project put all the resources in the same VPC project, it's not possible anymore to implement the access policies without moving resources between projects or recreating the VPC. - There are new constructs in work that are better suited for implementing this concept properly (Multi tenant hierarchy and domains). All that being said, it sounds like there are two separate efforts to get VPC into OpenStack, one by supporting AWS specs, and a second native OpenStack version. It sounds like further discussion is needed between these two efforts, so I am unapproving https://blueprints.launchpad.net/nova/+spec/aws-vpc-support as it needs further discussion. The last thing we want is to merge a controversial blueprint before all the questions can be resolved. We should keep the discussion going as I'm sure that we can get to a better proposal. JC ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Hierarchical Multitenancy and resource ownership
Vish, See comments below. JC On Feb 18, 2014, at 12:19 PM, Vishvananda Ishaya vishvana...@gmail.com wrote: On Feb 18, 2014, at 11:31 AM, Martin, JC jch.mar...@gmail.com wrote: I see a lot of good things happening on the hierarchical multi tenancy proposal that Vish made a while back. However, the focus so far is on roles and quota but could not find any discussion related to resource ownership. Is the plan to allow the creation of resources within any level of the hierarchy or is the plan to allow the visibility of the resources up to a level in the hierarchy ? or both ? For example, if I have : - orga.vpca.projecta - orga.vpca.projectb and I want to share a resource like a network between projecta and projectb, should the network be owned by vpca or should it be owned by projecta or projectb, or a vpca.admin project and then shared to all children of vpca ? I think either would work, and both maybe required. Opinions ? We haven’t discussed inheriting ownership of objects but at first glance it seems confusing: how would one determine if an object in vcpa is “shared” and visible to projects below, and if it is how far down the hierarchy would it be visible? It is probably best to keep this explicit for the moment. I’ve been thinking of sharing as objects that appear at multiple places in the hierarchy. This could be a list of “owners” or “shares”, but I think it would support either of your options. My initial thoughts would be to just put the network resource in orga.vcpa and then share it to the projects. This of course gets a little tedious when other projects are added later, but it avoids the complications i mentioned above. The way it would work is that when one is, for example, is creating a network with a 'shared' semantic (in a leaf project for example), the call would have to be extended with a scope (for backward compatibility, no scope would mean all/domain). e.g. neutron net-create --shared:orga.vpca vpca-shared-net instead of just neutron net-create --shared orga-shared-net another option is to implement the same policy mechanism that AWS has to allow the definition of scope based on rules. see http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_IAM.html JC ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] VPC Proposal
Harshad, I tried to find some discussion around this blueprint. Could you provide us with some notes or threads ? Also, about the code review you mention. which one are you talking about : https://review.openstack.org/#/c/40071/ https://review.openstack.org/#/c/49470/ https://review.openstack.org/#/c/53171 because they are all abandoned. Could you point me to the code, and update the BP because it seems that the links are not correct. Thanks, JC On Feb 16, 2014, at 9:04 AM, Allamaraju, Subbu su...@subbu.org wrote: Harshad, Thanks for clarifying. We started looking at this as some our customers/partners were interested in get AWS API compatibility. We have this blueprint and code review pending for long time now. We will know based on this thread wether the community is interested. But I assumed that community was interested as the blueprint was approved and code review has no -1(s) for long time now. Makes sense. I would leave it to others on this list to chime in if there is sufficient interest or not. To clarify, a clear incremental path from an AWS compatible API to an OpenStack model is not clear. In my mind AWS compatible API does not need new openstack model. As more discussion happen on JC's proposal and implementation becomes clear we will know how incremental is the path. But at high level there two major differences 1. New first class object will be introduced which effect all components 2. more than one project can be supported within VPC. But it does not change AWS API(s). So even in JC(s) model if you want AWS API then we will have to keep VPC to project mapping 1:1, since the API will not take both VPC ID and project ID. As more users want to migrate from AWS or IaaS providers who want compete with AWS should be interested in this compatibility. IMHO that's a tough sell. Though an AWS compatible API does not need an OpenStack abstraction, we would end up with two independent ways of doing similar things. That would OpenStack repeating itself! Subbu ___ 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
Re: [openstack-dev] VPC Proposal
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
[openstack-dev] VPC Proposal
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
Re: [openstack-dev] VPC Proposal
Arvind, Thanks for point me to the blueprint. I'll add it to the related blueprints. I think this could be part of the solution, but in addition to defining administrative boundaries, we need to change the way object sharing works. Today, there is only two levels : project private or public. You can share objects between projects but there is no single model across openstack to define resource scope, each component has a slightly different model. The VPC implementation will also have to address that. JC On Feb 14, 2014, at 11:26 AM, Tiwari, Arvind arvind.tiw...@hp.com wrote: Hi JC, I have proposed BP to address VPC using domain hierarchy and hierarchical administrative boundary. https://blueprints.launchpad.net/keystone/+spec/hierarchical-administrative-boundary Thanks, Arvind -Original Message- From: Martin, JC [mailto:jch.mar...@gmail.com] Sent: Friday, February 14, 2014 12:09 PM To: OpenStack Development Mailing List Subject: [openstack-dev] VPC Proposal 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
Re: [openstack-dev] VPC Proposal
Joe, I will let others comment, but since I think this BP was proposed much before the multi-tenant hierarchy BP, I would like to at least have the discussion. I would suggest a pause until we agree that this is ok to move this forward independently of the multi tenant hierarchy proposal. JC On Feb 14, 2014, at 11:42 AM, Joe Gordon joe.gord...@gmail.com wrote: On Fri, Feb 14, 2014 at 12:09 PM, 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. Nova doesn't support keystone V3 domains or the proposed multi tenant hierarchy (proposed after this BP) yet. Do you think this BP should be blocked with those two as dependencies? 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
Re: [openstack-dev] VPC Proposal
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
Re: [openstack-dev] VPC Proposal
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
Re: [openstack-dev] [keystone] role of Domain in VPC definition
Ravi, It seems that the following Blueprint https://wiki.openstack.org/wiki/Blueprint-aws-vpc-support has been approved. However, I cannot find a discussion with regard to the merit of using project vs. domain, or other mechanism for the implementation. I have an issue with this approach as it prevents tenants within the same domain sharing the same VPC to have projects. As an example, if you are a large organization on AWS, it is likely that you have a large VPC that will be shred by multiple projects. With this proposal, we loose that capability, unless I missed something. JC On Dec 19, 2013, at 6:10 PM, Ravi Chunduru ravi...@gmail.com wrote: Hi, We had some internal discussions on role of Domain and VPCs. I would like to expand and understand community thinking of Keystone domain and VPCs. Is VPC equivalent to Keystone Domain? If so, as a public cloud provider - I create a Keystone domain and give it to an organization which wants a virtual private cloud. Now the question is if that organization wants to have departments wise allocation of resources it is becoming difficult to visualize with existing v3 keystone constructs. Currently, it looks like each department of an organization cannot have their own resource management with in the organization VPC ( LDAP based user management, network management or dedicating computes etc.,) For us, Openstack Project does not match the requirements of a department of an organization. I hope you guessed what we wanted - Domain must have VPCs and VPC to have projects. I would like to know how community see the VPC model in Openstack. Thanks, -Ravi. ___ 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
